idnits 2.17.1 draft-sandlund-rfc4996bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4996]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4435 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 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 4996 (Obsoleted by RFC 6846) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Pelletier 3 Internet-Draft InterDigital Communications 4 Obsoletes: 4996 (if approved) K. Sandlund 5 Intended status: Standards Track Ericsson 6 Expires: September 6, 2012 L-E. Jonsson 8 M. West 9 Siemens/Roke Manor 10 March 5, 2012 12 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) 13 draft-sandlund-rfc4996bis-00 15 Abstract 17 This document specifies a ROHC (Robust Header Compression) profile 18 for compression of TCP/IP packets. The profile, called ROHC-TCP, 19 provides efficient and robust compression of TCP headers, including 20 frequently used TCP options such as SACK (Selective Acknowledgments) 21 and Timestamps. 23 ROHC-TCP works well when used over links with significant error rates 24 and long round-trip times. For many bandwidth-limited links where 25 header compression is essential, such characteristics are common. 27 This specification obsoletes [RFC4996]. It fixes a technical issue 28 with the SACK compression and clarifies other compression methods 29 used. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 6, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Existing TCP/IP Header Compression Schemes . . . . . . . . 7 68 3.2. Classification of TCP/IP Header Fields . . . . . . . . . . 8 69 4. Overview of the TCP/IP Profile (Informative) . . . . . . . . . 10 70 4.1. General Concepts . . . . . . . . . . . . . . . . . . . . . 10 71 4.2. Compressor and Decompressor Interactions . . . . . . . . . 10 72 4.2.1. Compressor Operation . . . . . . . . . . . . . . . . . 10 73 4.2.2. Decompressor Feedback . . . . . . . . . . . . . . . . 10 74 4.3. Packet Formats and Encoding Methods . . . . . . . . . . . 11 75 4.3.1. Compressing TCP Options . . . . . . . . . . . . . . . 11 76 4.3.2. Compressing Extension Headers . . . . . . . . . . . . 11 77 4.4. Expected Compression Ratios with ROHC-TCP . . . . . . . . 11 78 5. Compressor and Decompressor Logic (Normative) . . . . . . . . 12 79 5.1. Context Initialization . . . . . . . . . . . . . . . . . . 12 80 5.2. Compressor Operation . . . . . . . . . . . . . . . . . . . 13 81 5.2.1. Compression Logic . . . . . . . . . . . . . . . . . . 13 82 5.2.1.1. Optimistic Approach . . . . . . . . . . . . . . . 13 83 5.2.1.2. Periodic Context Refreshes . . . . . . . . . . . . 14 84 5.2.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 14 85 5.2.2.1. Optional Acknowledgments (ACKs) . . . . . . . . . 14 86 5.2.2.2. Negative Acknowledgments (NACKs) . . . . . . . . . 14 87 5.2.3. Context Replication . . . . . . . . . . . . . . . . . 15 88 5.3. Decompressor Operation . . . . . . . . . . . . . . . . . . 15 89 5.3.1. Decompressor States and Logic . . . . . . . . . . . . 15 90 5.3.1.1. Reconstruction and Verification . . . . . . . . . 16 91 5.3.1.2. Detecting Context Damage . . . . . . . . . . . . . 17 92 5.3.1.3. No Context (NC) State . . . . . . . . . . . . . . 18 93 5.3.1.4. Static Context (SC) State . . . . . . . . . . . . 18 94 5.3.1.5. Full Context (FC) State . . . . . . . . . . . . . 19 95 5.3.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 19 96 5.3.3. Context Replication . . . . . . . . . . . . . . . . . 19 97 6. Encodings in ROHC-TCP (Normative) . . . . . . . . . . . . . . 20 98 6.1. Control Fields in ROHC-TCP . . . . . . . . . . . . . . . . 20 99 6.1.1. Master Sequence Number (MSN) . . . . . . . . . . . . . 20 100 6.1.2. IP-ID Behavior . . . . . . . . . . . . . . . . . . . . 21 101 6.1.3. Explicit Congestion Notification (ECN) . . . . . . . . 21 102 6.2. Compressed Header Chains . . . . . . . . . . . . . . . . . 22 103 6.3. Compressing TCP Options with List Compression . . . . . . 24 104 6.3.1. List Compression . . . . . . . . . . . . . . . . . . . 24 105 6.3.2. Table-Based Item Compression . . . . . . . . . . . . . 25 106 6.3.3. Encoding of Compressed Lists . . . . . . . . . . . . . 26 107 6.3.4. Item Table Mappings . . . . . . . . . . . . . . . . . 28 108 6.3.5. Compressed Lists in Dynamic Chain . . . . . . . . . . 29 109 6.3.6. Irregular Chain Items for TCP Options . . . . . . . . 29 110 6.3.7. Replication of TCP Options . . . . . . . . . . . . . . 30 111 6.4. Profile-Specific Encoding Methods . . . . . . . . . . . . 30 112 6.4.1. inferred_ip_v4_header_checksum . . . . . . . . . . . . 30 113 6.4.2. inferred_mine_header_checksum . . . . . . . . . . . . 31 114 6.4.3. inferred_ip_v4_length . . . . . . . . . . . . . . . . 31 115 6.4.4. inferred_ip_v6_length . . . . . . . . . . . . . . . . 32 116 6.4.5. inferred_offset . . . . . . . . . . . . . . . . . . . 32 117 6.4.6. baseheader_extension_headers . . . . . . . . . . . . . 33 118 6.4.7. baseheader_outer_headers . . . . . . . . . . . . . . . 33 119 6.4.8. Scaled Encoding of Fields . . . . . . . . . . . . . . 33 120 6.4.8.1. Scaled TCP Sequence Number Encoding . . . . . . . 34 121 6.4.8.2. Scaled Acknowledgment Number Encoding . . . . . . 35 122 6.5. Encoding Methods With External Parameters . . . . . . . . 35 123 7. Packet Types (Normative) . . . . . . . . . . . . . . . . . . . 37 124 7.1. Initialization and Refresh (IR) Packets . . . . . . . . . 38 125 7.2. Context Replication (IR-CR) Packets . . . . . . . . . . . 40 126 7.3. Compressed (CO) Packets . . . . . . . . . . . . . . . . . 42 127 8. Header Formats (Normative) . . . . . . . . . . . . . . . . . . 43 128 8.1. Design Rationale for Compressed Base Headers . . . . . . . 43 129 8.2. Formal Definition of Header Formats . . . . . . . . . . . 46 130 8.3. Feedback Formats and Options . . . . . . . . . . . . . . . 87 131 8.3.1. Feedback Formats . . . . . . . . . . . . . . . . . . . 87 132 8.3.2. Feedback Options . . . . . . . . . . . . . . . . . . . 88 133 8.3.2.1. The REJECT Option . . . . . . . . . . . . . . . . 89 134 8.3.2.2. The MSN-NOT-VALID Option . . . . . . . . . . . . . 89 135 8.3.2.3. The MSN Option . . . . . . . . . . . . . . . . . . 89 136 8.3.2.4. The CONTEXT_MEMORY Feedback Option . . . . . . . . 90 137 8.3.2.5. Unknown Option Types . . . . . . . . . . . . . . . 90 138 9. Changes from RFC 4996 . . . . . . . . . . . . . . . . . . . . 90 139 9.1. Functional Changes . . . . . . . . . . . . . . . . . . . . 90 140 9.2. Non-functional Changes . . . . . . . . . . . . . . . . . . 91 141 10. Security Considerations . . . . . . . . . . . . . . . . . . . 91 142 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 143 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 144 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92 145 13.1. Normative References . . . . . . . . . . . . . . . . . . . 92 146 13.2. Informative References . . . . . . . . . . . . . . . . . . 93 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94 149 1. Introduction 151 There are several reasons to perform header compression on low- or 152 medium-speed links for TCP/IP traffic, and these have already been 153 discussed in [RFC2507]. Additional considerations that make 154 robustness an important objective for a TCP [RFC0793] compression 155 scheme are introduced in [RFC4163]. Finally, existing TCP/IP header 156 compression schemes ([RFC1144], [RFC2507]) are limited in their 157 handling of the TCP options field and cannot compress the headers of 158 handshaking packets (SYNs and FINs). 160 It is thus desirable for a header compression scheme to be able to 161 handle loss on the link between the compression and decompression 162 points as well as loss before the compression point. The header 163 compression scheme also needs to consider how to efficiently compress 164 short-lived TCP transfers and TCP options, such as SACK ([RFC2018], 165 [RFC2883]) and Timestamps ([RFC1323]). 167 The ROHC WG has developed a header compression framework on top of 168 which various profiles can be defined for different protocol sets, or 169 for different compression strategies. This document defines a TCP/IP 170 compression profile for the ROHC framework [RFC5795], compliant with 171 the requirements listed in [RFC4163]. 173 Specifically, it describes a header compression scheme for TCP/IP 174 header compression (ROHC-TCP) that is robust against packet loss and 175 that offers enhanced capabilities, in particular for the compression 176 of header fields including TCP options. The profile identifier for 177 TCP/IP compression is 0x0006. 179 2. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 This document reuses some of the terminology found in [RFC5795]. In 186 addition, this document uses or defines the following terms: 188 Base context 190 The base context is a context that has been validated by both the 191 compressor and the decompressor. A base context can be used as 192 the reference when building a new context using replication. 194 Base Context Identifier (Base CID) 195 The Base CID is the CID that identifies the base context, from 196 which information needed for context replication can be extracted. 198 Base header 200 A compressed representation of the innermost IP and TCP headers of 201 the uncompressed packet. 203 Chaining of items 205 A chain groups fields based on similar characteristics. ROHC-TCP 206 defines chain items for static, dynamic, replicable, or irregular 207 fields. Chaining is done by appending an item for each header 208 e.g., to the chain in their order of appearance in the 209 uncompressed packet. Chaining is useful to construct compressed 210 headers from an arbitrary number of any of the protocol headers 211 for which ROHC-TCP defines a compressed format. 213 Context Replication (CR) 215 Context replication is the mechanism that establishes and 216 initializes a new context based on another existing valid context 217 (a base context). This mechanism is introduced to reduce the 218 overhead of the context establishment procedure, and is especially 219 useful for compression of multiple short-lived TCP connections 220 that may be occurring simultaneously or near-simultaneously. 222 ROHC-TCP packet types 224 ROHC-TCP uses three different packet types: the Initialization and 225 Refresh (IR) packet type, the Context Replication (IR-CR) packet 226 type, and the Compressed packet (CO) type. 228 Short-lived TCP transfer 230 Short-lived TCP transfers refer to TCP connections transmitting 231 only small amounts of packets for each single connection. 233 3. Background 235 This section provides some background information on TCP/IP header 236 compression. The fundamentals of general header compression can be 237 found in [RFC5795]. In the following subsections, two existing 238 TCP/IP header compression schemes are first described along with a 239 discussion of their limitations, followed by the classification of 240 TCP/IP header fields. Finally, some of the characteristics of short- 241 lived TCP transfers are summarized. 243 A behavior analysis of TCP/IP header fields is found in [RFC4413]. 245 3.1. Existing TCP/IP Header Compression Schemes 247 Compressed TCP (CTCP) and IP Header Compression (IPHC) are two 248 different schemes that may be used to compress TCP/IP headers. Both 249 schemes transmit only the differences from the previous header in 250 order to reduce the size of the TCP/IP header. 252 The CTCP [RFC1144] compressor detects transport-level retransmissions 253 and sends a header that updates the context completely when they 254 occur. While CTCP works well over reliable links, it is vulnerable 255 when used over less reliable links as even a single packet loss 256 results in loss of synchronization between the compressor and the 257 decompressor. This in turn leads to the TCP receiver discarding all 258 remaining packets in the current window because of a checksum error. 259 This effectively prevents the TCP fast retransmit algorithm [RFC5681] 260 from being triggered. In such a case, the compressor must wait until 261 TCP times out and retransmits a packet to resynchronize. 263 To reduce the errors due to the inconsistent contexts between 264 compressor and decompressor when compressing TCP, IPHC [RFC2507] 265 improves somewhat on CTCP by augmenting the repair mechanism of CTCP 266 with a local repair mechanism called TWICE and with a link-layer 267 mechanism based on negative acknowledgments to request a header that 268 updates the context. 270 The TWICE algorithm assumes that only the Sequence Number field of 271 TCP segments is changing with the deltas between consecutive packets 272 being constant in most cases. This assumption is however not always 273 true, especially when TCP Timestamps and SACK options are used. 275 The full header request mechanism requires a feedback channel that 276 may be unavailable in some circumstances. This channel is used to 277 explicitly request that the next packet be sent with an uncompressed 278 header to allow resynchronization without waiting for a TCP timeout. 279 In addition, this mechanism does not perform well on links with long 280 round-trip times. 282 Both CTCP and IPHC are also limited in their handling of the TCP 283 options field. For IPHC, any change in the options field (caused by 284 Timestamps or SACK, for example) renders the entire field 285 uncompressible, while for CTCP, such a change in the options field 286 effectively disables TCP/IP header compression altogether. 288 Finally, existing TCP/IP compression schemes do not compress the 289 headers of handshaking packets (SYNs and FINs). Compressing these 290 packets may greatly improve the overall header compression ratio for 291 the cases where many short-lived TCP connections share the same 292 channel. 294 3.2. Classification of TCP/IP Header Fields 296 Header compression is possible due to the fact that there is much 297 redundancy between header field values within packets, especially 298 between consecutive packets. To utilize these properties for TCP/IP 299 header compression, it is important to understand the change patterns 300 of the various header fields. 302 All fields of the TCP/IP packet header have been classified in detail 303 in [RFC4413]. The main conclusion is that most of the header fields 304 can easily be compressed away since they seldom or never change. The 305 following fields do however require more sophisticated mechanisms: 307 - IPv4 Identification (16 bits) - IP-ID 308 - TCP Sequence Number (32 bits) - SN 309 - TCP Acknowledgment Number (32 bits) 310 - TCP Reserved ( 4 bits) 311 - TCP ECN flags ( 2 bits) - ECN 312 - TCP Window (16 bits) 313 - TCP Options 314 o Maximum Segment Size (32 bits) - MSS 315 o Window Scale (24 bits) - WSCALE 316 o SACK Permitted (16 bits) 317 o TCP SACK (80, 144, 208, or 272 bits) - SACK 318 o TCP Timestamp (80 bits) - TS 320 The assignment of IP-ID values can be done in various ways, usually 321 one of sequential, sequential jump, or random, as described in 322 Section 4.1.3 of [RFC4413]. Some IPv4 stacks do use a sequential 323 assignment when generating IP-ID values but do not transmit the 324 contents of this field in network byte order; instead, it is sent 325 with the two octets reversed. In this case, the compressor can 326 compress the IP-ID field after swapping the bytes. Consequently, the 327 decompressor also swaps the bytes of the IP-ID after decompression to 328 regenerate the original IP-ID. With respect to TCP compression, the 329 analysis in [RFC4413] reveals that there is no obvious candidate 330 among the TCP fields suitable to infer the IP-ID. 332 The change pattern of several TCP fields (Sequence Number, 333 Acknowledgment Number, Window, etc.) is very hard to predict. Of 334 particular importance to a TCP/IP header compression scheme is the 335 understanding of the sequence and acknowledgment numbers [RFC4413]. 337 Specifically, the TCP Sequence Number can be anywhere within a range 338 defined by the TCP Window at any point on the path (i.e., wherever a 339 compressor might be deployed). Missing packets or retransmissions 340 can cause the TCP Sequence Number to fluctuate within the limits of 341 this window. The TCP Window also bounds the jumps in acknowledgment 342 number. 344 Another important behavior of the TCP/IP header is the dependency 345 between the sequence number and the acknowledgment number. TCP 346 connections can be either near-symmetrical or show a strong 347 asymmetrical bias with respect to the data traffic. In the latter 348 case, the TCP connections mainly have one-way traffic (Web browsing 349 and file downloading, for example). This means that on the forward 350 path (from server to client), only the sequence number is changing 351 while the acknowledgment number remains constant for most packets; on 352 the backward path (from client to server), only the acknowledgment 353 number is changing and the sequence number remains constant for most 354 packets. A compression scheme for TCP should thus have packet 355 formats suitable for either cases, i.e., packet formats that can 356 carry either only sequence number bits, only acknowledgment number 357 bits, or both. 359 In addition, TCP flows can be short-lived transfers. Short-lived TCP 360 transfers will degrade the performance of header compression schemes 361 that establish a new context by initially sending full headers. 362 Multiple simultaneous or near simultaneous TCP connections may 363 exhibit much similarity in header field values and context values 364 among each other, which would make it possible to reuse information 365 between flows when initializing a new context. A mechanism to this 366 end, context replication [RFC4164], makes the context establishment 367 step faster and more efficient, by replicating part of an existing 368 context to a new flow. The conclusion from [RFC4413] is that part of 369 the IP sub-context, some TCP fields, and some context values can be 370 replicated since they seldom change or change with only a small jump. 372 ROHC-TCP also compresses the following headers: IPv6 Destination 373 Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by- 374 Hop Options header [RFC2460], Authentication Header (AH) [RFC4302], 375 NULL-encrypted Encapsulating Security Payload (ESP) header [RFC4303], 376 Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] and the 377 Minimal Encapsulation header (MINE) [RFC2004]. 379 Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any 380 special treatment in this document, for reasons similar to those 381 described in [RFC3095]. 383 4. Overview of the TCP/IP Profile (Informative) 385 4.1. General Concepts 387 ROHC-TCP uses the ROHC protocol as described in [RFC5795]. ROHC-TCP 388 supports context replication as defined in [RFC4164]. Context 389 replication can be particularly useful for short-lived TCP flows 390 [RFC4413]. 392 4.2. Compressor and Decompressor Interactions 394 4.2.1. Compressor Operation 396 Header compression with ROHC can be conceptually characterized as the 397 interaction of a compressor with a decompressor state machine. The 398 compressor's task is to minimally send the information needed to 399 successfully decompress a packet, based on a certain confidence 400 regarding the state of the decompressor context. 402 For ROHC-TCP compression, the compressor normally starts compression 403 with the initial assumption that the decompressor has no useful 404 information to process the new flow, and sends Initialization and 405 Refresh (IR) packets. Alternatively, the compressor may also support 406 Context Replication (CR) and use IR-CR packets [RFC4164], which 407 attempts to reuse context information related to another flow. 409 The compressor can then adjust the compression level based on its 410 confidence that the decompressor has the necessary information to 411 successfully process the Compressed (CO) packets that it selects. In 412 other words, the task of the compressor is to ensure that the 413 decompressor operates in the state that allows decompression of the 414 most efficient CO packet(s), and to allow the decompressor to move to 415 that state as soon as possible otherwise. 417 4.2.2. Decompressor Feedback 419 The ROHC-TCP profile can be used in environments with or without 420 feedback capabilities from decompressor to compressor. ROHC-TCP 421 however assumes that if a ROHC feedback channel is available and if 422 this channel is used at least once by the decompressor for a specific 423 ROHC-TCP context, this channel will be used during the entire 424 compression operation for that context. If the feedback channel 425 disappears, compression should be restarted. 427 The reception of either positive acknowledgment (ACKs) or negative 428 acknowledgment (NACKs) establishes the feedback channel from the 429 decompressor for the context for which the feedback was received. 430 Once there is an established feedback channel for a specific context, 431 the compressor should make use of this feedback to estimate the 432 current state of the decompressor. This helps in increasing the 433 compression efficiency by providing the information needed for the 434 compressor to achieve the necessary confidence level. 436 The ROHC-TCP feedback mechanism is limited in its applicability by 437 the number of (least significant bit (LSB) encoded) master sequence 438 number (MSN) (see Section 6.1.1) bits used in the FEEDBACK-2 format 439 (see Section 8.3). It is not suitable for a decompressor to use 440 feedback altogether where the MSN bits in the feedback could wrap 441 around within one round-trip time. Instead, unidirectional operation 442 -- where the compressor periodically sends larger context-updating 443 packets -- is more appropriate. 445 4.3. Packet Formats and Encoding Methods 447 The packet formats and encoding methods used for ROHC-TCP are defined 448 using the formal notation [RFC4997]. The formal notation is used to 449 provide an unambiguous representation of the packet formats and a 450 clear definition of the encoding methods. 452 4.3.1. Compressing TCP Options 454 The TCP options in ROHC-TCP are compressed using a list compression 455 encoding that allows option content to be established so that TCP 456 options can be added to the context without having to send all TCP 457 options uncompressed. 459 4.3.2. Compressing Extension Headers 461 ROHC-TCP compresses the extension headers as listed in Section 3.2. 462 These headers are treated exactly as other headers and thus have a 463 static chain, a dynamic chain, an irregular chain, and a chain for 464 context replication (Section 6.2). 466 This means that headers appearing in or disappearing from the flow 467 being compressed will lead to changes to the static chain. However, 468 the change pattern of extension headers is not deemed to impair 469 compression efficiency with respect to this design strategy. 471 4.4. Expected Compression Ratios with ROHC-TCP 473 The following table illustrates typical compression ratios that can 474 be expected when using ROHC-TCP and IPHC [RFC2507]. 476 The figures in the table assume that the compression context has 477 already been properly initialized. For the TS option, the Timestamp 478 is assumed to change with small values. All TCP options include a 479 suitable number of No Operation (NOP) options [RFC0793] for padding 480 and/or alignment. Finally, in the examples for IPv4, a sequential 481 IP-ID behavior is assumed. 483 Total Header Size (octets) 484 ROHC-TCP IPHC 485 Unc. DATA ACK DATA ACK 486 IPv4+TCP+TS 52 8 8 18 18 487 IPv4+TCP+TS 52 7 6 16 16 (1) 488 IPv6+TCP+TS 72 8 7 18 18 489 IPv6+TCP+no opt 60 6 5 6 6 490 IPv6+TCP+SACK 80 - 15 - 80 (2) 491 IPv6+TCP+SACK 80 - 9 - 26 (3) 493 (1) The payload size of the data stream is constant. 494 (2) The SACK option appears in the header, but was not present 495 in the previous packet. Two SACK blocks are assumed. 496 (3) The SACK option appears in the header, and was also present 497 in the previous packet (with different SACK blocks). 498 Two SACK blocks are assumed. 500 The table below illustrates the typical initial compression ratios 501 for ROHC-TCP and IPHC. The data stream in the example is assumed to 502 be IPv4+TCP, with a sequential behavior for the IP-ID. The following 503 options are assumed present in the SYN packet: TS, MSS, and WSCALE, 504 with an appropriate number of NOP options. 506 Total Header Size (octets) 507 Unc. ROHC-TCP IPHC 508 1st packet (SYN) 60 49 60 509 2nd packet 52 12 52 511 The figures in the table assume that the compressor has received an 512 acknowledgment from the decompressor before compressing the second 513 packet, which can be expected when feedback is used in ROHC-TCP. 514 This is because in the most common case, the TCP ACKs are expected to 515 take the same return path, and because TCP does not send more packets 516 until the TCP SYN packet has been acknowledged. 518 5. Compressor and Decompressor Logic (Normative) 520 5.1. Context Initialization 522 The static context of ROHC-TCP flows can be initialized in either of 523 two ways: 525 1. By using an IR packet as in Section 7.1, where the profile number 526 is 0x06 and the static chain ends with the static part of a TCP 527 header. 529 2. By replicating an existing context using the mechanism defined by 530 [RFC4164]. This is done with the IR-CR packet defined in 531 Section 7.2, where the profile number is 0x06. 533 5.2. Compressor Operation 535 5.2.1. Compression Logic 537 The task of the compressor is to determine what data must be sent 538 when compressing a TCP/IP packet, so that the decompressor can 539 successfully reconstruct the original packet based on its current 540 state. The selection of the type of compressed header to send thus 541 depends on a number of factors, including: 543 o The change behavior of header fields in the flow, e.g., conveying 544 the necessary information within the restrictions of the set of 545 available packet formats. 547 o The compressor's level of confidence regarding decompressor state, 548 e.g., by selecting header formats updating the same type of 549 information for a number of consecutive packets or from the 550 reception of decompressor feedback (ACKs and/or NACKs). 552 o Additional robustness required for the flow, e.g., periodic 553 refreshes of static and dynamic information using IR and IR-DYN 554 packets when decompressor feedback is not expected. 556 The impact of these factors on the compressor's packet type selection 557 is described in more detail in the following subsections. 559 In this section, a "higher compression state" means that less data 560 will be sent in compressed packets, i.e., smaller compressed headers 561 are used, while a lower compression state means that a larger amount 562 of data will be sent using larger compressed headers. 564 5.2.1.1. Optimistic Approach 566 The optimistic approach is the principle by which a compressor sends 567 the same type of information for a number of packets (consecutively 568 or not) until it is fairly confident that the decompressor has 569 received the information. The optimistic approach is useful to 570 ensure robustness when ROHC-TCP is used to compress packets over 571 lossy links. 573 Therefore, if field X in the uncompressed packet changes value, the 574 compressor MUST use a packet type that contains an encoding for field 575 X until it has gained confidence that the decompressor has received 576 at least one packet containing the new value for X. The compressor 577 SHOULD choose a compressed format with the smallest header that can 578 convey the changes needed to fulfill the optimistic approach 579 condition used. 581 5.2.1.2. Periodic Context Refreshes 583 When the optimistic approach is used, there will always be a 584 possibility of decompression failures since the decompressor may not 585 have received sufficient information for correct decompression. 587 Therefore, until the decompressor has established a feedback channel, 588 the compressor SHOULD periodically move to a lower compression state 589 and send IR and/or IR-DYN packets. These refreshes can be based on 590 timeouts, on the number of compressed packets sent for the flow, or 591 any other strategy specific to the implementation. Once the feedback 592 channel is established, the decompressor MAY stop performing periodic 593 refreshes. 595 5.2.2. Feedback Logic 597 The semantics of feedback messages, acknowledgments (ACKs) and 598 negative acknowledgments (NACKs or STATIC-NACKs), are defined in 599 Section 5.2.4.1 of [RFC5795]. 601 5.2.2.1. Optional Acknowledgments (ACKs) 603 The compressor MAY use acknowledgment feedback (ACKs) to move to a 604 higher compression state. 606 Upon reception of an ACK for a context-updating packet, the 607 compressor obtains confidence that the decompressor has received the 608 acknowledged packet and that it has observed changes in the packet 609 flow up to the acknowledged packet. 611 This functionality is optional, so a compressor MUST NOT expect to 612 get such ACKs, even if a feedback channel is available and has been 613 established for that flow. 615 5.2.2.2. Negative Acknowledgments (NACKs) 617 The compressor uses feedback from the decompressor to move to a lower 618 compression state (NACKs). 620 On reception of a NACK feedback, the compressor SHOULD: 622 o assume that only the static part of the decompressor is valid, and 624 o re-send all dynamic information (via an IR or IR-DYN packet) the 625 next time it compresses a packet for the indicated flow 627 unless it has confidence that information sent after the packet being 628 acknowledged already provides a suitable response to the NACK 629 feedback. In addition, the compressor MAY use a CO packet carrying a 630 7-bit Cyclic Redundancy Check (CRC) if it can determine with enough 631 confidence what information provides a suitable response to the NACK 632 feedback. 634 On reception of a STATIC-NACK feedback, the compressor SHOULD: 636 o assume that the decompressor has no valid context, and 638 o re-send all static and all dynamic information (via an IR packet) 639 the next time it compresses a packet for the indicated flow 641 unless it has confidence that information sent after the packet that 642 is being acknowledged already provides a suitable response to the 643 STATIC-NACK feedback. 645 5.2.3. Context Replication 647 A compressor MAY support context replication by implementing the 648 additional compression and feedback logic defined in [RFC4164]. 650 5.3. Decompressor Operation 652 5.3.1. Decompressor States and Logic 654 The three states of the decompressor are No Context (NC), Static 655 Context (SC), and Full Context (FC). The decompressor starts in its 656 lowest compression state, the NC state. Successful decompression 657 will always move the decompressor to the FC state. The decompressor 658 state machine normally never leaves the FC state once it has entered 659 this state; only repeated decompression failures will force the 660 decompressor to transit downwards to a lower state. 662 Below is the state machine for the decompressor. Details of the 663 transitions between states and decompression logic are given in the 664 subsections following the figure. 666 Success 667 +-->------>------>------>------>------>--+ 668 | | 669 No Static | No Dynamic Success | Success 670 +-->--+ | +-->--+ +--->----->---+ +-->--+ 671 | | | | | | | | | 672 | v | | v | v | v 673 +-----------------+ +---------------------+ +-------------------+ 674 | No Context (NC) | | Static Context (SC) | | Full Context (FC) | 675 +-----------------+ +---------------------+ +-------------------+ 676 ^ | ^ | 677 | Static Context | | Context Damage Assumed | 678 | Damage Assumed | | | 679 +-----<------<------<-----+ +-----<------<------<-----+ 681 5.3.1.1. Reconstruction and Verification 683 When decompressing an IR or an IR-DYN packet, the decompressor MUST 684 validate the integrity of the received header using CRC-8 validation 685 [RFC5795]. If validation fails, the packet MUST NOT be delivered to 686 upper layers. 688 Upon receiving an IR-CR packet, the decompressor MUST perform the 689 actions as specified in [RFC4164]. 691 When decompressing other packet types (e.g., CO packets), the 692 decompressor MUST validate the outcome of the decompression attempt 693 using CRC verification [RFC5795]. If verification fails, a 694 decompressor implementation MAY attempt corrective or repair measures 695 on the packet, and the result of any attempt MUST be validated using 696 the CRC verification; otherwise, the packet MUST NOT be delivered to 697 upper layers. 699 When the CRC-8 validation or the CRC verification of the received 700 header is successful, the decompressor SHOULD update its context with 701 the information received in the current header; the decompressor then 702 passes the reconstructed packet to the system's network layer. 703 Otherwise, the decompressor context MUST NOT be updated. 705 If the received packet is older than the current reference packet, 706 e.g., based on the master sequence number (MSN) in the compressed 707 packet, the decompressor MAY refrain from updating the context using 708 the information received in the current packet, even if the 709 correctness of its header was successfully verified. 711 5.3.1.2. Detecting Context Damage 713 All header formats carry a CRC and are context updating. A packet 714 for which the CRC succeeds updates the reference values of all header 715 fields, either explicitly (from the information about a field carried 716 within the compressed header) or implicitly (fields that are inferred 717 from other fields). 719 The decompressor may assume that some or the entire context is 720 invalid, following one or more failures to validate or verify a 721 header using the CRC. Because the decompressor cannot know the exact 722 reason(s) for a CRC failure or what field caused it, the validity of 723 the context hence does not refer to what exact context entry is 724 deemed valid or not. 726 Validity of the context rather relates to the detection of a problem 727 with the context. The decompressor first assumes that the type of 728 information that most likely caused the failure(s) is the state that 729 normally changes for each packet, i.e., context damage of the dynamic 730 part of the context. Upon repeated failures and unsuccessful 731 repairs, the decompressor then assumes that the entire context, 732 including the static part, needs to be repaired, i.e., static context 733 damage. 735 Context Damage Detection 737 The assumption of context damage means that the decompressor will 738 not attempt decompression of a CO header that carries a 3-bit CRC, 739 and only attempt decompression of IR, IR-DYN, or IR-CR headers or 740 CO headers protected by a CRC-7. 742 Static Context Damage Detection 744 The assumption of static context damage means that the 745 decompressor refrains from attempting decompression of any type of 746 header other than the IR header. 748 How these assumptions are made, i.e., how context damage is detected, 749 is open to implementations. It can be based on the residual error 750 rate, where a low error rate makes the decompressor assume damage 751 more often than on a high-rate link. 753 The decompressor implements these assumptions by selecting the type 754 of compressed header for which it may attempt decompression. In 755 other words, validity of the context refers to the ability of a 756 decompressor to attempt or not attempt decompression of specific 757 packet types. 759 5.3.1.3. No Context (NC) State 761 Initially, while working in the No Context (NC) state, the 762 decompressor has not yet successfully decompressed a packet. 764 Allowing decompression: 766 In the NC state, only packets carrying sufficient information on 767 the static fields (IR and IR-CR packets) can be decompressed; 768 otherwise, the packet MUST NOT be decompressed and MUST NOT be 769 delivered to upper layers. 771 Feedback logic: 773 In the NC state, the decompressor should send a STATIC-NACK if a 774 packet of a type other than IR is received, or if decompression of 775 an IR packet has failed, subject to the feedback rate limitation 776 as described in Section 5.3.2 778 Once a packet has been validated and decompressed correctly, the 779 decompressor MUST transit to the FC state. 781 5.3.1.4. Static Context (SC) State 783 When the decompressor is in the Static Context (SC) state, only the 784 static part of the decompressor context is valid. 786 From the SC state, the decompressor moves back to the NC state if 787 static context damage is detected. 789 Allowing decompression: 791 In the SC state, packets carrying sufficient information on the 792 dynamic fields covered by an 8-bit CRC (e.g., IR and IR-DYN) or CO 793 packets covered by a 7-bit CRC can be decompressed; otherwise, the 794 packet MUST NOT be decompressed and MUST NOT be delivered to upper 795 layers. 797 Feedback logic: 799 In the SC state, the decompressor should send a STATIC-NACK if CRC 800 validation of an IR/IR-DYN/IR-CR fails and static context damage 801 is assumed. If any other packet type is received, the 802 decompressor should send a NACK. Both of the above cases are 803 subject to the feedback rate limitation as described in 804 Section 5.3.2. 806 Once a packet has been validated and decompressed correctly, the 807 decompressor MUST transit to the FC state. 809 5.3.1.5. Full Context (FC) State 811 In the Full Context (FC) state, both the static and the dynamic parts 812 of the decompressor context are valid. From the FC state, the 813 decompressor moves back to the SC state if context damage is 814 detected. 816 Allowing decompression: 818 In the FC state, decompression can be attempted regardless of the 819 type of packet received. 821 Feedback logic: 823 In the FC state, the decompressor should send a NACK if the 824 decompression of any packet type fails and context damage is 825 assumed, subject to the feedback rate limitation as described in 826 Section 5.3.2. 828 5.3.2. Feedback Logic 830 The decompressor MAY send positive feedback (ACKs) to initially 831 establish the feedback channel for a particular flow. Either 832 positive feedback (ACKs) or negative feedback (NACKs) establishes 833 this channel. 835 Once the feedback channel is established, the decompressor is 836 REQUIRED to continue sending NACKs or STATIC-NACKs for as long as the 837 context is associated with the same profile, in this case with 838 profile 0x0006, as per the logic defined for each state in 839 Section 5.3.1. 841 The decompressor MAY send ACKs upon successful decompression of any 842 packet type. In particular, when a packet carrying a significant 843 context update is correctly decompressed, the decompressor MAY send 844 an ACK. 846 The decompressor should limit the rate at which it sends feedback, 847 for both ACKs and STATIC-NACK/NACKs, and should avoid sending 848 unnecessary duplicates of the same type of feedback message that may 849 be associated to the same event. 851 5.3.3. Context Replication 853 ROHC-TCP supports context replication; therefore, the decompressor 854 MUST implement the additional decompressor and feedback logic defined 855 in [RFC4164]. 857 6. Encodings in ROHC-TCP (Normative) 859 6.1. Control Fields in ROHC-TCP 861 In ROHC-TCP, a number of control fields are used by the decompressor 862 in its interpretation of the format of the packets received from the 863 compressor. 865 A control field is a field that is transmitted from the compressor to 866 the decompressor, but is not part of the uncompressed header. Values 867 for control fields can be set up in the context of both the 868 compressor and the decompressor. Once established at the 869 decompressor, the values of these fields should be kept until updated 870 by another packet. 872 6.1.1. Master Sequence Number (MSN) 874 There is no field in the TCP header that can act as the master 875 sequence number for TCP compression, as explained in [RFC4413], 876 Section 5.6. 878 To overcome this problem, ROHC-TCP introduces a control field called 879 the Master Sequence Number (MSN) field. The MSN field is created at 880 the compressor, rather than using one of the fields already present 881 in the uncompressed header. The compressor increments the value of 882 the MSN by one for each packet that it sends. 884 The MSN field has the following two functions: 886 1. Differentiating between packets when sending feedback data. 888 2. Inferring the value of incrementing fields such as the IP-ID. 890 The MSN field is present in every packet sent by the compressor. The 891 MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent 892 in full in IR/IR-DYN packets. The decompressor always sends the MSN 893 as part of the feedback information. The compressor can later use 894 the MSN to infer which packet the decompressor is acknowledging. 896 When the MSN is initialized, it SHOULD be initialized to a random 897 value. The compressor should only initialize a new MSN for the 898 initial IR or IR-CR packet sent for a CID that corresponds to a 899 context that is not already associated with this profile. In other 900 words, if the compressor reuses the same CID to compress many TCP 901 flows one after the other, the MSN is not reinitialized but rather 902 continues to increment monotonically. 904 For context replication, the compressor does not use the MSN of the 905 base context when sending the IR-CR packet, unless the replication 906 process overwrites the base context (i.e., Base CID == CID). 907 Instead, the compressor uses the value of the MSN if it already 908 exists in the ROHC-TCP context being associated with the new flow 909 (CID); otherwise, the MSN is initialized to a new value. 911 6.1.2. IP-ID Behavior 913 The IP-ID field of the IPv4 header can have different change 914 patterns. Conceptually, a compressor monitors changes in the value 915 of the IP-ID field and selects encoding methods and packet formats 916 that are the closest match to the observed change pattern. 918 ROHC-TCP defines different types of compression techniques for the 919 IP-ID, to provide the flexibility to compress any of the behaviors it 920 may observe for this field: sequential in network byte order (NBO), 921 sequential byte-swapped, random (RND), or constant to a value of 922 zero. 924 The compressor monitors changes in the value of the IP-ID field for a 925 number of packets, to identify which one of the above listed 926 compression alternatives is the closest match to the observed change 927 pattern. The compressor can then select packet formats and encoding 928 methods based on the identified field behavior. 930 If more than one level of IP headers is present, ROHC-TCP can assign 931 a sequential behavior (NBO or byte-swapped) only to the IP-ID of the 932 innermost IP header. This is because only this IP-ID can possibly 933 have a sufficiently close correlation with the MSN (see also 934 Section 6.1.1) to compress it as a sequentially changing field. 935 Therefore, a compressor MUST NOT assign either the sequential (NBO) 936 or the sequential byte-swapped behavior to tunneling headers. 938 The control field for the IP-ID behavior determines which set of 939 packet formats will be used. These control fields are also used to 940 determine the contents of the irregular chain item (see Section 6.2) 941 for each IP header. 943 6.1.3. Explicit Congestion Notification (ECN) 945 When ECN [RFC3168] is used once on a flow, the ECN bits could change 946 quite often. ROHC-TCP maintains a control field in the context to 947 indicate whether or not ECN is used. This control field is 948 transmitted in the dynamic chain of the TCP header, and its value can 949 be updated using specific compressed headers carrying a 7-bit CRC. 951 When this control field indicates that ECN is being used, items of 952 all IP and TCP headers in the irregular chain include bits used for 953 ECN. To preserve octet-alignment, all of the TCP reserved bits are 954 transmitted and, for outer IP headers, the entire Type of Service/ 955 Traffic Class (TOS/TC) field is included in the irregular chain. 956 When there is only one IP header present in the packet (i.e., no IP 957 tunneling is used), this compression behavior allows the compressor 958 to handle changes in the ECN bits by adding a single octet to the 959 compressed header. 961 The reason for including the ECN bits of all IP headers in the 962 compressed packet when the control field is set is that the profile 963 needs to efficiently compress flows containing IP tunnels using the 964 "full-functionality option" of Section 9.1 of [RFC3168]. For these 965 flows, a change in the ECN bits of an inner IP header is propagated 966 to the outer IP headers. When the "limited-functionality" option is 967 used, the compressor will therefore sometimes send one octet more 968 than necessary per tunnel header, but this has been considered a 969 reasonable tradeoff when designing this profile. 971 6.2. Compressed Header Chains 973 Some packet types use one or more chains containing sub-header 974 information. The function of a chain is to group fields based on 975 similar characteristics, such as static, dynamic, or irregular 976 fields. Chaining is done by appending an item for each header to the 977 chain in their order of appearance in the uncompressed packet, 978 starting from the fields in the outermost header. 980 Chains are defined for all headers compressed by ROHC-TCP, as listed 981 below. Also listed are the names of the encoding methods used to 982 encode each of these protocol headers. 984 o TCP [RFC0793], encoding method: "tcp" 986 o IPv4 [RFC0791], encoding method: "ipv4" 988 o IPv6 [RFC2460], encoding method: "ipv6" 990 o AH [RFC4302], encoding method: "ah" 992 o GRE [RFC2784][RFC2890], encoding method: "gre" 994 o MINE [RFC2004], encoding method: "mine" 996 o IPv6 Destination Options header [RFC2460], encoding method: 997 "ip_dest_opt" 999 o IPv6 Hop-by-Hop Options header [RFC2460], encoding method: 1000 "ip_hop_opt" 1002 o IPv6 Routing header [RFC2460], encoding method: "ip_rout_opt" 1004 Static chain: 1006 The static chain consists of one item for each header of the chain 1007 of protocol headers to be compressed, starting from the outermost 1008 IP header and ending with a TCP header. In the formal description 1009 of the packet formats, this static chain item for each header is a 1010 format whose name is suffixed by "_static". The static chain is 1011 only used in IR packets. 1013 Dynamic chain: 1015 The dynamic chain consists of one item for each header of the 1016 chain of protocol headers to be compressed, starting from the 1017 outermost IP header and ending with a TCP header. The dynamic 1018 chain item for the TCP header also contains a compressed list of 1019 TCP options (see Section 6.3). In the formal description of the 1020 packet formats, the dynamic chain item for each header type is a 1021 format whose name is suffixed by "_dynamic". The dynamic chain is 1022 used in both IR and IR-DYN packets. 1024 Replicate chain: 1026 The replicate chain consists of one item for each header in the 1027 chain of protocol headers to be compressed, starting from the 1028 outermost IP header and ending with a TCP header. The replicate 1029 chain item for the TCP header also contains a compressed list of 1030 TCP options (see Section 6.3). In the formal description of the 1031 packet formats, the replicate chain item for each header type is a 1032 format whose name is suffixed by "_replicate". Header fields that 1033 are not present in the replicate chain are replicated from the 1034 base context. The replicate chain is only used in the IR-CR 1035 packet. 1037 Irregular chain: 1039 The structure of the irregular chain is analogous to the structure 1040 of the static chain. For each compressed packet, the irregular 1041 chain is appended at the specified location in the general format 1042 of the compressed packets as defined in Section 7.3. This chain 1043 also includes the irregular chain items for TCP options as defined 1044 in Section 6.3.6, which are placed directly after the irregular 1045 chain item of the TCP header, and in the same order as the options 1046 appear in the uncompressed packet. In the formal description of 1047 the packet formats, the irregular chain item for each header type 1048 is a format whose name is suffixed by "_irregular". The irregular 1049 chain is used only in CO packets. 1051 The format of the irregular chain for the innermost IP header 1052 differs from the format of outer IP headers, since this header is 1053 part of the compressed base header. 1055 6.3. Compressing TCP Options with List Compression 1057 This section describes in detail how list compression is applied to 1058 the TCP options. In the definition of the packet formats for ROHC- 1059 TCP, the most frequent TCP options have one encoding method each, as 1060 listed in the table below. 1062 +-----------------+------------------------+ 1063 | Option name | Encoding method name | 1064 +-----------------+------------------------+ 1065 | NOP | tcp_opt_nop | 1066 | EOL | tcp_opt_eol | 1067 | MSS | tcp_opt_mss | 1068 | WINDOW SCALE | tcp_opt_wscale | 1069 | TIMESTAMP | tcp_opt_ts | 1070 | SACK-PERMITTED | tcp_opt_sack_permitted | 1071 | SACK | tcp_opt_sack | 1072 | Generic options | tcp_opt_generic | 1073 +-----------------+------------------------+ 1075 Each of these encoding methods has an uncompressed format, a format 1076 suffixed by "_list_item" and a format suffixed by "_irregular". In 1077 some cases, a single encoding method may have multiple "_list_item" 1078 or "_irregular" formats, in which case bindings inside these formats 1079 determine what format is used. This is further described in the 1080 following sections. 1082 6.3.1. List Compression 1084 The TCP options in the uncompressed packet can be represented as an 1085 ordered list, whose order and presence are usually constant between 1086 packets. The generic structure of such a list is as follows: 1088 +--------+--------+--...--+--------+ 1089 list: | item 1 | item 2 | | item n | 1090 +--------+--------+--...--+--------+ 1092 To compress this list, ROHC-TCP uses a list compression scheme, which 1093 compresses each of these items individually and combines them into a 1094 compressed list. 1096 The basic principles of list-based compression are the following: 1098 1) When a context is being initialized, a complete representation 1099 of the compressed list of options is transmitted. All options 1100 that have any content are present in the compressed list of items 1101 sent by the compressor. 1103 Then, once the context has been initialized: 1105 2) When the structure AND the content of the list are unchanged, 1106 no information about the list is sent in compressed headers. 1108 3) When the structure of the list is constant, and when only the 1109 content defined within the irregular format for one or more 1110 options is changed, no information about the list needs to be sent 1111 in compressed base headers; the irregular content is sent as part 1112 of the irregular chain, as described in Section 6.3.6. 1114 4) When the structure of the list changes, a compressed list is 1115 sent in the compressed base header, including a representation of 1116 its structure and order. Content defined within the irregular 1117 format of an option can still be sent as part of the irregular 1118 chain (as described in Section 6.3.6), provided that the item 1119 content is not part of the compressed list. 1121 6.3.2. Table-Based Item Compression 1123 The Table-based item compression compresses individual items sent in 1124 compressed lists. The compressor assigns a unique identifier, 1125 "Index", to each item, "Item", of a list. 1127 Compressor Logic 1129 The compressor conceptually maintains an item table containing all 1130 items, indexed using "Index". The (Index, Item) pair is sent 1131 together in compressed lists until the compressor gains enough 1132 confidence that the decompressor has observed the mapping between 1133 items and their respective index. Confidence is obtained from the 1134 reception of an acknowledgment from the decompressor, or by 1135 sending (Index, Item) pairs using the optimistic approach. Once 1136 confidence is obtained, the index alone is sent in compressed 1137 lists to indicate the presence of the item corresponding to this 1138 index. 1140 The compressor may reassign an existing index to a new item, by 1141 re-establishing the mapping using the procedure described above. 1143 Decompressor Logic 1145 The decompressor conceptually maintains an item table that 1146 contains all (Index, Item) pairs received. The item table is 1147 updated whenever an (Index, Item) pair is received and 1148 decompression is successfully verified using the CRC. The 1149 decompressor retrieves the item from the table whenever an index 1150 without an accompanying item is received. 1152 If an index without an accompanying item is received and the 1153 decompressor does not have any context for this index, the header 1154 MUST be discarded and a NACK SHOULD be sent. 1156 6.3.3. Encoding of Compressed Lists 1158 Each item present in a compressed list is represented by: 1160 o an index into the table of items 1162 o a presence bit indicating if a compressed representation of the 1163 item is present in the list 1165 o an item (if the presence bit is set) 1167 Decompression of an item will fail if the presence bit is not set and 1168 the decompressor has no entry in the context for that item. 1170 A compressed list of TCP options uses the following encoding: 1172 0 1 2 3 4 5 6 7 1173 +---+---+---+---+---+---+---+---+ 1174 | Reserved |PS | m | 1175 +---+---+---+---+---+---+---+---+ 1176 | XI_1, ..., XI_m | m octets, or m * 4 bits 1177 / --- --- --- ---/ 1178 | : Padding : if PS = 0 and m is odd 1179 +---+---+---+---+---+---+---+---+ 1180 | | 1181 / item_1, ..., item_n / variable 1182 | | 1183 +---+---+---+---+---+---+---+---+ 1185 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1186 discard the packet. 1188 PS: Indicates size of XI fields: 1190 PS = 0 indicates 4-bit XI fields; 1192 PS = 1 indicates 8-bit XI fields. 1194 m: Number of XI item(s) in the compressed list. 1196 XI_1, ..., XI_m: m XI items. Each XI represents one TCP option in 1197 the uncompressed packet, in the same order as they appear in the 1198 uncompressed packet. 1200 The format of an XI item is as follows: 1202 +---+---+---+---+ 1203 PS = 0: | X | Index | 1204 +---+---+---+---+ 1206 0 1 2 3 4 5 6 7 1207 +---+---+---+---+---+---+---+---+ 1208 PS = 1: | X | Reserved | Index | 1209 +---+---+---+---+---+---+---+---+ 1211 X: Indicates whether the item is present in the list: 1213 X = 1 indicates that the item corresponding to the Index is 1214 sent in the item_1, ..., item_n list; 1216 X = 0 indicates that the item corresponding to the Index is 1217 not sent and is instead included in the irregular chain. 1219 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1220 discard the packet. 1222 Index: An index into the item table. See Section 6.3.4. 1224 When 4-bit XI items are used, the XI items are placed in octets 1225 in the following manner: 1227 0 1 2 3 4 5 6 7 1228 +---+---+---+---+---+---+---+---+ 1229 | XI_k | XI_k + 1 | 1230 +---+---+---+---+---+---+---+---+ 1232 Padding: A 4-bit padding field is present when PS = 0 and the 1233 number of XIs is odd. The Padding field MUST be set to zero; 1234 otherwise, the decompressor MUST discard the packet. 1236 Item 1, ..., item n: Each item corresponds to an XI with X = 1 in 1237 XI 1, ..., XI m. The format of the entries in the item list is 1238 described in Section 6.3. The compressed format(s) suffixed by 1239 "_list_item" in the encoding methods defines the item inside the 1240 compressed item list. 1242 6.3.4. Item Table Mappings 1244 The item table for TCP options list compression is limited to 16 1245 different items, since it is unlikely that any packet flow will 1246 contain a larger number of unique options. 1248 The mapping between the TCP option type and table indexes are listed 1249 in the table below: 1251 +-----------------+---------------+ 1252 | Option name | Table index | 1253 +-----------------+---------------+ 1254 | NOP | 0 | 1255 | EOL | 1 | 1256 | MSS | 2 | 1257 | WINDOW SCALE | 3 | 1258 | TIMESTAMP | 4 | 1259 | SACK-PERMITTED | 5 | 1260 | SACK | 6 | 1261 | Generic options | 7-15 | 1262 +-----------------+---------------+ 1264 Some TCP options are used more frequently than others. To simplify 1265 their compression, a part of the item table is reserved for these 1266 option types, as shown on the table above. Both the compressor and 1267 the decompressor MUST use these mappings between item and indexes to 1268 (de)compress TCP options when using list compression. 1270 It is expected that the option types for which an index is reserved 1271 in the item table will only appear once in a list. However, if an 1272 option type is detected twice in the same options list and if both 1273 options have a different content, the compressor should compress the 1274 second occurrence of the option type by mapping it to a generic 1275 compressed option. Otherwise, if the options have the exact same 1276 content, the compressor can still use the same table index for both. 1278 The NOP option 1280 The NOP option can appear more than once in the list. However, 1281 since its value is always the same, no context information needs 1282 to be transmitted. Multiple NOP options can thus be mapped to the 1283 same index. Since the NOP option does not have any content when 1284 compressed as a "_list_item", it will never be present in the item 1285 list. For consistency, the compressor should still establish an 1286 entry in the list by setting the presence bit, as done for the 1287 other type of options. 1289 List compression always preserves the original order of each item 1290 in the decompressed list, whether or not the item is present in 1291 the compressed "_list_item" or if multiple items of the same type 1292 can be mapped to the same index, as for the NOP option. 1294 The EOL option 1296 The size of the compressed format for the EOL option can be larger 1297 than one octet, and it is defined so that it includes the option 1298 padding. This is because the EOL should terminate the parsing of 1299 the options, but it can also be followed by padding octets that 1300 all have the value zero. 1302 The Generic option 1304 The Generic option can be used to compress any type of TCP option 1305 that does not have a reserved index in the item table. 1307 6.3.5. Compressed Lists in Dynamic Chain 1309 A compressed list for TCP options that is part of the dynamic chain 1310 (e.g., in IR or IR-DYN packets) must have all its list items present, 1311 i.e., all X-bits in the XI list MUST be set. 1313 6.3.6. Irregular Chain Items for TCP Options 1315 The "_list_item" represents the option inside the compressed item 1316 list, and the "_irregular" format is used for the option fields that 1317 are expected to change with each packet. When an item of the 1318 specified type is present in the current context, these irregular 1319 fields are present in each compressed packet, as part of the 1320 irregular chain. Since many of the TCP option types are not expected 1321 to change for the duration of a flow, many of the "_irregular" 1322 formats are empty. 1324 The irregular chain for TCP options is structured analogously to the 1325 structure of the TCP options in the uncompressed packet. If a 1326 compressed list is present in the compressed packet, then the 1327 irregular chain for TCP options must not contain irregular items for 1328 the list items that are transmitted inside the compressed list (i.e., 1329 items in the list that have the X-bit set in its XI). The items that 1330 are not present in the compressed list, but are present in the 1331 uncompressed list, must have their respective irregular items present 1332 in the irregular chain. 1334 6.3.7. Replication of TCP Options 1336 The entire table of TCP options items is always replicated when using 1337 the IR-CR packet. In the IR-CR packet, the list of options for the 1338 new flow is also transmitted as a compressed list in the IR-CR 1339 packet. 1341 6.4. Profile-Specific Encoding Methods 1343 This section defines encoding methods that are specific to this 1344 profile. These methods are used in the formal definition of the 1345 packet formats in Section 8. 1347 6.4.1. inferred_ip_v4_header_checksum 1349 This encoding method compresses the Header Checksum field of the IPv4 1350 header. This checksum is defined in [RFC0791] as follows: 1352 Header Checksum: 16 bits 1354 A checksum on the header only. Since some header fields change 1355 (e.g., time to live), this is recomputed and verified at each 1356 point that the internet header is processed. 1358 The checksum algorithm is: 1360 The checksum field is the 16 bit one's complement of the one's 1361 complement sum of all 16 bit words in the header. For purposes 1362 of computing the checksum, the value of the checksum field is 1363 zero. 1365 As described above, the header checksum protects individual hops from 1366 processing a corrupted header. When almost all IP header information 1367 is compressed away, and when decompression is verified by a CRC 1368 computed over the original header for every compressed packet, there 1369 is no point in having this additional checksum; instead, it can be 1370 recomputed at the decompressor side. 1372 The "inferred_ip_v4_header_checksum" encoding method thus compresses 1373 the IPv4 header checksum down to a size of zero bits. Using this 1374 encoding method, the decompressor infers the value of this field 1375 using the computation above. 1377 This encoding method implicitly assumes that the compressor will not 1378 process a corrupted header; otherwise, it cannot guarantee that the 1379 checksum as recomputed by the decompressor will be bitwise identical 1380 to its original value before compression. 1382 6.4.2. inferred_mine_header_checksum 1384 This encoding method compresses the minimal encapsulation header 1385 checksum. This checksum is defined in [RFC2004] as follows: 1387 Header Checksum 1389 The 16-bit one's complement of the one's complement sum of all 1390 16-bit words in the minimal forwarding header. For purposes of 1391 computing the checksum, the value of the checksum field is 0. 1392 The IP header and IP payload (after the minimal forwarding 1393 header) are not included in this checksum computation. 1395 The "inferred_mine_header_checksum" encoding method compresses the 1396 minimal encapsulation header checksum down to a size of zero bits, 1397 i.e., no bits are transmitted in compressed headers for this field. 1398 Using this encoding method, the decompressor infers the value of this 1399 field using the above computation. 1401 The motivations and the assumptions for inferring this checksum are 1402 similar to the ones explained above in Section 6.4.1. 1404 6.4.3. inferred_ip_v4_length 1406 This encoding method compresses the Total Length field of the IPv4 1407 header. The Total Length field of the IPv4 header is defined in 1408 [RFC0791] as follows: 1410 Total Length: 16 bits 1412 Total Length is the length of the datagram, measured in octets, 1413 including internet header and data. This field allows the 1414 length of a datagram to be up to 65,535 octets. 1416 The "inferred_ip_v4_length" encoding method compresses the IPv4 Total 1417 Length field down to a size of zero bits. Using this encoding 1418 method, the decompressor infers the value of this field by counting 1419 in octets the length of the entire packet after decompression. 1421 6.4.4. inferred_ip_v6_length 1423 This encoding method compresses the Payload Length field of the IPv6 1424 header. This length field is defined in [RFC2460] as follows: 1426 Payload Length: 16-bit unsigned integer 1428 Length of the IPv6 payload, i.e., the rest of the packet 1429 following this IPv6 header, in octets. (Note that any 1430 extension headers present are considered part of the payload, 1431 i.e., included in the length count.) 1433 The "inferred_ip_v6_length" encoding method compresses the Payload 1434 Length field of the IPv6 header down to a size of zero bits. Using 1435 this encoding method, the decompressor infers the value of this field 1436 by counting in octets the length of the entire packet after 1437 decompression. 1439 6.4.5. inferred_offset 1441 This encoding method compresses the data offset field of the TCP 1442 header. 1444 The "inferred_offset" encoding method is used on the Data Offset 1445 field of the TCP header. This field is defined in [RFC0793] as: 1447 Data Offset: 4 bits 1449 The number of 32 bit words in the TCP Header. This indicates 1450 where the data begins. The TCP header (even one including 1451 options) is an integral number of 32 bits long. 1453 The "inferred_offset" encoding method compresses the Data Offset 1454 field of the TCP header down to a size of zero bits. Using this 1455 encoding method, the decompressor infers the value of this field by 1456 first decompressing the TCP options list, and by then setting: 1458 data offset = (options length / 4) + 5 1460 The equation above uses integer arithmetic. 1462 6.4.6. baseheader_extension_headers 1464 In CO packets (see Section 7.3), the innermost IP header and the TCP 1465 header are combined to create a compressed base header. In some 1466 cases, the IP header will have a number of extension headers between 1467 itself and the TCP header. 1469 To remain formally correct, the base header must define some 1470 representation of these extension headers, which is what this 1471 encoding method is used for. This encoding method skips over all the 1472 extension headers and does not encode any of the fields. Changed 1473 fields in these headers are encoded in the irregular chain. 1475 6.4.7. baseheader_outer_headers 1477 This encoding method, as well as the baseheader_extension_headers 1478 encoding method described above, is needed for the specification to 1479 remain formally correct. It is used in CO packets (see Section 7.3) 1480 to describe tunneling IP headers and their respective extension 1481 headers (i.e., all headers located before the innermost IP header). 1483 This encoding method skips over all the fields in these headers and 1484 does not perform any encoding. Changed fields in outer headers are 1485 instead handled by the irregular chain. 1487 6.4.8. Scaled Encoding of Fields 1489 Some header fields will exhibit a change pattern where the field 1490 increases by a constant value or by multiples of the same value. 1492 Examples of fields that may have this behavior are the TCP Sequence 1493 Number and the TCP Acknowledgment Number. For such fields, ROHC-TCP 1494 provides the means to downscale the field value before applying LSB 1495 encoding, which allows the compressor to transmit fewer bits. 1497 To be able to use scaled encoding, the field is required to fulfill 1498 the following equation: 1500 unscaled_value = scaling_factor * scaled_value + residue 1502 To use the scaled encoding, the compressor must be confident that the 1503 decompressor has established values for the "residue" and the 1504 "scaling_factor", so that it can correctly decompress the field when 1505 only an LSB-encoded "scaled_value" is present in the compressed 1506 packet. 1508 Once the compressor is confident that the value of the scaling_factor 1509 and the value of the residue have been established in the 1510 decompressor, the compressor may send compressed packets using the 1511 scaled representation of the field. The compressor MUST NOT use 1512 scaled encoding with the value of the scaling_factor set to zero. 1514 If the compressor detects that the value of the residue has changed, 1515 or if the compressor uses a different value for the scaling factor, 1516 it MUST NOT use scaled encoding until it is confident that the 1517 decompressor has received the new value(s) of these fields. 1519 When the unscaled value of the field wraps around, the value of the 1520 residue is likely to change, even if the scaling_factor remains 1521 constant. In such a case, the compressor must act in the same way as 1522 for any other change in the residue. 1524 The following subsections describe how the scaled encoding is applied 1525 to specific fields in ROHC-TCP, in particular, how the scaling_factor 1526 and residue values are established for the different fields. 1528 6.4.8.1. Scaled TCP Sequence Number Encoding 1530 For some TCP flows, such as data transfers, the payload size will be 1531 constant over periods of time. For such flows, the TCP Sequence 1532 Number is bound to increase by multiples of the payload size between 1533 packets, which means that this field can be a suitable target for 1534 scaled encoding. When using this encoding, the payload size will be 1535 used as the scaling factor (i.e., as the value for scaling_factor) of 1536 this encoding. This means that the scaling factor does not need to 1537 be explicitly transmitted, but is instead inferred from the length of 1538 the payload in the compressed packet. 1540 Establishing scaling_factor: 1542 The scaling factor is established by sending unscaled TCP Sequence 1543 Number bits, so that the decompressor can infer the scaling_factor 1544 from the payload size. 1546 Establishing residue: 1548 The residue is established identically as the scaling_factor, 1549 i.e., by sending unscaled TCP Sequence Number bits. 1551 A detailed specification of how the TCP Sequence Number uses the 1552 scaled encoding can be found in the definitions of the packet 1553 formats, in Section 8.2. 1555 6.4.8.2. Scaled Acknowledgment Number Encoding 1557 Similar to the pattern exhibited by the TCP Sequence Number, the 1558 expected increase in the TCP Acknowledgment Number is often constant 1559 and is therefore suitable for scaled encoding. 1561 For the TCP Acknowledgment Number, the scaling factor depends on the 1562 size of packets flowing in the opposite direction; this information 1563 might not be available to the compressor/decompressor pair. For this 1564 reason, ROHC-TCP uses an explicitly transmitted scaling factor to 1565 compress the TCP Acknowledgment Number. 1567 Establishing scaling_factor: 1569 The scaling factor is established by explicitly transmitting the 1570 value of the scaling factor (called ack_stride in the formal 1571 notation in Section 8.2) to the decompressor, using one of the 1572 packet types that can carry this information. 1574 Establishing residue: 1576 The scaling residue is established by sending unscaled TCP 1577 Acknowledgment Number bits, so that the decompressor can infer its 1578 value from the unscaled value and the scaling factor (ack_stride). 1580 A detailed specification of how the TCP Acknowledgment Number uses 1581 the scaled encoding can be found in the definitions of the packet 1582 formats, in Section 8.2. 1584 The compressor MAY use the scaled acknowledgment number encoding; 1585 what value it will use as the scaling factor is up to the compressor 1586 implementation. In the case where there is a co-located decompressor 1587 processing packets of the same TCP flow in the opposite direction, 1588 the scaling factor for the sequence number used for that flow can be 1589 used by the compressor to determine a suitable scaling factor for the 1590 TCP Acknowledgment number for this flow. 1592 6.5. Encoding Methods With External Parameters 1594 A number of encoding methods in Section 8.2 have one or more 1595 arguments for which the derivation of the parameter's value is 1596 outside the scope of the ROHC-FN specification of the header formats. 1597 This section lists the encoding methods together with a definition of 1598 each of their parameters. 1600 o esp_null(next_header_value): 1602 next_header_value: Set to the value of the Next Header field 1603 located in the ESP trailer, usually 12 octets from the end of 1604 the packet. Compression of null-encrypted ESP headers should 1605 only be performed when the compressor has prior knowledge of 1606 the exact location of the Next Header field. 1608 o ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn): 1610 is_innermost: This Boolean flag is set to true when processing 1611 the innermost IP header; otherwise, it is set to false. 1613 ttl_irregular_chain_flag: This parameter must be set to the 1614 value that was used for the corresponding 1615 "ttl_irregular_chain_flag" parameter of the "co_baseheader" 1616 encoding method (as defined below) when extracting the 1617 irregular chain for a compressed header; otherwise, it is set 1618 to zero and ignored for other types of chains. 1620 ip_inner_ecn: This parameter is bound by the encoding method, 1621 and therefore it should be undefined when calling this encoding 1622 method. This value is then used to bind the corresponding 1623 parameter in the "tcp" encoding method, as its value is needed 1624 when processing the irregular chain for TCP. See the 1625 definition of the "ip_inner_ecn" parameter for the "tcp" 1626 encoding method below. 1628 o ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn, 1629 ip_id_behavior_value): 1631 See definition of arguments for "ipv6" above 1633 ip_id_behavior_value: Set to a 2-bit integer value, using one 1634 of the constants whose name begins with the prefix 1635 IP_ID_BEHAVIOR_ and as defined in Section 8.2. 1637 o tcp_opt_eol(nbits): 1639 nbits: This parameter is set to the length of the padding data 1640 located after the EOL option type octet to the end of the TCP 1641 options in the uncompressed header. 1643 o tcp_opt_sack(ack_value): 1645 ack_value: Set to the value of the Acknowledgment Number field 1646 of the TCP header. 1648 o tcp(payload_size, ack_stride_value, ip_inner_ecn): 1650 payload_size: Set to the length (in octets) of the payload 1651 following the TCP header. 1653 ack_stride_value: This parameter is the scaling factor used 1654 when scaling the TCP Acknowledgment Number. Its value is set 1655 by the compressor implementation. See Section 6.4.8.2 for 1656 recommendations on how to set this value. 1658 ip_inner_ecn: This parameter binds with the value given to the 1659 corresponding "ip_inner_ecn" parameter by the "ipv4" or the 1660 "ipv6" encoding method when processing the innermost IP header 1661 of this packet. See also the definition of the "ip_inner_ecn" 1662 parameter to the "ipv6" and "ipv4" encoding method above. 1664 o co_baseheader(payload_size, ack_stride_value, 1665 ttl_irregular_chain_flag, ip_id_behavior_value): 1667 payload_size: Set to the length (in octets) of the payload 1668 following the TCP header. 1670 ack_stride_value: This parameter is the scaling factor used 1671 when scaling the TCP Acknowledgment Number. Its value is set 1672 by the compressor implementation. See Section 6.4.8.2 for 1673 recommendations on how to set this value. 1675 ttl_irregular_chain_flag: This parameter is set to one if the 1676 TTL/Hop Limit of an outer header has changed compared to its 1677 reference in the context; otherwise, it is set to zero. The 1678 value used for this parameter is also used for the 1679 "ttl_irregular_chain_flag" argument for the "ipv4" and "ipv6" 1680 encoding methods when processing the irregular chain, as 1681 defined above for the "ipv6" and "ipv4" encoding methods. 1683 ip_id_behavior_value: Set to a 2-bit integer value, using one 1684 of the constants whose name begins with the prefix 1685 IP_ID_BEHAVIOR_ and as defined in Section 8.2. 1687 7. Packet Types (Normative) 1689 ROHC-TCP uses three different packet types: the Initialization and 1690 Refresh (IR) packet type, the Context Replication (IR-CR) packet 1691 type, and the Compressed (CO) packet type. 1693 Each packet type defines a number of packet formats: two packet 1694 formats are defined for the IR type, one packet format is defined for 1695 the IR-CR type, and two sets of eight base header formats are defined 1696 for the CO type with one additional format that is common to both 1697 sets. 1699 The profile identifier for ROHC-TCP is 0x0006. 1701 7.1. Initialization and Refresh (IR) Packets 1703 ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets 1704 as defined in [RFC5795] (Sections 5.2.2.1 and 5.2.2.2, respectively). 1706 Packet type: IR 1708 This packet type communicates the static part and the dynamic part 1709 of the context. 1711 For the ROHC-TCP IR packet, the value of the x bit MUST be set to 1712 one. It has the following format, which corresponds to the 1713 "Header" and "Payload" fields described in Section 5.2.1 of 1714 [RFC5795]: 1716 0 1 2 3 4 5 6 7 1717 --- --- --- --- --- --- --- --- 1718 : Add-CID octet : if for small CIDs and (CID != 0) 1719 +---+---+---+---+---+---+---+---+ 1720 | 1 1 1 1 1 1 0 1 | IR type octet 1721 +---+---+---+---+---+---+---+---+ 1722 : : 1723 / 0-2 octets of CID / 1-2 octets if for large CIDs 1724 : : 1725 +---+---+---+---+---+---+---+---+ 1726 | Profile = 0x06 | 1 octet 1727 +---+---+---+---+---+---+---+---+ 1728 | CRC | 1 octet 1729 +---+---+---+---+---+---+---+---+ 1730 | | 1731 / Static chain / variable length 1732 | | 1733 - - - - - - - - - - - - - - - - 1734 | | 1735 / Dynamic chain / variable length 1736 | | 1737 - - - - - - - - - - - - - - - - 1738 | | 1739 / Payload / variable length 1740 | | 1741 - - - - - - - - - - - - - - - - 1743 CRC: 8-bit CRC, computed according to Section 5.3.1.1. of 1744 [RFC5795]. The CRC covers the entire IR header, thus excluding 1745 payload, padding, and feedback, if any. 1747 Static chain: See Section 6.2. 1749 Dynamic chain: See Section 6.2. 1751 Payload: The payload of the corresponding original packet, if any. 1752 The payload consists of all data after the last octet of the TCP 1753 header to the end of the uncompressed packet. The presence of a 1754 payload is inferred from the packet length. 1756 Packet type: IR-DYN 1758 This packet type communicates the dynamic part of the context. 1760 The ROHC-TCP IR-DYN packet has the following format, which 1761 corresponds to the "Header" and "Payload" fields described in 1762 Section 5.2.1 of [RFC5795]: 1764 0 1 2 3 4 5 6 7 1765 --- --- --- --- --- --- --- --- 1766 : Add-CID octet : if for small CIDs and (CID != 0) 1767 +---+---+---+---+---+---+---+---+ 1768 | 1 1 1 1 1 0 0 0 | IR-DYN type octet 1769 +---+---+---+---+---+---+---+---+ 1770 : : 1771 / 0-2 octets of CID / 1-2 octets if for large CIDs 1772 : : 1773 +---+---+---+---+---+---+---+---+ 1774 | Profile = 0x06 | 1 octet 1775 +---+---+---+---+---+---+---+---+ 1776 | CRC | 1 octet 1777 +---+---+---+---+---+---+---+---+ 1778 | | 1779 / Dynamic chain / variable length 1780 | | 1781 - - - - - - - - - - - - - - - - 1782 | | 1783 / Payload / variable length 1784 | | 1785 - - - - - - - - - - - - - - - - 1787 CRC: 8-bit CRC, computed according to Section 5.3.1.1 of 1788 [RFC5795]. The CRC covers the entire IR-DYN header, thus 1789 excluding payload, padding, and feedback, if any. 1791 Dynamic chain: See Section 6.2. 1793 Payload: The payload of the corresponding original packet, if any. 1794 The payload consists of all data after the last octet of the TCP 1795 header to end of the uncompressed packet. The presence of a 1796 payload is inferred from the packet length. 1798 7.2. Context Replication (IR-CR) Packets 1800 Context replication requires a dedicated IR packet format that 1801 uniquely identifies the IR-CR packet for the ROHC-TCP profile. This 1802 section defines the profile-specific part of the IR-CR packet 1803 [RFC4164]. 1805 Packet type: IR-CR 1807 This packet type communicates a reference to a base context along 1808 with the static and dynamic parts of the replicated context that 1809 differs from the base context. 1811 The ROHC-TCP IR-CR packet follows the general format of the ROHC 1812 IR-CR packet, as defined in [RFC4164], Section 3.5.2. With 1813 consideration to the extensibility of the IR packet type defined in 1814 [RFC5795], the ROHC-TCP profile supports context replication through 1815 the profile-specific part of the IR packet. This is achieved using 1816 the bit (x) left in the IR header for "Profile specific information". 1817 For ROHC-TCP, this bit is defined as a flag indicating whether this 1818 packet is an IR packet or an IR-CR packet. For the ROHC-TCP IR-CR 1819 packet, the value of the x bit MUST be set to zero. 1821 The ROHC-TCP IR-CR has the following format, which corresponds to the 1822 "Header" and "Payload" fields described in Section 5.2.1 of 1823 [RFC5795]: 1825 0 1 2 3 4 5 6 7 1826 --- --- --- --- --- --- --- --- 1827 : Add-CID octet : if for small CIDs and (CID != 0) 1828 +---+---+---+---+---+---+---+---+ 1829 | 1 1 1 1 1 1 0 0 | IR-CR type octet 1830 +---+---+---+---+---+---+---+---+ 1831 : : 1832 / 0-2 octets of CID / 1-2 octets if for large CIDs 1833 : : 1834 +---+---+---+---+---+---+---+---+ 1835 | Profile = 0x06 | 1 octet 1836 +---+---+---+---+---+---+---+---+ 1837 | CRC | 1 octet 1838 +---+---+---+---+---+---+---+---+ 1839 | B | CRC7 | 1 octet 1840 +---+---+---+---+---+---+---+---+ 1841 : Reserved | Base CID : 1 octet, for small CID, if B=1 1842 +---+---+---+---+---+---+---+---+ 1843 : : 1844 / Base CID / 1-2 octets, for large CIDs, 1845 : : if B=1 1846 +---+---+---+---+---+---+---+---+ 1847 | | 1848 / Replicate chain / variable length 1849 | | 1850 - - - - - - - - - - - - - - - - 1851 | | 1852 / Payload / variable length 1853 | | 1854 - - - - - - - - - - - - - - - - 1856 B: B = 1 indicates that the Base CID field is present. 1858 CRC: This CRC covers the entire IR-CR header, thus excluding 1859 payload, padding, and feedback, if any. This 8-bit CRC is 1860 calculated according to Section 5.3.1.1 of [RFC5795]. 1862 CRC7: The CRC over the original, uncompressed, header. Calculated 1863 according to Section 3.5.1.1 of [RFC4164]. 1865 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1866 discard the packet. 1868 Base CID: CID of base context. Encoded according to [RFC4164], 1869 Section 3.5.3. 1871 Replicate chain: See Section 6.2. 1873 Payload: The payload of the corresponding original packet, if any. 1874 The presence of a payload is inferred from the packet length. 1876 7.3. Compressed (CO) Packets 1878 The ROHC-TCP CO packets communicate irregularities in the packet 1879 header. All CO packets carry a CRC and can update the context. 1881 The general format for a compressed TCP header is as follows, which 1882 corresponds to the "Header" and "Payload" fields described in Section 1883 5.2.1 of [RFC5795]: 1885 0 1 2 3 4 5 6 7 1886 --- --- --- --- --- --- --- --- 1887 : Add-CID octet : if for small CIDs and CID 1-15 1888 +---+---+---+---+---+---+---+---+ 1889 | First octet of base header | (with type indication) 1890 +---+---+---+---+---+---+---+---+ 1891 : : 1892 / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 1893 : : 1894 +---+---+---+---+---+---+---+---+ 1895 / Remainder of base header / variable number of octets 1896 +---+---+---+---+---+---+---+---+ 1897 : Irregular chain : 1898 / (including irregular chain / variable 1899 : items for TCP options) : 1900 --- --- --- --- --- --- --- --- 1901 | | 1902 / Payload / variable length 1903 | | 1904 - - - - - - - - - - - - - - - - 1906 Base header: The complete set of base headers is defined in 1907 Section 8. 1909 Irregular chain: See Section 6.2 and Section 6.3.6. 1911 Payload: The payload of the corresponding original packet, if any. 1912 The presence of a payload is inferred from the packet length. 1914 8. Header Formats (Normative) 1916 This section describes the set of compressed TCP/IP packet formats. 1917 The normative description of the packet formats is given using the 1918 formal notation for ROHC profiles defined in [RFC4997]. The formal 1919 description of the packet formats specifies all of the information 1920 needed to compress and decompress a header relative to the context. 1922 In particular, the notation provides a list of all the fields present 1923 in the uncompressed and compressed TCP/IP headers, and defines how to 1924 map from each uncompressed packet to its compressed equivalent and 1925 vice versa. 1927 8.1. Design Rationale for Compressed Base Headers 1929 The compressed header formats are defined as two separate sets: one 1930 set for the packets where the innermost IP header contains a 1931 sequential IP-ID (either network byte order or byte swapped), and one 1932 set for the packets without sequential IP-ID (either random, zero, or 1933 no IP-ID). 1935 These two sets of header formats are referred to as the "sequential" 1936 and the "random" set of header formats, respectively. 1938 In addition, there is one compressed format that is common to both 1939 sets of header formats and that can thus be used regardless of the 1940 type of IP-ID behavior. This format can transmit rarely changing 1941 fields and also send the frequently changing fields coded in variable 1942 lengths. It can also change the value of control fields such as 1943 IP-ID behavior and ECN behavior. 1945 All compressed base headers contain a 3-bit CRC, unless they update 1946 control fields such as "ip_id_behavior" or "ecn_used" that affect the 1947 interpretation of subsequent headers. Headers that can modify these 1948 control fields carry a 7-bit CRC instead. 1950 When discussing LSB-encoded fields below, "p" equals the 1951 "offset_param" and "k" equals the "num_lsbs_param" in [RFC4997]. 1953 The encoding methods used in the compressed base headers are based on 1954 the following design criteria: 1956 o MSN 1958 Since the MSN is a number generated by the compressor, it only 1959 needs to be large enough to ensure robust operation and to 1960 accommodate a small amount of reordering [RFC4163]. Therefore, 1961 each compressed base header has an MSN field that is LSB- 1962 encoded with k=4 and p=4 to handle a reordering depth of up to 1963 4 packets. Additional guidance to improve robustness when 1964 reordering is possible can be found in [RFC4224]. 1966 o TCP Sequence Number 1968 ROHC-TCP has the capability to handle bulk data transfers 1969 efficiently, for which the sequence number is expected to 1970 increase by about 1460 octets (which can be represented by 11 1971 bits). For the compressed base headers to handle 1972 retransmissions (i.e., negative delta to the sequence number), 1973 the LSB interpretation interval has to handle negative offsets 1974 about as large as positive offsets, which means that one more 1975 bit is needed. 1977 Also, for ROHC-TCP to be robust to losses, two additional bits 1978 are added to the LSB encoding of the sequence number. This 1979 means that the base headers should contain at least 14 bits of 1980 LSB-encoded sequence number when present. According to the 1981 logic above, the LSB offset value is set to be as large as the 1982 positive offset, i.e., p = 2^(k-1)-1. 1984 o TCP Acknowledgment Number 1986 The design criterion for the acknowledgment number is similar 1987 to that of the TCP Sequence Number. However, often only every 1988 other data packet is acknowledged, which means that the 1989 expected delta value is twice as large as for sequence numbers. 1991 Therefore, at least 15 bits of acknowledgment number should be 1992 used in compressed base headers. Since the acknowledgment 1993 number is expected to constantly increase, and the only 1994 exception to this is packet reordering (either on the ROHC 1995 channel [RFC3759] or prior to the compression point), the 1996 negative offset for LSB encoding is set to be 1/4 of the total 1997 interval, i.e., p = 2^(k-2)-1. 1999 o TCP Window 2001 The TCP Window field is expected to increase in increments of 2002 similar size as the TCP Sequence Number, and therefore the 2003 design criterion for the TCP window is to send at least 14 bits 2004 when used. 2006 o IP-ID 2007 For the "sequential" set of packet formats, all the compressed 2008 base headers contain LSB-encoded IP-ID offset bits, where the 2009 offset is the difference between the value of the MSN field and 2010 the value of the IP-ID field. The requirement is that at least 2011 3 bits of IP-ID should always be present, but it is preferable 2012 to use 4 to 7 bits. When k=3 then p=1, and if k>3 then p=3 2013 since the offset is expected to increase most of the time. 2015 Each set of header formats contains eight different compressed base 2016 headers. The reason for having this large number of header formats 2017 is that the TCP Sequence Number, TCP Acknowledgment Number, and TCP 2018 Window are frequently changing in a non-linear pattern. 2020 The design of the header formats is derived from the field behavior 2021 analysis found in [RFC4413]. 2023 All of the compressed base headers transmit LSB-encoded MSN bits, the 2024 TCP Push flag, and a CRC, and in addition to this, all the base 2025 headers in the sequential packet format set contain LSB-encoded IP-ID 2026 bits. 2028 The following header formats exist in both the sequential and random 2029 packet format sets: 2031 o Format 1: This header format carries changes to the TCP Sequence 2032 Number and is expected to be used on the downstream of a data 2033 transfer. 2035 o Format 2: This header format carries the TCP Sequence Number in 2036 scaled form and is expected to be useful for the downstream of a 2037 data transfer where the payload size is constant for multiple 2038 packets. 2040 o Format 3: This header format carries changes in the TCP 2041 Acknowledgment Number and is expected to be useful for the 2042 acknowledgment direction of a data transfer. 2044 o Format 4: This header format is similar to format 3, but carries a 2045 scaled TCP Acknowledgment Number. 2047 o Format 5: This header format carries both the TCP Sequence Number 2048 and the TCP Acknowledgment Number and is expected to be useful for 2049 flows that send data in both directions. 2051 o Format 6: This header format is similar to format 5, but carries 2052 the TCP Sequence Number in scaled form, when the payload size is 2053 static for certain intervals in a data flow. 2055 o Format 7: This header format carries changes to both the TCP 2056 Acknowledgment Number and the TCP Window and is expected to be 2057 useful for the acknowledgment flows of data connections. 2059 o Format 8: This header format is used to convey changes to some of 2060 the more seldom changing fields in the TCP flow, such as ECN 2061 behavior, RST/SYN/FIN flags, the TTL/Hop Limit, and the TCP 2062 options list. This format carries a 7-bit CRC, since it can 2063 change the structure of the contents of the irregular chain for 2064 subsequent packets. Note that this can be seen as a reduced form 2065 of the common packet format. 2067 o Common header format: The common header format can be used for all 2068 kinds of IP-ID behavior and should be useful when some of the more 2069 rarely changing fields in the IP or TCP header change. Since this 2070 header format can update control fields that decide how the 2071 decompressor interprets packets, it carries a 7-bit CRC to reduce 2072 the probability of context corruption. This header can basically 2073 convey changes to any of the dynamic fields in the IP and TCP 2074 headers, and it uses a large set of flags to provide information 2075 about which fields are present in the header format. 2077 8.2. Formal Definition of Header Formats 2079 // NOTE: The irregular, static, and dynamic chains (see Section 6.2) 2080 // are defined across multiple encoding methods and are embodied 2081 // in the correspondingly named formats within those encoding 2082 // methods. In particular, note that the static and dynamic 2083 // chains ordinarily go together. The uncompressed fields are 2084 // defined across these two formats combined, rather than in one 2085 // or the other of them. The irregular chain items are likewise 2086 // combined with a baseheader format. 2088 //////////////////////////////////////////// 2089 // Constants 2090 //////////////////////////////////////////// 2092 IP_ID_BEHAVIOR_SEQUENTIAL = 0; 2093 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; 2094 IP_ID_BEHAVIOR_RANDOM = 2; 2095 IP_ID_BEHAVIOR_ZERO = 3; 2097 //////////////////////////////////////////// 2098 // Global control fields 2099 //////////////////////////////////////////// 2101 CONTROL { 2102 ecn_used [ 1 ]; 2103 msn [ 16 ]; 2104 // ip_id fields are for innermost IP header only 2105 ip_id_offset [ 16 ]; 2106 ip_id_behavior_innermost [ 2 ]; 2107 // ACK-related 2108 ack_stride [ 32 ]; 2109 ack_number_scaled [ 32 ]; 2110 ack_number_residue [ 32 ]; 2111 seq_number_scaled [ 32 ]; 2112 seq_number_residue [ 32 ]; 2113 } 2115 /////////////////////////////////////////////// 2116 // Encoding methods not specified in FN syntax 2117 /////////////////////////////////////////////// 2119 list_tcp_options "defined in Section 6.3.3"; 2120 inferred_ip_v4_header_checksum "defined in Section 6.4.1"; 2121 inferred_mine_header_checksum "defined in Section 6.4.2"; 2122 inferred_ip_v4_length "defined in Section 6.4.3"; 2123 inferred_ip_v6_length "defined in Section 6.4.4"; 2124 inferred_offset "defined in Section 6.4.5"; 2125 baseheader_extension_headers "defined in Section 6.4.6"; 2126 baseheader_outer_headers "defined in Section 6.4.7"; 2128 //////////////////////////////////////////// 2129 // General encoding methods 2130 //////////////////////////////////////////// 2132 static_or_irreg(flag, width) 2133 { 2134 UNCOMPRESSED { 2135 field [ width ]; 2136 } 2138 COMPRESSED irreg_enc { 2139 field =:= irregular(width) [ width ]; 2140 ENFORCE(flag == 1); 2141 } 2143 COMPRESSED static_enc { 2144 field =:= static [ 0 ]; 2145 ENFORCE(flag == 0); 2146 } 2147 } 2149 zero_or_irreg(flag, width) 2150 { 2151 UNCOMPRESSED { 2152 field [ width ]; 2153 } 2155 COMPRESSED non_zero { 2156 field =:= irregular(width) [ width ]; 2157 ENFORCE(flag == 0); 2158 } 2160 COMPRESSED zero { 2161 field =:= uncompressed_value(width, 0) [ 0 ]; 2162 ENFORCE(flag == 1); 2163 } 2164 } 2166 variable_length_32_enc(flag) 2167 { 2168 UNCOMPRESSED { 2169 field [ 32 ]; 2170 } 2172 COMPRESSED not_present { 2173 field =:= static [ 0 ]; 2174 ENFORCE(flag == 0); 2175 } 2177 COMPRESSED lsb_8_bit { 2178 field =:= lsb(8, 63) [ 8 ]; 2179 ENFORCE(flag == 1); 2180 } 2182 COMPRESSED lsb_16_bit { 2183 field =:= lsb(16, 16383) [ 16 ]; 2184 ENFORCE(flag == 2); 2185 } 2187 COMPRESSED irreg_32_bit { 2188 field =:= irregular(32) [ 32 ]; 2189 ENFORCE(flag == 3); 2190 } 2191 } 2193 optional32(flag) 2194 { 2195 UNCOMPRESSED { 2196 item [ 0, 32 ]; 2197 } 2198 COMPRESSED present { 2199 item =:= irregular(32) [ 32 ]; 2200 ENFORCE(flag == 1); 2201 } 2203 COMPRESSED not_present { 2204 item =:= compressed_value(0, 0) [ 0 ]; 2205 ENFORCE(flag == 0); 2206 } 2207 } 2209 lsb_7_or_31 2210 { 2211 UNCOMPRESSED { 2212 item [ 32 ]; 2213 } 2215 COMPRESSED lsb_7 { 2216 discriminator =:= '0' [ 1 ]; 2217 item =:= lsb(7, 8) [ 7 ]; 2218 } 2220 COMPRESSED lsb_31 { 2221 discriminator =:= '1' [ 1 ]; 2222 item =:= lsb(31, 256) [ 31 ]; 2223 } 2224 } 2226 opt_lsb_7_or_31(flag) 2227 { 2228 UNCOMPRESSED { 2229 item [ 0, 32 ]; 2230 } 2232 COMPRESSED present { 2233 item =:= lsb_7_or_31 [ 8, 32 ]; 2234 ENFORCE(flag == 1); 2235 } 2237 COMPRESSED not_present { 2238 item =:= compressed_value(0, 0) [ 0 ]; 2239 ENFORCE(flag == 0); 2240 } 2241 } 2243 crc3(data_value, data_length) 2244 { 2245 UNCOMPRESSED { 2246 } 2248 COMPRESSED { 2249 crc_value =:= 2250 crc(3, 0x06, 0x07, data_value, data_length) [ 3 ]; 2251 } 2252 } 2254 crc7(data_value, data_length) 2255 { 2256 UNCOMPRESSED { 2257 } 2259 COMPRESSED { 2260 crc_value =:= 2261 crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ]; 2262 } 2263 } 2265 one_bit_choice 2266 { 2267 UNCOMPRESSED { 2268 field [ 1 ]; 2269 } 2271 COMPRESSED zero { 2272 field [ 1 ]; 2273 ENFORCE(field.UVALUE == 0); 2274 } 2276 COMPRESSED nonzero { 2277 field [ 1 ]; 2278 ENFORCE(field.UVALUE == 1); 2279 } 2280 } 2282 // Encoding method for updating a scaled field and its associated 2283 // control fields. Should be used both when the value is scaled 2284 // or unscaled in a compressed format. 2285 // Does not have an uncompressed side. 2286 field_scaling(stride_value, scaled_value, unscaled_value, residue_value) 2287 { 2288 UNCOMPRESSED { 2289 // Nothing 2290 } 2292 COMPRESSED no_scaling { 2293 ENFORCE(stride_value == 0); 2294 ENFORCE(residue_value == unscaled_value); 2295 ENFORCE(scaled_value == 0); 2296 } 2298 COMPRESSED scaling_used { 2299 ENFORCE(stride_value != 0); 2300 ENFORCE(residue_value == (unscaled_value % stride_value)); 2301 ENFORCE(unscaled_value == 2302 scaled_value * stride_value + residue_value); 2303 } 2304 } 2306 //////////////////////////////////////////// 2307 // IPv6 Destination options header 2308 //////////////////////////////////////////// 2310 ip_dest_opt 2311 { 2312 UNCOMPRESSED { 2313 next_header [ 8 ]; 2314 length [ 8 ]; 2315 value [ length.UVALUE * 64 + 48 ]; 2316 } 2318 DEFAULT { 2319 length =:= static; 2320 next_header =:= static; 2321 value =:= static; 2322 } 2324 COMPRESSED dest_opt_static { 2325 next_header =:= irregular(8) [ 8 ]; 2326 length =:= irregular(8) [ 8 ]; 2327 } 2329 COMPRESSED dest_opt_dynamic { 2330 value =:= 2331 irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; 2332 } 2334 COMPRESSED dest_opt_0_replicate { 2335 discriminator =:= '00000000' [ 8 ]; 2336 } 2338 COMPRESSED dest_opt_1_replicate { 2339 discriminator =:= '10000000' [ 8 ]; 2340 length =:= irregular(8) [ 8 ]; 2341 value =:= 2342 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2343 } 2345 COMPRESSED dest_opt_irregular { 2346 } 2347 } 2349 //////////////////////////////////////////// 2350 // IPv6 Hop-by-Hop options header 2351 //////////////////////////////////////////// 2353 ip_hop_opt 2354 { 2355 UNCOMPRESSED { 2356 next_header [ 8 ]; 2357 length [ 8 ]; 2358 value [ length.UVALUE * 64 + 48 ]; 2359 } 2361 DEFAULT { 2362 length =:= static; 2363 next_header =:= static; 2364 value =:= static; 2365 } 2367 COMPRESSED hop_opt_static { 2368 next_header =:= irregular(8) [ 8 ]; 2369 length =:= irregular(8) [ 8 ]; 2370 } 2372 COMPRESSED hop_opt_dynamic { 2373 value =:= 2374 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2375 } 2377 COMPRESSED hop_opt_0_replicate { 2378 discriminator =:= '00000000' [ 8 ]; 2379 } 2381 COMPRESSED hop_opt_1_replicate { 2382 discriminator =:= '10000000' [ 8 ]; 2383 length =:= irregular(8) [ 8 ]; 2384 value =:= 2385 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2386 } 2388 COMPRESSED hop_opt_irregular { 2389 } 2390 } 2392 //////////////////////////////////////////// 2393 // IPv6 Routing header 2394 //////////////////////////////////////////// 2396 ip_rout_opt 2397 { 2398 UNCOMPRESSED { 2399 next_header [ 8 ]; 2400 length [ 8 ]; 2401 value [ length.UVALUE * 64 + 48 ]; 2402 } 2404 DEFAULT { 2405 length =:= static; 2406 next_header =:= static; 2407 value =:= static; 2408 } 2410 COMPRESSED rout_opt_static { 2411 next_header =:= irregular(8) [ 8 ]; 2412 length =:= irregular(8) [ 8 ]; 2413 value =:= 2414 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2415 } 2417 COMPRESSED rout_opt_dynamic { 2418 } 2420 COMPRESSED rout_opt_0_replicate { 2421 discriminator =:= '00000000' [ 8 ]; 2422 } 2424 COMPRESSED rout_opt_0_replicate { 2425 discriminator =:= '10000000' [ 8 ]; 2426 length =:= irregular(8) [ 8 ]; 2427 value =:= 2428 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2429 } 2431 COMPRESSED rout_opt_irregular { 2432 } 2433 } 2435 //////////////////////////////////////////// 2436 // GRE Header 2437 //////////////////////////////////////////// 2439 optional_checksum(flag_value) 2440 { 2441 UNCOMPRESSED { 2442 value [ 0, 16 ]; 2443 reserved1 [ 0, 16 ]; 2444 } 2446 COMPRESSED cs_present { 2447 value =:= irregular(16) [ 16 ]; 2448 reserved1 =:= uncompressed_value(16, 0) [ 0 ]; 2449 ENFORCE(flag_value == 1); 2450 } 2452 COMPRESSED not_present { 2453 value =:= compressed_value(0, 0) [ 0 ]; 2454 reserved1 =:= compressed_value(0, 0) [ 0 ]; 2455 ENFORCE(flag_value == 0); 2456 } 2457 } 2459 gre_proto 2460 { 2461 UNCOMPRESSED { 2462 protocol [ 16 ]; 2463 } 2465 COMPRESSED ether_v4 { 2466 discriminator =:= compressed_value(1, 0) [ 1 ]; 2467 protocol =:= uncompressed_value(16, 0x0800) [ 0 ]; 2468 } 2470 COMPRESSED ether_v6 { 2471 discriminator =:= compressed_value(1, 1) [ 1 ]; 2472 protocol =:= uncompressed_value(16, 0x86DD) [ 0 ]; 2473 } 2474 } 2476 gre 2477 { 2478 UNCOMPRESSED { 2479 c_flag [ 1 ]; 2480 r_flag =:= uncompressed_value(1, 0) [ 1 ]; 2481 k_flag [ 1 ]; 2482 s_flag [ 1 ]; 2483 reserved0 =:= uncompressed_value(9, 0) [ 9 ]; 2484 version =:= uncompressed_value(3, 0) [ 3 ]; 2485 protocol [ 16 ]; 2486 checksum_and_res [ 0, 32 ]; 2487 key [ 0, 32 ]; 2488 sequence_number [ 0, 32 ]; 2489 } 2491 DEFAULT { 2492 c_flag =:= static; 2493 k_flag =:= static; 2494 s_flag =:= static; 2495 protocol =:= static; 2496 key =:= static; 2497 sequence_number =:= static; 2498 } 2500 COMPRESSED gre_static { 2501 ENFORCE((c_flag.UVALUE == 1 && checksum_and_res.ULENGTH == 32) 2502 || checksum_and_res.ULENGTH == 0); 2503 ENFORCE((s_flag.UVALUE == 1 && sequence_number.ULENGTH == 32) 2504 || sequence_number.ULENGTH == 0); 2505 protocol =:= gre_proto [ 1 ]; 2506 c_flag =:= irregular(1) [ 1 ]; 2507 k_flag =:= irregular(1) [ 1 ]; 2508 s_flag =:= irregular(1) [ 1 ]; 2509 padding =:= compressed_value(4, 0) [ 4 ]; 2510 key =:= optional32(k_flag.UVALUE) [ 0, 32 ]; 2511 } 2513 COMPRESSED gre_dynamic { 2514 checksum_and_res =:= 2515 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2516 sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ]; 2517 } 2519 COMPRESSED gre_0_replicate { 2520 discriminator =:= '00000000' [ 8 ]; 2521 checksum_and_res =:= 2522 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2523 sequence_number =:= 2524 optional32(s_flag.UVALUE) [ 0, 8, 32 ]; 2525 } 2527 COMPRESSED gre_1_replicate { 2528 discriminator =:= '10000' [ 5 ]; 2529 c_flag =:= irregular(1) [ 1 ]; 2530 k_flag =:= irregular(1) [ 1 ]; 2531 s_flag =:= irregular(1) [ 1 ]; 2532 checksum_and_res =:= 2533 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2534 key =:= optional32(k_flag.UVALUE) [ 0, 32 ]; 2535 sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ]; 2536 } 2538 COMPRESSED gre_irregular { 2539 checksum_and_res =:= 2540 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2541 sequence_number =:= 2542 opt_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ]; 2543 } 2544 } 2546 ///////////////////////////////////////////// 2547 // MINE header 2548 ///////////////////////////////////////////// 2550 mine 2551 { 2552 UNCOMPRESSED { 2553 next_header [ 8 ]; 2554 s_bit [ 1 ]; 2555 res_bits [ 7 ]; 2556 checksum [ 16 ]; 2557 orig_dest [ 32 ]; 2558 orig_src [ 0, 32 ]; 2559 } 2561 DEFAULT { 2562 next_header =:= static; 2563 s_bit =:= static; 2564 res_bits =:= static; 2565 checksum =:= inferred_mine_header_checksum; 2566 orig_dest =:= static; 2567 orig_src =:= static; 2568 } 2570 COMPRESSED mine_static { 2571 next_header =:= irregular(8) [ 8 ]; 2572 s_bit =:= irregular(1) [ 1 ]; 2573 // Reserved bits are included to achieve byte-alignment 2574 res_bits =:= irregular(7) [ 7 ]; 2575 orig_dest =:= irregular(32) [ 32 ]; 2576 orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ]; 2577 } 2579 COMPRESSED mine_dynamic { 2580 } 2581 COMPRESSED mine_0_replicate { 2582 discriminator =:= '00000000' [ 8 ]; 2583 } 2585 COMPRESSED mine_1_replicate { 2586 discriminator =:= '10000000' [ 8 ]; 2587 s_bit =:= irregular(1) [ 1 ]; 2588 res_bits =:= irregular(7) [ 7 ]; 2589 orig_dest =:= irregular(32) [ 32 ]; 2590 orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ]; 2591 } 2593 COMPRESSED mine_irregular { 2594 } 2595 } 2597 ///////////////////////////////////////////// 2598 // Authentication Header (AH) 2599 ///////////////////////////////////////////// 2601 ah 2602 { 2603 UNCOMPRESSED { 2604 next_header [ 8 ]; 2605 length [ 8 ]; 2606 res_bits [ 16 ]; 2607 spi [ 32 ]; 2608 sequence_number [ 32 ]; 2609 icv [ length.UVALUE*32-32 ]; 2610 } 2612 DEFAULT { 2613 next_header =:= static; 2614 length =:= static; 2615 res_bits =:= static; 2616 spi =:= static; 2617 sequence_number =:= static; 2618 } 2620 COMPRESSED ah_static { 2621 next_header =:= irregular(8) [ 8 ]; 2622 length =:= irregular(8) [ 8 ]; 2623 spi =:= irregular(32) [ 32 ]; 2624 } 2626 COMPRESSED ah_dynamic { 2627 res_bits =:= irregular(16) [ 16 ]; 2628 sequence_number =:= irregular(32) [ 32 ]; 2629 icv =:= 2630 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2631 } 2633 COMPRESSED ah_0_replicate { 2634 discriminator =:= '00000000' [ 8 ]; 2635 sequence_number =:= irregular(32) [ 32 ]; 2636 icv =:= 2637 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2638 } 2640 COMPRESSED ah_1_replicate { 2641 discriminator =:= '10000000' [ 8 ]; 2642 length =:= irregular(8) [ 8 ]; 2643 res_bits =:= irregular(16) [ 16 ]; 2644 spi =:= irregular(32) [ 32 ]; 2645 sequence_number =:= irregular(32) [ 32 ]; 2646 icv =:= 2647 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2648 } 2650 COMPRESSED ah_irregular { 2651 sequence_number =:= lsb_7_or_31 [ 8, 32 ]; 2652 icv =:= 2653 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2654 } 2655 } 2657 ///////////////////////////////////////////// 2658 // IPv6 Header 2659 ///////////////////////////////////////////// 2661 fl_enc 2662 { 2663 UNCOMPRESSED { 2664 flow_label [ 20 ]; 2665 } 2667 COMPRESSED fl_zero { 2668 discriminator =:= '0' [ 1 ]; 2669 flow_label =:= uncompressed_value(20, 0) [ 0 ]; 2670 reserved =:= '0000' [ 4 ]; 2671 } 2673 COMPRESSED fl_non_zero { 2674 discriminator =:= '1' [ 1 ]; 2675 flow_label =:= irregular(20) [ 20 ]; 2676 } 2678 } 2680 // The is_innermost flag is true if this is the innermost IP header 2681 // If extracting the irregular chain for a compressed packet: 2682 // - ttl_irregular_chain_flag must have the same value as it had when 2683 // processing co_baseheader. 2684 // - ip_inner_ecn is bound in this encoding method and the value that 2685 // it gets bound to should be passed to the tcp encoding method 2686 // For other formats than the irregular chain, these two are ignored 2687 ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn) 2688 { 2689 UNCOMPRESSED { 2690 version =:= uncompressed_value(4, 6) [ 4 ]; 2691 dscp [ 6 ]; 2692 ip_ecn_flags [ 2 ]; 2693 flow_label [ 20 ]; 2694 payload_length [ 16 ]; 2695 next_header [ 8 ]; 2696 ttl_hopl [ 8 ]; 2697 src_addr [ 128 ]; 2698 dst_addr [ 128 ]; 2699 } 2701 DEFAULT { 2702 dscp =:= static; 2703 ip_ecn_flags =:= static; 2704 flow_label =:= static; 2705 payload_length =:= inferred_ip_v6_length; 2706 next_header =:= static; 2707 ttl_hopl =:= static; 2708 src_addr =:= static; 2709 dst_addr =:= static; 2710 } 2712 COMPRESSED ipv6_static { 2713 version_flag =:= '1' [ 1 ]; 2714 reserved =:= '00' [ 2 ]; 2715 flow_label =:= fl_enc [ 5, 21 ]; 2716 next_header =:= irregular(8) [ 8 ]; 2717 src_addr =:= irregular(128) [ 128 ]; 2718 dst_addr =:= irregular(128) [ 128 ]; 2719 } 2721 COMPRESSED ipv6_dynamic { 2722 dscp =:= irregular(6) [ 6 ]; 2723 ip_ecn_flags =:= irregular(2) [ 2 ]; 2724 ttl_hopl =:= irregular(8) [ 8 ]; 2725 } 2726 COMPRESSED ipv6_replicate { 2727 dscp =:= irregular(6) [ 6 ]; 2728 ip_ecn_flags =:= irregular(2) [ 2 ]; 2729 reserved =:= '000' [ 3 ]; 2730 flow_label =:= fl_enc [ 5, 21 ]; 2731 } 2733 COMPRESSED ipv6_outer_without_ttl_irregular { 2734 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2735 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2736 ENFORCE(ttl_irregular_chain_flag == 0); 2737 ENFORCE(is_innermost == false); 2738 } 2740 COMPRESSED ipv6_outer_with_ttl_irregular { 2741 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2742 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2743 ttl_hopl =:= irregular(8) [ 8 ]; 2744 ENFORCE(ttl_irregular_chain_flag == 1); 2745 ENFORCE(is_innermost == false); 2746 } 2748 COMPRESSED ipv6_innermost_irregular { 2749 ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE); 2750 ENFORCE(is_innermost == true); 2751 } 2752 } 2754 ///////////////////////////////////////////// 2755 // IPv4 Header 2756 ///////////////////////////////////////////// 2758 ip_id_enc_dyn(behavior) 2759 { 2760 UNCOMPRESSED { 2761 ip_id [ 16 ]; 2762 } 2764 COMPRESSED ip_id_seq { 2765 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 2766 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 2767 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 2768 ip_id =:= irregular(16) [ 16 ]; 2769 } 2771 COMPRESSED ip_id_random { 2772 ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); 2773 ip_id =:= irregular(16) [ 16 ]; 2775 } 2777 COMPRESSED ip_id_zero { 2778 ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); 2779 ip_id =:= uncompressed_value(16, 0) [ 0 ]; 2780 } 2781 } 2783 ip_id_enc_irreg(behavior) 2784 { 2785 UNCOMPRESSED { 2786 ip_id [ 16 ]; 2787 } 2789 COMPRESSED ip_id_seq { 2790 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 2791 } 2793 COMPRESSED ip_id_seq_swapped { 2794 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 2795 } 2797 COMPRESSED ip_id_rand { 2798 ip_id =:= irregular(16) [ 16 ]; 2799 ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); 2800 } 2802 COMPRESSED ip_id_zero { 2803 ip_id =:= uncompressed_value(16, 0) [ 0 ]; 2804 ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); 2805 } 2806 } 2808 // The is_innermost flag is true if this is the innermost IP header 2809 // If extracting the irregular chain for a compressed packet: 2810 // - ttl_irregular_chain_flag must have the same value as it had when 2811 // processing co_baseheader. 2812 // - ip_inner_ecn is bound in this encoding method and the value that 2813 // it gets bound to should be passed to the tcp encoding method 2814 // For other formats than the irregular chain, these two are ignored 2815 ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn, 2816 ip_id_behavior_value) 2817 { 2818 UNCOMPRESSED { 2819 version =:= uncompressed_value(4, 4) [ 4 ]; 2820 hdr_length =:= uncompressed_value(4, 5) [ 4 ]; 2821 dscp [ 6 ]; 2822 ip_ecn_flags [ 2 ]; 2823 length =:= inferred_ip_v4_length [ 16 ]; 2824 ip_id [ 16 ]; 2825 rf =:= uncompressed_value(1, 0) [ 1 ]; 2826 df [ 1 ]; 2827 mf =:= uncompressed_value(1, 0) [ 1 ]; 2828 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 2829 ttl_hopl [ 8 ]; 2830 protocol [ 8 ]; 2831 checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 2832 src_addr [ 32 ]; 2833 dst_addr [ 32 ]; 2834 } 2836 CONTROL { 2837 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 2838 ENFORCE(innermost_ip.UVALUE == is_innermost); 2839 ip_id_behavior_outer [ 2 ]; 2840 innermost_ip [ 1 ]; 2841 } 2843 DEFAULT { 2844 dscp =:= static; 2845 ip_ecn_flags =:= static; 2846 df =:= static; 2847 ttl_hopl =:= static; 2848 protocol =:= static; 2849 src_addr =:= static; 2850 dst_addr =:= static; 2851 ip_id_behavior_outer =:= static; 2852 } 2854 COMPRESSED ipv4_static { 2855 version_flag =:= '0' [ 1 ]; 2856 reserved =:= '0000000' [ 7 ]; 2857 protocol =:= irregular(8) [ 8 ]; 2858 src_addr =:= irregular(32) [ 32 ]; 2859 dst_addr =:= irregular(32) [ 32 ]; 2860 } 2862 COMPRESSED ipv4_innermost_dynamic { 2863 ENFORCE(is_innermost == 1); 2864 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 2865 reserved =:= '00000' [ 5 ]; 2866 df =:= irregular(1) [ 1 ]; 2867 ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 2868 dscp =:= irregular(6) [ 6 ]; 2869 ip_ecn_flags =:= irregular(2) [ 2 ]; 2870 ttl_hopl =:= irregular(8) [ 8 ]; 2871 ip_id =:= 2872 ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2873 } 2875 COMPRESSED ipv4_outer_dynamic { 2876 ENFORCE(is_innermost == 0); 2877 ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value); 2878 reserved =:= '00000' [ 5 ]; 2879 df =:= irregular(1) [ 1 ]; 2880 ip_id_behavior_outer =:= irregular(2) [ 2 ]; 2881 dscp =:= irregular(6) [ 6 ]; 2882 ip_ecn_flags =:= irregular(2) [ 2 ]; 2883 ttl_hopl =:= irregular(8) [ 8 ]; 2884 ip_id =:= 2885 ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2886 } 2888 COMPRESSED ipv4_innermost_replicate { 2889 ENFORCE(is_innermost == 1); 2890 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 2891 reserved =:= '0000' [ 4 ]; 2892 ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 2893 ttl_flag =:= irregular(1) [ 1 ]; 2894 df =:= irregular(1) [ 1 ]; 2895 dscp =:= irregular(6) [ 6 ]; 2896 ip_ecn_flags =:= irregular(2) [ 2 ]; 2897 ip_id =:= 2898 ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2899 ttl_hopl =:= 2900 static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ]; 2901 } 2903 COMPRESSED ipv4_outer_replicate { 2904 ENFORCE(is_innermost == 0); 2905 ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value); 2906 reserved =:= '0000' [ 4 ]; 2907 ip_id_behavior_outer =:= irregular(2) [ 2 ] 2908 ttl_flag =:= irregular(1) [ 1 ]; 2909 df =:= irregular(1) [ 1 ]; 2910 dscp =:= irregular(6) [ 6 ]; 2911 ip_ecn_flags =:= irregular(2) [ 2 ]; 2912 ip_id =:= 2913 ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2914 ttl_hopl =:= 2915 static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ]; 2916 } 2918 COMPRESSED ipv4_outer_without_ttl_irregular { 2919 ENFORCE(is_innermost == 0); 2920 ip_id =:= 2921 ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2922 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2923 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2924 ENFORCE(ttl_irregular_chain_flag == 0); 2925 ENFORCE(is_innermost == false); 2926 } 2928 COMPRESSED ipv4_outer_with_ttl_irregular { 2929 ENFORCE(is_innermost == 0); 2930 ip_id =:= 2931 ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2932 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2933 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2934 ttl_hopl =:= irregular(8) [ 8 ]; 2935 ENFORCE(ttl_irregular_chain_flag == 1); 2936 } 2938 COMPRESSED ipv4_innermost_irregular { 2939 ENFORCE(is_innermost == 1); 2940 ip_id =:= 2941 ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2942 ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE); 2943 } 2944 } 2946 ///////////////////////////////////////////// 2947 // TCP Options 2948 ///////////////////////////////////////////// 2950 // nbits is bound to the remaining length (in bits) of TCP 2951 // options, including the EOL type byte. 2952 tcp_opt_eol(nbits) 2953 { 2954 UNCOMPRESSED { 2955 type =:= uncompressed_value(8, 0) [ 8 ]; 2956 padding =:= 2957 uncompressed_value(nbits-8, 0) [ nbits-8 ]; 2958 } 2960 CONTROL { 2961 pad_len [ 8 ]; 2962 } 2964 COMPRESSED eol_list_item { 2965 pad_len =:= compressed_value(8, nbits-8) [ 8 ]; 2966 } 2967 COMPRESSED eol_irregular { 2968 pad_len =:= static; 2969 ENFORCE(nbits-8 == pad_len.UVALUE); 2970 } 2971 } 2973 tcp_opt_nop 2974 { 2975 UNCOMPRESSED { 2976 type =:= uncompressed_value(8, 1) [ 8 ]; 2977 } 2979 COMPRESSED nop_list_item { 2980 } 2982 COMPRESSED nop_irregular { 2983 } 2984 } 2986 tcp_opt_mss 2987 { 2988 UNCOMPRESSED { 2989 type =:= uncompressed_value(8, 2) [ 8 ]; 2990 length =:= uncompressed_value(8, 4) [ 8 ]; 2991 mss [ 16 ]; 2992 } 2994 COMPRESSED mss_list_item { 2995 mss =:= irregular(16) [ 16 ]; 2996 } 2998 COMPRESSED mss_irregular { 2999 mss =:= static; 3000 } 3001 } 3003 tcp_opt_wscale 3004 { 3005 UNCOMPRESSED { 3006 type =:= uncompressed_value(8, 3) [ 8 ]; 3007 length =:= uncompressed_value(8, 3) [ 8 ]; 3008 wscale [ 8 ]; 3009 } 3011 COMPRESSED wscale_list_item { 3012 wscale =:= irregular(8) [ 8 ]; 3013 } 3014 COMPRESSED wscale_irregular { 3015 wscale =:= static; 3016 } 3017 } 3019 ts_lsb 3020 { 3021 UNCOMPRESSED { 3022 tsval [ 32 ]; 3023 } 3025 COMPRESSED tsval_7 { 3026 discriminator =:= '0' [ 1 ]; 3027 tsval =:= lsb(7, -1) [ 7 ]; 3028 } 3030 COMPRESSED tsval_14 { 3031 discriminator =:= '10' [ 2 ]; 3032 tsval =:= lsb(14, -1) [ 14 ]; 3033 } 3035 COMPRESSED tsval_21 { 3036 discriminator =:= '110' [ 3 ]; 3037 tsval =:= lsb(21, 0x00040000) [ 21 ]; 3038 } 3040 COMPRESSED tsval_29 { 3041 discriminator =:= '111' [ 3 ]; 3042 tsval =:= lsb(29, 0x04000000) [ 29 ]; 3043 } 3044 } 3046 tcp_opt_ts 3047 { 3048 UNCOMPRESSED { 3049 type =:= uncompressed_value(8, 8) [ 8 ]; 3050 length =:= uncompressed_value(8, 10) [ 8 ]; 3051 tsval [ 32 ]; 3052 tsecho [ 32 ]; 3053 } 3055 COMPRESSED tsopt_list_item { 3056 tsval =:= irregular(32) [ 32 ]; 3057 tsecho =:= irregular(32) [ 32 ]; 3058 } 3060 COMPRESSED tsopt_irregular { 3061 tsval =:= ts_lsb [ 8, 16, 24, 32 ]; 3062 tsecho =:= ts_lsb [ 8, 16, 24, 32 ]; 3063 } 3064 } 3065 sack_pure_lsb(base) 3066 { 3067 UNCOMPRESSED { 3068 sack_field [ 32 ]; 3069 } 3071 CONTROL { 3072 ENFORCE(sack_field.CVALUE == (sack_field.UVALUE - base)); 3073 } 3075 COMPRESSED lsb_15 { 3076 ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x7fff); 3077 discriminator =:= '0' [ 1 ]; 3078 sack_field [ 15 ]; 3079 } 3081 COMPRESSED lsb_22 { 3082 ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x3fffff); 3083 discriminator =:= '10' [ 2 ]; 3084 sack_field [ 22 ]; 3085 } 3087 COMPRESSED lsb_29 { 3088 ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x1fffffff); 3089 discriminator =:= '110' [ 3 ]; 3090 sack_field [ 29 ]; 3091 } 3093 COMPRESSED full_offset { 3094 discriminator =:= '11111111' [ 8 ]; 3095 sack_field [ 32 ]; 3096 } 3097 } 3099 sack_block(reference) 3100 { 3101 UNCOMPRESSED { 3102 block_start [ 32 ]; 3103 block_end [ 32 ]; 3104 } 3106 COMPRESSED { 3107 block_start =:= 3108 sack_pure_lsb(reference) [ 16, 24, 32, 40 ]; 3109 block_end =:= 3110 sack_pure_lsb(block_start.UVALUE) [ 16, 24, 32, 40 ]; 3111 } 3112 } 3114 // The value of the parameter is set to the ack_number value 3115 // of the TCP header 3116 tcp_opt_sack(ack_value) 3117 { 3119 UNCOMPRESSED { 3120 type =:= uncompressed_value(8, 5) [ 8 ]; 3121 length [ 8 ]; 3122 block_1 [ 64 ]; 3123 block_2 [ 0, 64 ]; 3124 block_3 [ 0, 64 ]; 3125 block_4 [ 0, 64 ]; 3126 } 3128 DEFAULT { 3129 length =:= static; 3130 block_2 =:= uncompressed_value(0, 0); 3131 block_3 =:= uncompressed_value(0, 0); 3132 block_4 =:= uncompressed_value(0, 0); 3133 } 3135 COMPRESSED sack1_list_item { 3136 discriminator =:= '00000001'; 3137 block_1 =:= sack_block(ack_value); 3138 ENFORCE(length.UVALUE == 10); 3139 } 3141 COMPRESSED sack2_list_item { 3142 discriminator =:= '00000010'; 3143 block_1 =:= sack_block(ack_value); 3144 block_2 =:= sack_block(ack_value); 3145 ENFORCE(length.UVALUE == 18); 3146 } 3148 COMPRESSED sack3_list_item { 3149 discriminator =:= '00000011'; 3150 block_1 =:= sack_block(ack_value); 3151 block_2 =:= sack_block(ack_value); 3152 block_3 =:= sack_block(ack_value); 3153 ENFORCE(length.UVALUE == 26); 3154 } 3156 COMPRESSED sack4_list_item { 3157 discriminator =:= '00000100'; 3158 block_1 =:= sack_block(ack_value); 3159 block_2 =:= sack_block(ack_value); 3160 block_3 =:= sack_block(ack_value); 3161 block_4 =:= sack_block(ack_value); 3162 ENFORCE(length.UVALUE == 34); 3163 } 3165 COMPRESSED sack_unchanged_irregular { 3166 discriminator =:= '00000000'; 3167 block_1 =:= static; 3168 block_2 =:= static; 3169 block_3 =:= static; 3170 block_4 =:= static; 3171 } 3173 COMPRESSED sack1_irregular { 3174 discriminator =:= '00000001'; 3175 block_1 =:= sack_block(ack_value); 3176 ENFORCE(length.UVALUE == 10); 3177 } 3179 COMPRESSED sack2_irregular { 3180 discriminator =:= '00000010'; 3181 block_1 =:= sack_block(ack_value); 3182 block_2 =:= sack_block(ack_value); 3183 ENFORCE(length.UVALUE == 18); 3184 } 3186 COMPRESSED sack3_irregular { 3187 discriminator =:= '00000011'; 3188 block_1 =:= sack_block(ack_value); 3189 block_2 =:= sack_block(ack_value); 3190 block_3 =:= sack_block(ack_value); 3191 ENFORCE(length.UVALUE == 26); 3192 } 3194 COMPRESSED sack4_irregular { 3195 discriminator =:= '00000100'; 3196 block_1 =:= sack_block(ack_value); 3197 block_2 =:= sack_block(ack_value); 3198 block_3 =:= sack_block(ack_value); 3199 block_4 =:= sack_block(ack_value); 3200 ENFORCE(length.UVALUE == 34); 3201 } 3202 } 3204 tcp_opt_sack_permitted 3205 { 3206 UNCOMPRESSED { 3207 type =:= uncompressed_value(8, 4) [ 8 ]; 3208 length =:= uncompressed_value(8, 2) [ 8 ]; 3209 } 3211 COMPRESSED sack_permitted_list_item { 3212 } 3214 COMPRESSED sack_permitted_irregular { 3215 } 3216 } 3218 tcp_opt_generic 3219 { 3220 UNCOMPRESSED { 3221 type [ 8 ]; 3222 length_msb =:= uncompressed_value(1, 0) [ 1 ]; 3223 length_lsb [ 7 ]; 3224 contents [ length_lsb.UVALUE*8-16 ]; 3225 } 3227 CONTROL { 3228 option_static [ 1 ]; 3229 } 3231 DEFAULT { 3232 type =:= static; 3233 length_lsb =:= static; 3234 contents =:= static; 3235 } 3237 COMPRESSED generic_list_item { 3238 type =:= irregular(8) [ 8 ]; 3239 option_static =:= one_bit_choice [ 1 ]; 3240 length_lsb =:= irregular(7) [ 7 ]; 3241 contents =:= 3242 irregular(length_lsb.UVALUE*8-16) [ length_lsb.UVALUE*8-16 ]; 3243 } 3245 // Used when context of option has option_static set to one 3246 COMPRESSED generic_static_irregular { 3247 ENFORCE(option_static.UVALUE == 1); 3248 } 3250 // An item that can change, but currently is unchanged 3251 COMPRESSED generic_stable_irregular { 3252 discriminator =:= '11111111' [ 8 ]; 3253 ENFORCE(option_static.UVALUE == 0); 3255 } 3257 // An item that is assumed to change constantly. 3258 // Length is not allowed to change here, since a length change is 3259 // most likely to cause new NOPs or an EOL length change. 3260 COMPRESSED generic_full_irregular { 3261 discriminator =:= '00000000' [ 8 ]; 3262 contents =:= 3263 irregular(length_lsb.UVALUE*8-16) [ length_lsb.UVALUE*8-16 ]; 3264 ENFORCE(option_static.UVALUE == 0); 3265 } 3266 } 3268 tcp_list_presence_enc(presence) 3269 { 3270 UNCOMPRESSED { 3271 tcp_options; 3272 } 3274 COMPRESSED list_not_present { 3275 tcp_options =:= static [ 0 ]; 3276 ENFORCE(presence == 0); 3277 } 3279 COMPRESSED list_present { 3280 tcp_options =:= list_tcp_options [ VARIABLE ]; 3281 ENFORCE(presence == 1); 3282 } 3283 } 3285 ///////////////////////////////////////////// 3286 // TCP Header 3287 ///////////////////////////////////////////// 3289 port_replicate(flags) 3290 { 3291 UNCOMPRESSED { 3292 port [ 16 ]; 3293 } 3295 COMPRESSED port_static_enc { 3296 port =:= static [ 0 ]; 3297 ENFORCE(flags == 0b00); 3298 } 3300 COMPRESSED port_lsb8 { 3301 port =:= lsb(8, 64) [ 8 ]; 3302 ENFORCE(flags == 0b01); 3304 } 3306 COMPRESSED port_irr_enc { 3307 port =:= irregular(16) [ 16 ]; 3308 ENFORCE(flags == 0b10); 3309 } 3310 } 3312 tcp_irreg_ip_ecn(ip_inner_ecn) 3313 { 3314 UNCOMPRESSED { 3315 ip_ecn_flags [ 2 ]; 3316 } 3318 COMPRESSED ecn_present { 3319 // This field does not exist in the uncompressed header 3320 // and therefore cannot use uncompressed_value. 3321 ip_ecn_flags =:= 3322 compressed_value(2, ip_inner_ecn) [ 2 ]; 3323 ENFORCE(ecn_used.UVALUE == 1); 3324 } 3326 COMPRESSED ecn_not_present { 3327 ip_ecn_flags =:= static [ 0 ]; 3328 ENFORCE(ecn_used.UVALUE == 0); 3329 } 3330 } 3332 rsf_index_enc 3333 { 3334 UNCOMPRESSED { 3335 rsf_flag [ 3 ]; 3336 } 3338 COMPRESSED none { 3339 rsf_idx =:= '00' [ 2 ]; 3340 rsf_flag =:= uncompressed_value(3, 0x00); 3341 } 3343 COMPRESSED rst_only { 3344 rsf_idx =:= '01' [ 2 ]; 3345 rsf_flag =:= uncompressed_value(3, 0x04); 3346 } 3348 COMPRESSED syn_only { 3349 rsf_idx =:= '10' [ 2 ]; 3350 rsf_flag =:= uncompressed_value(3, 0x02); 3351 } 3352 COMPRESSED fin_only { 3353 rsf_idx =:= '11' [ 2 ]; 3354 rsf_flag =:= uncompressed_value(3, 0x01); 3355 } 3356 } 3358 optional_2bit_padding(used_flag) 3359 { 3360 UNCOMPRESSED { 3361 } 3363 COMPRESSED used { 3364 padding =:= compressed_value(2, 0x0) [ 2 ]; 3365 ENFORCE(used_flag == 1); 3366 } 3368 COMPRESSED unused { 3369 padding =:= compressed_value(0, 0x0); 3370 ENFORCE(used_flag == 0); 3371 } 3372 } 3374 // ack_stride_value is the user-selected stride for scaling the 3375 // TCP ack_number 3376 // ip_inner_ecn is the value bound when processing the innermost 3377 // IP header (ipv4 or ipv6 encoding method) 3378 tcp(payload_size, ack_stride_value, ip_inner_ecn) 3379 { 3380 UNCOMPRESSED { 3381 src_port [ 16 ]; 3382 dst_port [ 16 ]; 3383 seq_number [ 32 ]; 3384 ack_number [ 32 ]; 3385 data_offset [ 4 ]; 3386 tcp_res_flags [ 4 ]; 3387 tcp_ecn_flags [ 2 ]; 3388 urg_flag [ 1 ]; 3389 ack_flag [ 1 ]; 3390 psh_flag [ 1 ]; 3391 rsf_flags [ 3 ]; 3392 window [ 16 ]; 3393 checksum [ 16 ]; 3394 urg_ptr [ 16 ]; 3395 options [ (data_offset.UVALUE-5)*32 ]; 3396 } 3398 CONTROL { 3399 dummy_field_s =:= field_scaling(payload_size, 3400 seq_number_scaled.UVALUE, seq_number.UVALUE, 3401 seq_number_residue.UVALUE) [ 0 ]; 3402 dummy_field_a =:= field_scaling(ack_stride.UVALUE, 3403 ack_number_scaled.UVALUE, ack_number.UVALUE, 3404 ack_number_residue.UVALUE) [ 0 ]; 3405 ENFORCE(ack_stride.UVALUE == ack_stride_value); 3406 } 3408 INITIAL { 3409 ack_stride =:= uncompressed_value(16, 0); 3410 } 3412 DEFAULT { 3413 src_port =:= static; 3414 dst_port =:= static; 3415 seq_number =:= static; 3416 ack_number =:= static; 3417 data_offset =:= inferred_offset; 3418 tcp_res_flags =:= static; 3419 tcp_ecn_flags =:= static; 3420 urg_flag =:= static; 3421 ack_flag =:= uncompressed_value(1, 1); 3422 rsf_flags =:= uncompressed_value(3, 0); 3423 window =:= static; 3424 urg_ptr =:= static; 3425 ack_stride =:= static; 3426 ack_number_scaled =:= static; 3427 seq_number_scaled =:= static; 3428 ack_number_residue =:= static; 3429 seq_number_residue =:= static; 3430 } 3432 COMPRESSED tcp_static { 3433 src_port =:= irregular(16) [ 16 ]; 3434 dst_port =:= irregular(16) [ 16 ]; 3435 } 3437 COMPRESSED tcp_dynamic { 3438 ecn_used =:= one_bit_choice [ 1 ]; 3439 ack_stride_flag =:= irregular(1) [ 1 ]; 3440 ack_zero =:= irregular(1) [ 1 ]; 3441 urp_zero =:= irregular(1) [ 1 ]; 3442 tcp_res_flags =:= irregular(4) [ 4 ]; 3443 tcp_ecn_flags =:= irregular(2) [ 2 ]; 3444 urg_flag =:= irregular(1) [ 1 ]; 3445 ack_flag =:= irregular(1) [ 1 ]; 3446 psh_flag =:= irregular(1) [ 1 ]; 3447 rsf_flags =:= irregular(3) [ 3 ]; 3448 msn =:= irregular(16) [ 16 ]; 3449 seq_number =:= irregular(32) [ 32 ]; 3450 ack_number =:= 3451 zero_or_irreg(ack_zero.CVALUE, 32) [ 0, 32 ]; 3452 window =:= irregular(16) [ 16 ]; 3453 checksum =:= irregular(16) [ 16 ]; 3454 urg_ptr =:= 3455 zero_or_irreg(urp_zero.CVALUE, 16) [ 0, 16 ]; 3456 ack_stride =:= 3457 static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; 3458 options =:= list_tcp_options [ VARIABLE ]; 3459 } 3461 COMPRESSED tcp_replicate { 3462 reserved =:= '0' [ 1 ]; 3463 window_presence =:= irregular(1) [ 1 ]; 3464 list_present =:= irregular(1) [ 1 ]; 3465 src_port_presence =:= irregular(2) [ 2 ]; 3466 dst_port_presence =:= irregular(2) [ 2 ]; 3467 ack_stride_flag =:= irregular(1) [ 1 ]; 3468 ack_presence =:= irregular(1) [ 1 ]; 3469 urp_presence =:= irregular(1) [ 1 ]; 3470 urg_flag =:= irregular(1) [ 1 ]; 3471 ack_flag =:= irregular(1) [ 1 ]; 3472 psh_flag =:= irregular(1) [ 1 ]; 3473 rsf_flags =:= rsf_index_enc [ 2 ]; 3474 ecn_used =:= one_bit_choice [ 1 ]; 3475 msn =:= irregular(16) [ 16 ]; 3476 seq_number =:= irregular(32) [ 32 ]; 3477 src_port =:= 3478 port_replicate(src_port_presence) [ 0, 8, 16 ]; 3479 dst_port =:= 3480 port_replicate(dst_port_presence) [ 0, 8, 16 ]; 3481 window =:= 3482 static_or_irreg(window_presence, 16) [ 0, 16 ]; 3483 urg_point =:= 3484 static_or_irreg(urp_presence, 16) [ 0, 16 ]; 3485 ack_number =:= 3486 static_or_irreg(ack_presence, 32) [ 0, 32 ]; 3487 ecn_padding =:= 3488 optional_2bit_padding(ecn_used.CVALUE) [ 0, 2 ]; 3489 tcp_res_flags =:= 3490 static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; 3491 tcp_ecn_flags =:= 3492 static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ]; 3493 checksum =:= irregular(16) [ 16 ]; 3494 ack_stride =:= 3495 static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; 3497 options =:= 3498 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3499 } 3501 COMPRESSED tcp_irregular { 3502 ip_ecn_flags =:= tcp_irreg_ip_ecn(ip_inner_ecn) [ 0, 2 ]; 3503 tcp_res_flags =:= 3504 static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; 3505 tcp_ecn_flags =:= 3506 static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ]; 3507 checksum =:= irregular(16) [ 16 ]; 3508 } 3509 } 3511 /////////////////////////////////////////////////// 3512 // Encoding methods used in compressed base headers 3513 /////////////////////////////////////////////////// 3515 dscp_enc(flag) 3516 { 3517 UNCOMPRESSED { 3518 dscp [ 6 ]; 3519 } 3521 COMPRESSED static_enc { 3522 dscp =:= static [ 0 ]; 3523 ENFORCE(flag == 0); 3524 } 3526 COMPRESSED irreg { 3527 dscp =:= irregular(6) [ 6 ]; 3528 padding =:= compressed_value(2, 0) [ 2 ]; 3529 ENFORCE(flag == 1); 3530 } 3531 } 3533 ip_id_lsb(behavior, k, p) 3534 { 3535 UNCOMPRESSED { 3536 ip_id [ 16 ]; 3537 } 3539 CONTROL { 3540 ip_id_nbo [ 16 ]; 3541 } 3543 COMPRESSED nbo { 3544 ip_id_offset =:= lsb(k, p) [ k ]; 3545 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 3546 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 3547 } 3549 COMPRESSED non_nbo { 3550 ip_id_offset =:= lsb(k, p) [ k ]; 3551 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 3552 ENFORCE(ip_id_nbo.UVALUE == 3553 (ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256); 3554 ENFORCE(ip_id_nbo.ULENGTH == 16); 3555 ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE); 3556 } 3557 } 3559 optional_ip_id_lsb(behavior, indicator) 3560 { 3561 UNCOMPRESSED { 3562 ip_id [ 16 ]; 3563 } 3565 COMPRESSED short { 3566 ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ]; 3567 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 3568 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3569 ENFORCE(indicator == 0); 3570 } 3572 COMPRESSED long { 3573 ip_id =:= irregular(16) [ 16 ]; 3574 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 3575 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3576 ENFORCE(indicator == 1); 3577 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 3578 } 3580 COMPRESSED not_present { 3581 ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || 3582 (behavior == IP_ID_BEHAVIOR_ZERO)); 3583 } 3584 } 3586 dont_fragment(version) 3587 { 3588 UNCOMPRESSED { 3589 df [ 1 ]; 3590 } 3592 COMPRESSED v4 { 3593 df =:= irregular(1) [ 1 ]; 3594 ENFORCE(version == 4); 3595 } 3597 COMPRESSED v6 { 3598 df =:= compressed_value(1, 0) [ 1 ]; 3599 ENFORCE(version == 6); 3600 } 3601 } 3603 ////////////////////////////////// 3604 // Actual start of compressed packet formats 3605 // Important note: 3606 // The base header is the compressed representation 3607 // of the innermost IP header AND the TCP header. 3608 ////////////////////////////////// 3610 // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit 3611 // of an outer header has changed. The same value must be passed as 3612 // an argument to the ipv4/ipv6 encoding methods when extracting 3613 // the irregular chain items. 3614 co_baseheader(payload_size, ack_stride_value, 3615 ttl_irregular_chain_flag, ip_id_behavior_value) 3616 { 3617 UNCOMPRESSED v4 { 3618 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3619 version =:= uncompressed_value(4, 4) [ 4 ]; 3620 header_length =:= uncompressed_value(4, 5) [ 4 ]; 3621 dscp [ 6 ]; 3622 ip_ecn_flags [ 2 ]; 3623 length [ 16 ]; 3624 ip_id [ 16 ]; 3625 rf =:= uncompressed_value(1, 0) [ 1 ]; 3626 df [ 1 ]; 3627 mf =:= uncompressed_value(1, 0) [ 1 ]; 3628 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 3629 ttl_hopl [ 8 ]; 3630 next_header [ 8 ]; 3631 checksum [ 16 ]; 3632 src_addr [ 32 ]; 3633 dest_addr [ 32 ]; 3634 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3635 src_port [ 16 ]; 3636 dest_port [ 16 ]; 3637 seq_number [ 32 ]; 3638 ack_number [ 32 ]; 3639 data_offset [ 4 ]; 3640 tcp_res_flags [ 4 ]; 3641 tcp_ecn_flags [ 2 ]; 3642 urg_flag [ 1 ]; 3643 ack_flag [ 1 ]; 3644 psh_flag [ 1 ]; 3645 rsf_flags [ 3 ]; 3646 window [ 16 ]; 3647 tcp_checksum [ 16 ]; 3648 urg_ptr [ 16 ]; 3649 options [ (data_offset.UVALUE-5)*32 ]; 3650 } 3652 UNCOMPRESSED v6 { 3653 ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM); 3654 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3655 version =:= uncompressed_value(4, 6) [ 4 ]; 3656 dscp [ 6 ]; 3657 ip_ecn_flags [ 2 ]; 3658 flow_label [ 20 ]; 3659 payload_length [ 16 ]; 3660 next_header [ 8 ]; 3661 ttl_hopl [ 8 ]; 3662 src_addr [ 128 ]; 3663 dest_addr [ 128 ]; 3664 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3665 src_port [ 16 ]; 3666 dest_port [ 16 ]; 3667 seq_number [ 32 ]; 3668 ack_number [ 32 ]; 3669 data_offset [ 4 ]; 3670 tcp_res_flags [ 4 ]; 3671 tcp_ecn_flags [ 2 ]; 3672 urg_flag [ 1 ]; 3673 ack_flag [ 1 ]; 3674 psh_flag [ 1 ]; 3675 rsf_flags [ 3 ]; 3676 window [ 16 ]; 3677 tcp_checksum [ 16 ]; 3678 urg_ptr [ 16 ]; 3679 options [ (data_offset.UVALUE-5)*32 ]; 3680 df =:= uncompressed_value(0,0) [ 0 ]; 3681 ip_id =:= uncompressed_value(0,0) [ 0 ]; 3682 } 3684 CONTROL { 3685 dummy_field_s =:= field_scaling(payload_size, 3686 seq_number_scaled.UVALUE, seq_number.UVALUE, 3687 seq_number_residue.UVALUE) [ 0 ]; 3688 dummy_field_a =:= field_scaling(ack_stride.UVALUE, 3689 ack_number_scaled.UVALUE, ack_number.UVALUE, 3690 ack_number_residue.UVALUE) [ 0 ]; 3691 ENFORCE(ack_stride.UVALUE == ack_stride_value); 3692 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 3693 } 3695 INITIAL { 3696 ack_stride =:= uncompressed_value(16, 0); 3697 } 3699 DEFAULT { 3700 tcp_ecn_flags =:= static; 3701 data_offset =:= inferred_offset; 3702 tcp_res_flags =:= static; 3703 rsf_flags =:= uncompressed_value(3, 0); 3704 dest_port =:= static; 3705 dscp =:= static; 3706 src_port =:= static; 3707 urg_flag =:= uncompressed_value(1, 0); 3708 window =:= static; 3709 dest_addr =:= static; 3710 version =:= static; 3711 ttl_hopl =:= static; 3712 src_addr =:= static; 3713 df =:= static; 3714 ack_number =:= static; 3715 urg_ptr =:= static; 3716 seq_number =:= static; 3717 ack_flag =:= uncompressed_value(1, 1); 3718 // The default for "options" is case 2) and 3) from 3719 // the list in section 6.3.1 (i.e. nothing present in the 3720 // baseheader itself). 3721 payload_length =:= inferred_ip_v6_length; 3722 checksum =:= inferred_ip_v4_header_checksum; 3723 length =:= inferred_ip_v4_length; 3724 flow_label =:= static; 3725 next_header =:= static; 3726 ip_ecn_flags =:= static; 3727 // The tcp_checksum has no default, 3728 // it is considered a part of tcp_irregular 3729 ip_id_behavior_innermost =:= static; 3730 ecn_used =:= static; 3731 ack_stride =:= static; 3732 ack_number_scaled =:= static; 3733 seq_number_scaled =:= static; 3734 ack_number_residue =:= static; 3735 seq_number_residue =:= static; 3736 // Default is to have no TTL in irregular chain 3737 // Can only be nonzero if co_common is used 3738 ENFORCE(ttl_irregular_chain_flag == 0); 3739 } 3741 //////////////////////////////////////////// 3742 // Common compressed packet format 3743 //////////////////////////////////////////// 3745 COMPRESSED co_common { 3746 discriminator =:= '1111101' [ 7 ]; 3747 ttl_hopl_outer_flag =:= 3748 compressed_value(1, ttl_irregular_chain_flag) [ 1 ]; 3749 ack_flag =:= irregular(1) [ 1 ]; 3750 psh_flag =:= irregular(1) [ 1 ]; 3751 rsf_flags =:= rsf_index_enc [ 2 ]; 3752 msn =:= lsb(4, 4) [ 4 ]; 3753 seq_indicator =:= irregular(2) [ 2 ]; 3754 ack_indicator =:= irregular(2) [ 2 ]; 3755 ack_stride_indicator =:= irregular(1) [ 1 ]; 3756 window_indicator =:= irregular(1) [ 1 ]; 3757 ip_id_indicator =:= irregular(1) [ 1 ]; 3758 urg_ptr_present =:= irregular(1) [ 1 ]; 3759 reserved =:= compressed_value(1, 0) [ 1 ]; 3760 ecn_used =:= one_bit_choice [ 1 ]; 3761 dscp_present =:= irregular(1) [ 1 ]; 3762 ttl_hopl_present =:= irregular(1) [ 1 ]; 3763 list_present =:= irregular(1) [ 1 ]; 3764 ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 3765 urg_flag =:= irregular(1) [ 1 ]; 3766 df =:= dont_fragment(version.UVALUE) [ 1 ]; 3767 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3768 seq_number =:= 3769 variable_length_32_enc(seq_indicator.CVALUE) [ 0, 8, 16, 32 ]; 3770 ack_number =:= 3771 variable_length_32_enc(ack_indicator.CVALUE) [ 0, 8, 16, 32 ]; 3772 ack_stride =:= 3773 static_or_irreg(ack_stride_indicator.CVALUE, 16) [ 0, 16 ]; 3774 window =:= 3775 static_or_irreg(window_indicator.CVALUE, 16) [ 0, 16 ]; 3776 ip_id =:= 3777 optional_ip_id_lsb(ip_id_behavior_innermost.UVALUE, 3778 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 3779 urg_ptr =:= 3780 static_or_irreg(urg_ptr_present.CVALUE, 16) [ 0, 16 ]; 3781 dscp =:= 3782 dscp_enc(dscp_present.CVALUE) [ 0, 8 ]; 3783 ttl_hopl =:= 3784 static_or_irreg(ttl_hopl_present.CVALUE, 8) [ 0, 8 ]; 3785 options =:= 3786 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3787 } 3789 // Send LSBs of sequence number 3790 COMPRESSED rnd_1 { 3791 discriminator =:= '101110' [ 6 ]; 3792 seq_number =:= lsb(18, 65535) [ 18 ]; 3793 msn =:= lsb(4, 4) [ 4 ]; 3794 psh_flag =:= irregular(1) [ 1 ]; 3795 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3796 ENFORCE((ip_id_behavior_innermost.UVALUE == 3797 IP_ID_BEHAVIOR_RANDOM) || 3798 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3799 } 3801 // Send scaled sequence number LSBs 3802 COMPRESSED rnd_2 { 3803 discriminator =:= '1100' [ 4 ]; 3804 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3805 msn =:= lsb(4, 4) [ 4 ]; 3806 psh_flag =:= irregular(1) [ 1 ]; 3807 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3808 ENFORCE(payload_size != 0); 3809 ENFORCE((ip_id_behavior_innermost.UVALUE == 3810 IP_ID_BEHAVIOR_RANDOM) || 3811 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3812 } 3814 // Send acknowledgment number LSBs 3815 COMPRESSED rnd_3 { 3816 discriminator =:= '0' [ 1 ]; 3817 ack_number =:= lsb(15, 8191) [ 15 ]; 3818 msn =:= lsb(4, 4) [ 4 ]; 3819 psh_flag =:= irregular(1) [ 1 ]; 3820 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3821 ENFORCE((ip_id_behavior_innermost.UVALUE == 3822 IP_ID_BEHAVIOR_RANDOM) || 3823 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3824 } 3826 // Send acknowledgment number scaled 3827 COMPRESSED rnd_4 { 3828 discriminator =:= '1101' [ 4 ]; 3829 ack_number_scaled =:= lsb(4, 3) [ 4 ]; 3830 msn =:= lsb(4, 4) [ 4 ]; 3831 psh_flag =:= irregular(1) [ 1 ]; 3832 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3833 ENFORCE(ack_stride.UVALUE != 0); 3834 ENFORCE((ip_id_behavior_innermost.UVALUE == 3835 IP_ID_BEHAVIOR_RANDOM) || 3836 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3837 } 3839 // Send ACK and sequence number 3840 COMPRESSED rnd_5 { 3841 discriminator =:= '100' [ 3 ]; 3842 psh_flag =:= irregular(1) [ 1 ]; 3843 msn =:= lsb(4, 4) [ 4 ]; 3844 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3845 seq_number =:= lsb(14, 8191) [ 14 ]; 3846 ack_number =:= lsb(15, 8191) [ 15 ]; 3847 ENFORCE((ip_id_behavior_innermost.UVALUE == 3848 IP_ID_BEHAVIOR_RANDOM) || 3849 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3850 } 3852 // Send both ACK and scaled sequence number LSBs 3853 COMPRESSED rnd_6 { 3854 discriminator =:= '1010' [ 4 ]; 3855 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3856 psh_flag =:= irregular(1) [ 1 ]; 3857 ack_number =:= lsb(16, 16383) [ 16 ]; 3858 msn =:= lsb(4, 4) [ 4 ]; 3859 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3860 ENFORCE(payload_size != 0); 3861 ENFORCE((ip_id_behavior_innermost.UVALUE == 3862 IP_ID_BEHAVIOR_RANDOM) || 3863 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3864 } 3866 // Send ACK and window 3867 COMPRESSED rnd_7 { 3868 discriminator =:= '101111' [ 6 ]; 3869 ack_number =:= lsb(18, 65535) [ 18 ]; 3870 window =:= irregular(16) [ 16 ]; 3871 msn =:= lsb(4, 4) [ 4 ]; 3872 psh_flag =:= irregular(1) [ 1 ]; 3873 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3874 ENFORCE((ip_id_behavior_innermost.UVALUE == 3875 IP_ID_BEHAVIOR_RANDOM) || 3876 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3877 } 3879 // An extended packet type for seldom-changing fields 3880 // Can send LSBs of TTL, RSF flags, change ECN behavior, and 3881 // options list 3882 COMPRESSED rnd_8 { 3883 discriminator =:= '10110' [ 5 ]; 3884 rsf_flags =:= rsf_index_enc [ 2 ]; 3885 list_present =:= irregular(1) [ 1 ]; 3886 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3887 msn =:= lsb(4, 4) [ 4 ]; 3888 psh_flag =:= irregular(1) [ 1 ]; 3889 ttl_hopl =:= lsb(3, 3) [ 3 ]; 3890 ecn_used =:= one_bit_choice [ 1 ]; 3891 seq_number =:= lsb(16, 65535) [ 16 ]; 3892 ack_number =:= lsb(16, 16383) [ 16 ]; 3893 options =:= 3894 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3895 ENFORCE((ip_id_behavior_innermost.UVALUE == 3896 IP_ID_BEHAVIOR_RANDOM) || 3897 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3898 } 3900 // Send LSBs of sequence number 3901 COMPRESSED seq_1 { 3902 discriminator =:= '1010' [ 4 ]; 3903 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 3904 seq_number =:= lsb(16, 32767) [ 16 ]; 3905 msn =:= lsb(4, 4) [ 4 ]; 3906 psh_flag =:= irregular(1) [ 1 ]; 3907 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3908 ENFORCE((ip_id_behavior_innermost.UVALUE == 3909 IP_ID_BEHAVIOR_SEQUENTIAL) || 3910 (ip_id_behavior_innermost.UVALUE == 3911 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3912 } 3914 // Send scaled sequence number LSBs 3915 COMPRESSED seq_2 { 3916 discriminator =:= '11010' [ 5 ]; 3917 ip_id =:= 3918 ip_id_lsb(ip_id_behavior_innermost.UVALUE, 7, 3) [ 7 ]; 3919 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3920 msn =:= lsb(4, 4) [ 4 ]; 3921 psh_flag =:= irregular(1) [ 1 ]; 3922 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3923 ENFORCE(payload_size != 0); 3924 ENFORCE((ip_id_behavior_innermost.UVALUE == 3925 IP_ID_BEHAVIOR_SEQUENTIAL) || 3926 (ip_id_behavior_innermost.UVALUE == 3927 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3929 } 3931 // Send acknowledgment number LSBs 3932 COMPRESSED seq_3 { 3933 discriminator =:= '1001' [ 4 ]; 3934 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 3935 ack_number =:= lsb(16, 16383) [ 16 ]; 3936 msn =:= lsb(4, 4) [ 4 ]; 3937 psh_flag =:= irregular(1) [ 1 ]; 3938 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3939 ENFORCE((ip_id_behavior_innermost.UVALUE == 3940 IP_ID_BEHAVIOR_SEQUENTIAL) || 3941 (ip_id_behavior_innermost.UVALUE == 3942 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3943 } 3945 // Send scaled acknowledgment number scaled 3946 COMPRESSED seq_4 { 3947 discriminator =:= '0' [ 1 ]; 3948 ack_number_scaled =:= lsb(4, 3) [ 4 ]; 3949 // Due to having very few ip_id bits, no negative offset 3950 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 3, 1) [ 3 ]; 3951 msn =:= lsb(4, 4) [ 4 ]; 3952 psh_flag =:= irregular(1) [ 1 ]; 3953 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3954 ENFORCE(ack_stride.UVALUE != 0); 3955 ENFORCE((ip_id_behavior_innermost.UVALUE == 3956 IP_ID_BEHAVIOR_SEQUENTIAL) || 3957 (ip_id_behavior_innermost.UVALUE == 3958 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3959 } 3961 // Send ACK and sequence number 3962 COMPRESSED seq_5 { 3963 discriminator =:= '1000' [ 4 ]; 3964 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 3965 ack_number =:= lsb(16, 16383) [ 16 ]; 3966 seq_number =:= lsb(16, 32767) [ 16 ]; 3967 msn =:= lsb(4, 4) [ 4 ]; 3968 psh_flag =:= irregular(1) [ 1 ]; 3969 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3970 ENFORCE((ip_id_behavior_innermost.UVALUE == 3971 IP_ID_BEHAVIOR_SEQUENTIAL) || 3972 (ip_id_behavior_innermost.UVALUE == 3973 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3974 } 3976 // Send both ACK and scaled sequence number LSBs 3977 COMPRESSED seq_6 { 3978 discriminator =:= '11011' [ 5 ]; 3979 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3980 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 7, 3) [ 7 ]; 3981 ack_number =:= lsb(16, 16383) [ 16 ]; 3982 msn =:= lsb(4, 4) [ 4 ]; 3983 psh_flag =:= irregular(1) [ 1 ]; 3984 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3985 ENFORCE(payload_size != 0); 3986 ENFORCE((ip_id_behavior_innermost.UVALUE == 3987 IP_ID_BEHAVIOR_SEQUENTIAL) || 3988 (ip_id_behavior_innermost.UVALUE == 3989 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3990 } 3992 // Send ACK and window 3993 COMPRESSED seq_7 { 3994 discriminator =:= '1100' [ 4 ]; 3995 window =:= lsb(15, 16383) [ 15 ]; 3996 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5, 3) [ 5 ]; 3997 ack_number =:= lsb(16, 32767) [ 16 ]; 3998 msn =:= lsb(4, 4) [ 4 ]; 3999 psh_flag =:= irregular(1) [ 1 ]; 4000 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4001 ENFORCE((ip_id_behavior_innermost.UVALUE == 4002 IP_ID_BEHAVIOR_SEQUENTIAL) || 4003 (ip_id_behavior_innermost.UVALUE == 4004 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4005 } 4007 // An extended packet type for seldom-changing fields 4008 // Can send LSBs of TTL, RSF flags, change ECN behavior, and 4009 // options list 4010 COMPRESSED seq_8 { 4011 discriminator =:= '1011' [ 4 ]; 4012 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 4013 list_present =:= irregular(1) [ 1 ]; 4014 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4015 msn =:= lsb(4, 4) [ 4 ]; 4016 psh_flag =:= irregular(1) [ 1 ]; 4017 ttl_hopl =:= lsb(3, 3) [ 3 ]; 4018 ecn_used =:= one_bit_choice [ 1 ]; 4019 ack_number =:= lsb(15, 8191) [ 15 ]; 4020 rsf_flags =:= rsf_index_enc [ 2 ]; 4021 seq_number =:= lsb(14, 8191) [ 14 ]; 4022 options =:= 4023 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 4024 ENFORCE((ip_id_behavior_innermost.UVALUE == 4025 IP_ID_BEHAVIOR_SEQUENTIAL) || 4026 (ip_id_behavior_innermost.UVALUE == 4027 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4028 } 4029 } 4031 8.3. Feedback Formats and Options 4033 8.3.1. Feedback Formats 4035 This section describes the feedback formats for the ROHC-TCP profile, 4036 following the general ROHC feedback format described in Section 5.2.3 4037 of [RFC5795]. 4039 All feedback formats carry a field labeled MSN. The MSN field 4040 contains LSBs of the MSN control field described in Section 6.1.1. 4041 The sequence number to use is the MSN corresponding to the last 4042 header that was successfully CRC-8 validated or CRC verified. 4044 FEEDBACK-1 4046 0 1 2 3 4 5 6 7 4047 +---+---+---+---+---+---+---+---+ 4048 | MSN | 4049 +---+---+---+---+---+---+---+---+ 4051 MSN: The LSB-encoded master sequence number. 4053 A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, 4054 FEEDBACK-2 must be used. 4056 FEEDBACK-2 4058 0 1 2 3 4 5 6 7 4059 +---+---+---+---+---+---+---+---+ 4060 |Acktype| MSN | 4061 +---+---+---+---+---+---+---+---+ 4062 | MSN | 4063 +---+---+---+---+---+---+---+---+ 4064 | CRC | 4065 +---+---+---+---+---+---+---+---+ 4066 / Feedback options / 4067 +---+---+---+---+---+---+---+---+ 4068 Acktype: 4070 0 = ACK 4072 1 = NACK 4074 2 = STATIC-NACK 4076 3 is reserved (MUST NOT be used for parsability) 4078 MSN: The LSB-encoded master sequence number. 4080 CRC: 8-bit CRC computed over the entire feedback element (as 4081 defined in Section 5.3.1.1 of [RFC5795]). For the purpose of 4082 computing the CRC, the CRC field is zero. The CRC is calculated 4083 using the polynomial defined in [RFC5795]. 4085 Feedback options: A variable number of feedback options, see 4086 Section 8.3.2. Options may appear in any order. 4088 A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an 4089 acknowledgment for a successfully decompressed packet, which packet 4090 corresponds to the MSN of the feedback element, unless the MSN-NOT- 4091 VALID option (Section 8.3.2.2) appears in the feedback element. 4093 The FEEDBACK-2 format always carries a CRC and is thus more robust 4094 than the FEEDBACK-1 format. When receiving FEEDBACK-2, the 4095 compressor MUST verify the information by computing the CRC and by 4096 comparing the result with the CRC carried in the feedback format. If 4097 the two are not identical, the feedback element MUST be discarded. 4099 8.3.2. Feedback Options 4101 A ROHC-TCP feedback option has variable length and the following 4102 general format: 4104 0 1 2 3 4 5 6 7 4105 +---+---+---+---+---+---+---+---+ 4106 | Opt Type | Opt Len | 4107 +---+---+---+---+---+---+---+---+ 4108 / option data / Opt Length (octets) 4109 +---+---+---+---+---+---+---+---+ 4111 Each ROHC-TCP feedback option can appear at most once within a 4112 FEEDBACK-2. 4114 8.3.2.1. The REJECT Option 4116 The REJECT option informs the compressor that the decompressor does 4117 not have sufficient resources to handle the flow. 4119 +---+---+---+---+---+---+---+---+ 4120 | Opt Type = 2 | Opt Len = 0 | 4121 +---+---+---+---+---+---+---+---+ 4123 When receiving a REJECT option, the compressor MUST stop compressing 4124 the packet flow, and SHOULD refrain from attempting to increase the 4125 number of compressed packet flows for some time. The REJECT option 4126 MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, 4127 the compressor MUST discard the entire feedback element. 4129 8.3.2.2. The MSN-NOT-VALID Option 4131 The MSN-NOT-VALID option indicates that the MSN of the feedback is 4132 not valid. 4134 +---+---+---+---+---+---+---+---+ 4135 | Opt Type = 3 | Opt Len = 0 | 4136 +---+---+---+---+---+---+---+---+ 4138 A compressor MUST ignore the MSN of the feedback element when this 4139 option is present. Consequently, a NACK or a STATIC-NACK feedback 4140 type sent with the MSN-NOT-VALID option is equivalent to a STATIC- 4141 NACK with respect to the semantics of the feedback message. 4143 The MSN-NOT-VALID option MUST NOT appear more than once in the 4144 FEEDBACK-2 format and MUST NOT appear in the same feedback element as 4145 the MSN option; otherwise, the compressor MUST discard the entire 4146 feedback element. 4148 8.3.2.3. The MSN Option 4150 The MSN option provides 2 additional bits of MSN. 4152 +---+---+---+---+---+---+---+---+ 4153 | Opt Type = 4 | Opt Len = 1 | 4154 +---+---+---+---+---+---+---+---+ 4155 | MSN | Reserved | 4156 +---+---+---+---+---+---+---+---+ 4158 These 2 bits are the least significant bits of the MSN and are thus 4159 concatenated with the 14 bits already present in the FEEDBACK-2 4160 format. 4162 The MSN option MUST NOT appear more than once in the FEEDBACK-2 4163 format and MUST NOT appear in the same feedback element as the MSN- 4164 NOT-VALID option; otherwise, the compressor MUST discard the entire 4165 feedback element. 4167 8.3.2.4. The CONTEXT_MEMORY Feedback Option 4169 The CONTEXT_MEMORY option means that the decompressor does not have 4170 sufficient memory resources to handle the context of the packet flow, 4171 as the flow is currently compressed. 4173 0 1 2 3 4 5 6 7 4174 +---+---+---+---+---+---+---+---+ 4175 | Opt Type = 9 | Opt Len = 0 | 4176 +---+---+---+---+---+---+---+---+ 4178 When receiving a CONTEXT_MEMORY option, the compressor SHOULD take 4179 actions to compress the packet flow in a way that requires less 4180 decompressor memory resources, or stop compressing the packet flow. 4182 The CONTEXT_MEMORY option MUST NOT appear more than once in the 4183 FEEDBACK-2 format; otherwise, the compressor MUST discard the entire 4184 feedback element. 4186 8.3.2.5. Unknown Option Types 4188 If an option type unknown to the compressor is encountered, the 4189 compressor MUST continue parsing the rest of the FEEDBACK element, 4190 which is possible since the length of the option is explicit, but 4191 MUST otherwise ignore the unknown option. 4193 9. Changes from RFC 4996 4195 This RFC revises RFC 4996. It is mostly backwards-compatible with 4196 RFC 4996 except for two cases that did not interoperate as described 4197 below. 4199 9.1. Functional Changes 4201 o The SACK option compression in [RFC4996] assumed that multiple 4202 SACK blocks within the same option would be in sorted order so 4203 that the block starts were LSB-encoded from the end of the 4204 previous block. This meant that SACK blocks that are not in 4205 sorted order could be impossible to compress in some cases. 4206 Therefore, the SACK compression in the formal notation has changed 4207 and therefore also the bits-on-the-wire. 4209 o The ESP NULL header compression has been deprecated due to 4210 interoperability problems with needing to know information from 4211 the trailer. The ESP NULL compression was already removed from 4212 ROHCv2 [RFC5225] for the same reason and it was considered better 4213 to remove it from this profile rather than try to fix the 4214 interoperability issue. 4216 9.2. Non-functional Changes 4218 o The way sequential IP-ID compression was described in the FN code 4219 was incorrect and the code used for ROHCv2 [RFC5225] has been 4220 imported into this specification (e.g. offset is made into a 4221 global control field). This does not change the bits-on-the-wire. 4222 The only change is how this encoding is described in the formal 4223 notation, not how the compression occurs. 4225 o Default encoding for the 'df' and 'ip_id' fields have been added 4226 for IPv6 with 0-bit uncompressed format to clarify that these 4227 never appear in IPv6. 4229 o The scaled encoding of the Acknowledgment Number and Sequence 4230 Number were incorrectly described in the FN code in [RFC4996] and 4231 have been updated in the same style as in ROHCv2 [RFC5225]. This 4232 does not change the bits-on-the-wire, only the way the compression 4233 is described in the FN code. 4235 o The external arguments to ipv4 and co_baseheader have been 4236 updated. This is again only a change for FN correctness and does 4237 not affect interoperability. 4239 o Erratas for [RFC4996] related to minor errors in the FN and 4240 textual errors have also been corrected. 4242 10. Security Considerations 4244 A malfunctioning or malicious header compressor could cause the 4245 header decompressor to reconstitute packets that do not match the 4246 original packets but still have valid IP and TCP headers, and 4247 possibly also valid TCP checksums. Such corruption may be detected 4248 with end-to-end authentication and integrity mechanisms that will not 4249 be affected by the compression. Moreover, this header compression 4250 scheme uses an internal checksum for verification of reconstructed 4251 headers. This reduces the probability of producing decompressed 4252 headers not matching the original ones without this being noticed. 4254 Denial-of-service attacks are possible if an intruder can introduce 4255 (for example) bogus IR, CO, or FEEDBACK packets onto the link and 4256 thereby cause compression efficiency to be reduced. However, an 4257 intruder having the ability to inject arbitrary packets at the link 4258 layer in this manner raises additional security issues that dwarf 4259 those related to the use of header compression. 4261 11. IANA Considerations 4263 The ROHC profile identifier 0x0006 has been reserved by the IANA for 4264 the profile defined in this document. 4266 A ROHC profile identifier has been reserved by the IANA for the 4267 profile defined in this document. Profiles 0x0000-0x0005 have 4268 previously been reserved; this profile is 0x0006. As for previous 4269 ROHC profiles, profile numbers 0xnn06 have been reserved for future 4270 updates of this profile. 4272 Profile Usage Document 4273 identifier 4275 0x0006 ROHC TCP [RFC4996] 4276 0xnn06 Reserved 4278 12. Acknowledgments 4280 The authors would like to thank Qian Zhang, Hong Bin Liao, Richard 4281 Price, and Fredrik Lindstroem for their work with early versions of 4282 this specification. Thanks also to Robert Finking and Carsten 4283 Bormann for valuable input. 4285 Additional thanks: this document was reviewed during working group 4286 last-call by committed reviewers Joe Touch and Ted Faber, as well as 4287 by Sally Floyd, who provided a review at the request of the Transport 4288 Area Directors. 4290 13. References 4292 13.1. Normative References 4294 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4295 September 1981. 4297 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 4298 RFC 793, September 1981. 4300 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 4301 October 1996. 4303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4304 Requirement Levels", BCP 14, RFC 2119, March 1997. 4306 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4307 (IPv6) Specification", RFC 2460, December 1998. 4309 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 4310 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 4311 March 2000. 4313 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 4314 RFC 2890, September 2000. 4316 [RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context 4317 Replication for ROHC Profiles", RFC 4164, August 2005. 4319 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 4320 December 2005. 4322 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 4323 RFC 4303, December 2005. 4325 [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust 4326 Header Compression (ROHC-FN)", RFC 4997, July 2007. 4328 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 4329 Header Compression (ROHC) Framework", RFC 5795, 4330 March 2010. 4332 13.2. Informative References 4334 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 4335 serial links", RFC 1144, February 1990. 4337 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 4338 for High Performance", RFC 1323, May 1992. 4340 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 4341 Selective Acknowledgment Options", RFC 2018, October 1996. 4343 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 4344 Compression", RFC 2507, February 1999. 4346 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 4347 Extension to the Selective Acknowledgement (SACK) Option 4348 for TCP", RFC 2883, July 2000. 4350 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 4351 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 4352 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 4353 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 4354 Compression (ROHC): Framework and four profiles: RTP, UDP, 4355 ESP, and uncompressed", RFC 3095, July 2001. 4357 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 4358 of Explicit Congestion Notification (ECN) to IP", 4359 RFC 3168, September 2001. 4361 [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): 4362 Terminology and Channel Mapping Examples", RFC 3759, 4363 April 2004. 4365 [RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC): 4366 Requirements on TCP/IP Header Compression", RFC 4163, 4367 August 2005. 4369 [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust 4370 Header Compression (ROHC): ROHC over Channels That Can 4371 Reorder Packets", RFC 4224, January 2006. 4373 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 4374 March 2006. 4376 [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 4377 "RObust Header Compression (ROHC): A Profile for TCP/IP 4378 (ROHC-TCP)", RFC 4996, July 2007. 4380 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 4381 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 4382 UDP-Lite", RFC 5225, April 2008. 4384 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 4385 Control", RFC 5681, September 2009. 4387 Authors' Addresses 4389 Ghyslain Pelletier 4390 InterDigital Communications 4391 1000, rue Sherbrooke ouest, 10th floor 4392 Montreal, Quebec H3A 3G4 4393 Canada 4395 Phone: +46 (0) 70 609 27 73 4396 Email: ghyslain.pelletier@interdigital.com 4398 Kristofer Sandlund 4399 Ericsson 4400 Box 920 4401 Lulea SE-971 28 4402 Sweden 4404 Phone: +46 (0) 8 404 41 58 4405 Email: kristofer.sandlund@ericsson.com 4407 Lars-Erik Jonsson 4408 Optand 737 4409 Ostersund SE-831 92 4410 Sweden 4412 Phone: +46 70 365 20 58 4413 Email: lars-erik@lejonsson.com 4415 Mark A West 4416 Siemens/Roke Manor 4417 Roke Manor Research Ltd. 4418 Romsey, Hampshire SO51 0ZN 4419 UK 4421 Phone: +44 1794 833311 4422 Email: mark.a.west@roke.co.uk 4423 URI: http://www.roke.co.uk