idnits 2.17.1 draft-sandlund-rfc4996bis-02.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 (May 16, 2012) is 4357 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 4268, but not defined ** 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 (~~), 2 warnings (==), 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: November 17, 2012 L-E. Jonsson 8 M. West 9 Siemens/Roke Manor 10 May 16, 2012 12 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) 13 draft-sandlund-rfc4996bis-02 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 November 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 13 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) . . . . . . . . . 15 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 . . . . . . . . . 37 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]). TCP options that may be less 166 frequently used must be supported transparently by the compression 167 protocol, although their contents may not be compressed but their 168 presence should not reduce the overall compression efficiency of 169 other parts of the TCP header. 171 The ROHC WG has developed a header compression framework on top of 172 which various profiles can be defined for different protocol sets, or 173 for different compression strategies. This document defines a TCP/IP 174 compression profile for the ROHC framework [RFC5795], compliant with 175 the requirements listed in [RFC4163]. 177 Specifically, it describes a header compression scheme for TCP/IP 178 header compression (ROHC-TCP) that is robust against packet loss and 179 that offers enhanced capabilities, in particular for the compression 180 of header fields including TCP options. The profile identifier for 181 TCP/IP compression is 0x0006. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 This document reuses some of the terminology found in [RFC5795]. In 190 addition, this document uses or defines the following terms: 192 Base context 193 The base context is a context that has been validated by both the 194 compressor and the decompressor. A base context can be used as 195 the reference when building a new context using replication. 197 Base Context Identifier (Base CID) 199 The Base CID is the CID that identifies the base context, from 200 which information needed for context replication can be extracted. 202 Base header 204 A compressed representation of the innermost IP and TCP headers of 205 the uncompressed packet. 207 Chaining of items 209 A chain groups fields based on similar characteristics. ROHC-TCP 210 defines chain items for static, dynamic, replicable, or irregular 211 fields. Chaining is done by appending an item for each header 212 e.g., to the chain in their order of appearance in the 213 uncompressed packet. Chaining is useful to construct compressed 214 headers from an arbitrary number of any of the protocol headers 215 for which ROHC-TCP defines a compressed format. 217 Context Replication (CR) 219 Context replication is the mechanism that establishes and 220 initializes a new context based on another existing valid context 221 (a base context). This mechanism is introduced to reduce the 222 overhead of the context establishment procedure, and is especially 223 useful for compression of multiple short-lived TCP connections 224 that may be occurring simultaneously or near-simultaneously. 226 ROHC-TCP packet types 228 ROHC-TCP uses three different packet types: the Initialization and 229 Refresh (IR) packet type, the Context Replication (IR-CR) packet 230 type, and the Compressed packet (CO) type. 232 Short-lived TCP transfer 234 Short-lived TCP transfers refer to TCP connections transmitting 235 only small amounts of packets for each single connection. 237 3. Background 239 This section provides some background information on TCP/IP header 240 compression. The fundamentals of general header compression can be 241 found in [RFC5795]. In the following subsections, two existing 242 TCP/IP header compression schemes are first described along with a 243 discussion of their limitations, followed by the classification of 244 TCP/IP header fields. Finally, some of the characteristics of short- 245 lived TCP transfers are summarized. 247 A behavior analysis of TCP/IP header fields is found in [RFC4413]. 249 3.1. Existing TCP/IP Header Compression Schemes 251 Compressed TCP (CTCP) and IP Header Compression (IPHC) are two 252 different schemes that may be used to compress TCP/IP headers. Both 253 schemes transmit only the differences from the previous header in 254 order to reduce the size of the TCP/IP header. 256 The CTCP [RFC1144] compressor detects transport-level retransmissions 257 and sends a header that updates the context completely when they 258 occur. While CTCP works well over reliable links, it is vulnerable 259 when used over less reliable links as even a single packet loss 260 results in loss of synchronization between the compressor and the 261 decompressor. This in turn leads to the TCP receiver discarding all 262 remaining packets in the current window because of a checksum error. 263 This effectively prevents the TCP fast retransmit algorithm [RFC5681] 264 from being triggered. In such a case, the compressor must wait until 265 TCP times out and retransmits a packet to resynchronize. 267 To reduce the errors due to the inconsistent contexts between 268 compressor and decompressor when compressing TCP, IPHC [RFC2507] 269 improves somewhat on CTCP by augmenting the repair mechanism of CTCP 270 with a local repair mechanism called TWICE and with a link-layer 271 mechanism based on negative acknowledgments to request a header that 272 updates the context. 274 The TWICE algorithm assumes that only the Sequence Number field of 275 TCP segments is changing with the deltas between consecutive packets 276 being constant in most cases. This assumption is however not always 277 true, especially when TCP Timestamps and SACK options are used. 279 The full header request mechanism requires a feedback channel that 280 may be unavailable in some circumstances. This channel is used to 281 explicitly request that the next packet be sent with an uncompressed 282 header to allow resynchronization without waiting for a TCP timeout. 283 In addition, this mechanism does not perform well on links with long 284 round-trip times. 286 Both CTCP and IPHC are also limited in their handling of the TCP 287 options field. For IPHC, any change in the options field (caused by 288 Timestamps or SACK, for example) renders the entire field 289 uncompressible, while for CTCP, such a change in the options field 290 effectively disables TCP/IP header compression altogether. 292 Finally, existing TCP/IP compression schemes do not compress the 293 headers of handshaking packets (SYNs and FINs). Compressing these 294 packets may greatly improve the overall header compression ratio for 295 the cases where many short-lived TCP connections share the same 296 channel. 298 3.2. Classification of TCP/IP Header Fields 300 Header compression is possible due to the fact that there is much 301 redundancy between header field values within packets, especially 302 between consecutive packets. To utilize these properties for TCP/IP 303 header compression, it is important to understand the change patterns 304 of the various header fields. 306 All fields of the TCP/IP packet header have been classified in detail 307 in [RFC4413]. The main conclusion is that most of the header fields 308 can easily be compressed away since they seldom or never change. The 309 following fields do however require more sophisticated mechanisms: 311 - IPv4 Identification (16 bits) - IP-ID 312 - TCP Sequence Number (32 bits) - SN 313 - TCP Acknowledgment Number (32 bits) 314 - TCP Reserved ( 4 bits) 315 - TCP ECN flags ( 2 bits) - ECN 316 - TCP Window (16 bits) 317 - TCP Options 318 o Maximum Segment Size (32 bits) - MSS 319 o Window Scale (24 bits) - WSCALE 320 o SACK Permitted (16 bits) 321 o TCP SACK (80, 144, 208, or 272 bits) - SACK 322 o TCP Timestamp (80 bits) - TS 324 The assignment of IP-ID values can be done in various ways, usually 325 one of sequential, sequential jump, or random, as described in 326 Section 4.1.3 of [RFC4413]. Some IPv4 stacks do use a sequential 327 assignment when generating IP-ID values but do not transmit the 328 contents of this field in network byte order; instead, it is sent 329 with the two octets reversed. In this case, the compressor can 330 compress the IP-ID field after swapping the bytes. Consequently, the 331 decompressor also swaps the bytes of the IP-ID after decompression to 332 regenerate the original IP-ID. With respect to TCP compression, the 333 analysis in [RFC4413] reveals that there is no obvious candidate 334 among the TCP fields suitable to infer the IP-ID. 336 The change pattern of several TCP fields (Sequence Number, 337 Acknowledgment Number, Window, etc.) is very hard to predict. Of 338 particular importance to a TCP/IP header compression scheme is the 339 understanding of the sequence and acknowledgment numbers [RFC4413]. 341 Specifically, the TCP Sequence Number can be anywhere within a range 342 defined by the TCP Window at any point on the path (i.e., wherever a 343 compressor might be deployed). Missing packets or retransmissions 344 can cause the TCP Sequence Number to fluctuate within the limits of 345 this window. The TCP Window also bounds the jumps in acknowledgment 346 number. 348 Another important behavior of the TCP/IP header is the dependency 349 between the sequence number and the acknowledgment number. TCP 350 connections can be either near-symmetrical or show a strong 351 asymmetrical bias with respect to the data traffic. In the latter 352 case, the TCP connections mainly have one-way traffic (Web browsing 353 and file downloading, for example). This means that on the forward 354 path (from server to client), only the sequence number is changing 355 while the acknowledgment number remains constant for most packets; on 356 the backward path (from client to server), only the acknowledgment 357 number is changing and the sequence number remains constant for most 358 packets. A compression scheme for TCP should thus have packet 359 formats suitable for either cases, i.e., packet formats that can 360 carry either only sequence number bits, only acknowledgment number 361 bits, or both. 363 In addition, TCP flows can be short-lived transfers. Short-lived TCP 364 transfers will degrade the performance of header compression schemes 365 that establish a new context by initially sending full headers. 366 Multiple simultaneous or near simultaneous TCP connections may 367 exhibit much similarity in header field values and context values 368 among each other, which would make it possible to reuse information 369 between flows when initializing a new context. A mechanism to this 370 end, context replication [RFC4164], makes the context establishment 371 step faster and more efficient, by replicating part of an existing 372 context to a new flow. The conclusion from [RFC4413] is that part of 373 the IP sub-context, some TCP fields, and some context values can be 374 replicated since they seldom change or change with only a small jump. 376 ROHC-TCP also compresses the following headers: IPv6 Destination 377 Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by- 378 Hop Options header [RFC2460], Authentication Header (AH) [RFC4302], 379 Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] and the 380 Minimal Encapsulation header (MINE) [RFC2004]. 382 Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any 383 special treatment in this document, for reasons similar to those 384 described in [RFC3095]. 386 4. Overview of the TCP/IP Profile (Informative) 388 4.1. General Concepts 390 ROHC-TCP uses the ROHC protocol as described in [RFC5795]. ROHC-TCP 391 supports context replication as defined in [RFC4164]. Context 392 replication can be particularly useful for short-lived TCP flows 393 [RFC4413]. 395 4.2. Compressor and Decompressor Interactions 397 4.2.1. Compressor Operation 399 Header compression with ROHC can be conceptually characterized as the 400 interaction of a compressor with a decompressor state machine. The 401 compressor's task is to minimally send the information needed to 402 successfully decompress a packet, based on a certain confidence 403 regarding the state of the decompressor context. 405 For ROHC-TCP compression, the compressor normally starts compression 406 with the initial assumption that the decompressor has no useful 407 information to process the new flow, and sends Initialization and 408 Refresh (IR) packets. Alternatively, the compressor may also support 409 Context Replication (CR) and use IR-CR packets [RFC4164], which 410 attempts to reuse context information related to another flow. 412 The compressor can then adjust the compression level based on its 413 confidence that the decompressor has the necessary information to 414 successfully process the Compressed (CO) packets that it selects. In 415 other words, the task of the compressor is to ensure that the 416 decompressor operates in the state that allows decompression of the 417 most efficient CO packet(s), and to allow the decompressor to move to 418 that state as soon as possible otherwise. 420 4.2.2. Decompressor Feedback 422 The ROHC-TCP profile can be used in environments with or without 423 feedback capabilities from decompressor to compressor. ROHC-TCP 424 however assumes that if a ROHC feedback channel is available and if 425 this channel is used at least once by the decompressor for a specific 426 ROHC-TCP context, this channel will be used during the entire 427 compression operation for that context. If the feedback channel 428 disappears, compression should be restarted. 430 The reception of either positive acknowledgment (ACKs) or negative 431 acknowledgment (NACKs) establishes the feedback channel from the 432 decompressor for the context for which the feedback was received. 433 Once there is an established feedback channel for a specific context, 434 the compressor should make use of this feedback to estimate the 435 current state of the decompressor. This helps in increasing the 436 compression efficiency by providing the information needed for the 437 compressor to achieve the necessary confidence level. 439 The ROHC-TCP feedback mechanism is limited in its applicability by 440 the number of (least significant bit (LSB) encoded) master sequence 441 number (MSN) (see Section 6.1.1) bits used in the FEEDBACK-2 format 442 (see Section 8.3). It is not suitable for a decompressor to use 443 feedback altogether where the MSN bits in the feedback could wrap 444 around within one round-trip time. Instead, unidirectional operation 445 -- where the compressor periodically sends larger context-updating 446 packets -- is more appropriate. 448 4.3. Packet Formats and Encoding Methods 450 The packet formats and encoding methods used for ROHC-TCP are defined 451 using the formal notation [RFC4997]. The formal notation is used to 452 provide an unambiguous representation of the packet formats and a 453 clear definition of the encoding methods. 455 4.3.1. Compressing TCP Options 457 The TCP options in ROHC-TCP are compressed using a list compression 458 encoding that allows option content to be established so that TCP 459 options can be added to the context without having to send all TCP 460 options uncompressed. 462 4.3.2. Compressing Extension Headers 464 ROHC-TCP compresses the extension headers as listed in Section 3.2. 465 These headers are treated exactly as other headers and thus have a 466 static chain, a dynamic chain, an irregular chain, and a chain for 467 context replication (Section 6.2). 469 This means that headers appearing in or disappearing from the flow 470 being compressed will lead to changes to the static chain. However, 471 the change pattern of extension headers is not deemed to impair 472 compression efficiency with respect to this design strategy. 474 4.4. Expected Compression Ratios with ROHC-TCP 476 The following table illustrates typical compression ratios that can 477 be expected when using ROHC-TCP and IPHC [RFC2507]. 479 The figures in the table assume that the compression context has 480 already been properly initialized. For the TS option, the Timestamp 481 is assumed to change with small values. All TCP options include a 482 suitable number of No Operation (NOP) options [RFC0793] for padding 483 and/or alignment. Finally, in the examples for IPv4, a sequential 484 IP-ID behavior is assumed. 486 Total Header Size (octets) 487 ROHC-TCP IPHC 488 Unc. DATA ACK DATA ACK 489 IPv4+TCP+TS 52 8 8 18 18 490 IPv4+TCP+TS 52 7 6 16 16 (1) 491 IPv6+TCP+TS 72 8 7 18 18 492 IPv6+TCP+no opt 60 6 5 6 6 493 IPv6+TCP+SACK 80 - 15 - 80 (2) 494 IPv6+TCP+SACK 80 - 9 - 26 (3) 496 (1) The payload size of the data stream is constant. 497 (2) The SACK option appears in the header, but was not present 498 in the previous packet. Two SACK blocks are assumed. 499 (3) The SACK option appears in the header, and was also present 500 in the previous packet (with different SACK blocks). 501 Two SACK blocks are assumed. 503 The table below illustrates the typical initial compression ratios 504 for ROHC-TCP and IPHC. The data stream in the example is assumed to 505 be IPv4+TCP, with a sequential behavior for the IP-ID. The following 506 options are assumed present in the SYN packet: TS, MSS, and WSCALE, 507 with an appropriate number of NOP options. 509 Total Header Size (octets) 510 Unc. ROHC-TCP IPHC 511 1st packet (SYN) 60 49 60 512 2nd packet 52 12 52 514 The figures in the table assume that the compressor has received an 515 acknowledgment from the decompressor before compressing the second 516 packet, which can be expected when feedback is used in ROHC-TCP. 517 This is because in the most common case, the TCP ACKs are expected to 518 take the same return path, and because TCP does not send more packets 519 until the TCP SYN packet has been acknowledged. 521 5. Compressor and Decompressor Logic (Normative) 522 5.1. Context Initialization 524 The static context of ROHC-TCP flows can be initialized in either of 525 two ways: 527 1. By using an IR packet as in Section 7.1, where the profile number 528 is 0x06 and the static chain ends with the static part of a TCP 529 header. 531 2. By replicating an existing context using the mechanism defined by 532 [RFC4164]. This is done with the IR-CR packet defined in 533 Section 7.2, where the profile number is 0x06. 535 5.2. Compressor Operation 537 5.2.1. Compression Logic 539 The task of the compressor is to determine what data must be sent 540 when compressing a TCP/IP packet, so that the decompressor can 541 successfully reconstruct the original packet based on its current 542 state. The selection of the type of compressed header to send thus 543 depends on a number of factors, including: 545 o The change behavior of header fields in the flow, e.g., conveying 546 the necessary information within the restrictions of the set of 547 available packet formats. 549 o The compressor's level of confidence regarding decompressor state, 550 e.g., by selecting header formats updating the same type of 551 information for a number of consecutive packets or from the 552 reception of decompressor feedback (ACKs and/or NACKs). 554 o Additional robustness required for the flow, e.g., periodic 555 refreshes of static and dynamic information using IR and IR-DYN 556 packets when decompressor feedback is not expected. 558 The impact of these factors on the compressor's packet type selection 559 is described in more detail in the following subsections. 561 In this section, a "higher compression state" means that less data 562 will be sent in compressed packets, i.e., smaller compressed headers 563 are used, while a lower compression state means that a larger amount 564 of data will be sent using larger compressed headers. 566 5.2.1.1. Optimistic Approach 568 The optimistic approach is the principle by which a compressor sends 569 the same type of information for a number of packets (consecutively 570 or not) until it is fairly confident that the decompressor has 571 received the information. The optimistic approach is useful to 572 ensure robustness when ROHC-TCP is used to compress packets over 573 lossy links. 575 Therefore, if field X in the uncompressed packet changes value, the 576 compressor MUST use a packet type that contains an encoding for field 577 X until it has gained confidence that the decompressor has received 578 at least one packet containing the new value for X. The compressor 579 SHOULD choose a compressed format with the smallest header that can 580 convey the changes needed to fulfill the optimistic approach 581 condition used. 583 5.2.1.2. Periodic Context Refreshes 585 When the optimistic approach is used, there will always be a 586 possibility of decompression failures since the decompressor may not 587 have received sufficient information for correct decompression. 589 Therefore, until the decompressor has established a feedback channel, 590 the compressor SHOULD periodically move to a lower compression state 591 and send IR and/or IR-DYN packets. These refreshes can be based on 592 timeouts, on the number of compressed packets sent for the flow, or 593 any other strategy specific to the implementation. Once the feedback 594 channel is established, the decompressor MAY stop performing periodic 595 refreshes. 597 5.2.2. Feedback Logic 599 The semantics of feedback messages, acknowledgments (ACKs) and 600 negative acknowledgments (NACKs or STATIC-NACKs), are defined in 601 Section 5.2.4.1 of [RFC5795]. 603 5.2.2.1. Optional Acknowledgments (ACKs) 605 The compressor MAY use acknowledgment feedback (ACKs) to move to a 606 higher compression state. 608 Upon reception of an ACK for a context-updating packet, the 609 compressor obtains confidence that the decompressor has received the 610 acknowledged packet and that it has observed changes in the packet 611 flow up to the acknowledged packet. 613 This functionality is optional, so a compressor MUST NOT expect to 614 get such ACKs, even if a feedback channel is available and has been 615 established for that flow. 617 5.2.2.2. Negative Acknowledgments (NACKs) 619 The compressor uses feedback from the decompressor to move to a lower 620 compression state (NACKs). 622 On reception of a NACK feedback, the compressor SHOULD: 624 o assume that only the static part of the decompressor is valid, and 626 o re-send all dynamic information (via an IR or IR-DYN packet) the 627 next time it compresses a packet for the indicated flow 629 unless it has confidence that information sent after the packet being 630 acknowledged already provides a suitable response to the NACK 631 feedback. In addition, the compressor MAY use a CO packet carrying a 632 7-bit Cyclic Redundancy Check (CRC) if it can determine with enough 633 confidence what information provides a suitable response to the NACK 634 feedback. 636 On reception of a STATIC-NACK feedback, the compressor SHOULD: 638 o assume that the decompressor has no valid context, and 640 o re-send all static and all dynamic information (via an IR packet) 641 the next time it compresses a packet for the indicated flow 643 unless it has confidence that information sent after the packet that 644 is being acknowledged already provides a suitable response to the 645 STATIC-NACK feedback. 647 5.2.3. Context Replication 649 A compressor MAY support context replication by implementing the 650 additional compression and feedback logic defined in [RFC4164]. 652 5.3. Decompressor Operation 654 5.3.1. Decompressor States and Logic 656 The three states of the decompressor are No Context (NC), Static 657 Context (SC), and Full Context (FC). The decompressor starts in its 658 lowest compression state, the NC state. Successful decompression 659 will always move the decompressor to the FC state. The decompressor 660 state machine normally never leaves the FC state once it has entered 661 this state; only repeated decompression failures will force the 662 decompressor to transit downwards to a lower state. 664 Below is the state machine for the decompressor. Details of the 665 transitions between states and decompression logic are given in the 666 subsections following the figure. 668 Success 669 +-->------>------>------>------>------>--+ 670 | | 671 No Static | No Dynamic Success | Success 672 +-->--+ | +-->--+ +--->----->---+ +-->--+ 673 | | | | | | | | | 674 | v | | v | v | v 675 +-----------------+ +---------------------+ +-------------------+ 676 | No Context (NC) | | Static Context (SC) | | Full Context (FC) | 677 +-----------------+ +---------------------+ +-------------------+ 678 ^ | ^ | 679 | Static Context | | Context Damage Assumed | 680 | Damage Assumed | | | 681 +-----<------<------<-----+ +-----<------<------<-----+ 683 5.3.1.1. Reconstruction and Verification 685 When decompressing an IR or an IR-DYN packet, the decompressor MUST 686 validate the integrity of the received header using CRC-8 validation 687 [RFC5795]. If validation fails, the packet MUST NOT be delivered to 688 upper layers. 690 Upon receiving an IR-CR packet, the decompressor MUST perform the 691 actions as specified in [RFC4164]. 693 When decompressing other packet types (e.g., CO packets), the 694 decompressor MUST validate the outcome of the decompression attempt 695 using CRC verification [RFC5795]. If verification fails, a 696 decompressor implementation MAY attempt corrective or repair measures 697 on the packet, and the result of any attempt MUST be validated using 698 the CRC verification; otherwise, the packet MUST NOT be delivered to 699 upper layers. 701 When the CRC-8 validation or the CRC verification of the received 702 header is successful, the decompressor SHOULD update its context with 703 the information received in the current header; the decompressor then 704 passes the reconstructed packet to the system's network layer. 705 Otherwise, the decompressor context MUST NOT be updated. 707 If the received packet is older than the current reference packet, 708 e.g., based on the master sequence number (MSN) in the compressed 709 packet, the decompressor MAY refrain from updating the context using 710 the information received in the current packet, even if the 711 correctness of its header was successfully verified. 713 5.3.1.2. Detecting Context Damage 715 All header formats carry a CRC and are context updating. A packet 716 for which the CRC succeeds updates the reference values of all header 717 fields, either explicitly (from the information about a field carried 718 within the compressed header) or implicitly (fields that are inferred 719 from other fields). 721 The decompressor may assume that some or the entire context is 722 invalid, following one or more failures to validate or verify a 723 header using the CRC. Because the decompressor cannot know the exact 724 reason(s) for a CRC failure or what field caused it, the validity of 725 the context hence does not refer to what exact context entry is 726 deemed valid or not. 728 Validity of the context rather relates to the detection of a problem 729 with the context. The decompressor first assumes that the type of 730 information that most likely caused the failure(s) is the state that 731 normally changes for each packet, i.e., context damage of the dynamic 732 part of the context. Upon repeated failures and unsuccessful 733 repairs, the decompressor then assumes that the entire context, 734 including the static part, needs to be repaired, i.e., static context 735 damage. 737 Context Damage Detection 739 The assumption of context damage means that the decompressor will 740 not attempt decompression of a CO header that carries a 3-bit CRC, 741 and only attempt decompression of IR, IR-DYN, or IR-CR headers or 742 CO headers protected by a CRC-7. 744 Static Context Damage Detection 746 The assumption of static context damage means that the 747 decompressor refrains from attempting decompression of any type of 748 header other than the IR header. 750 How these assumptions are made, i.e., how context damage is detected, 751 is open to implementations. It can be based on the residual error 752 rate, where a low error rate makes the decompressor assume damage 753 more often than on a high-rate link. 755 The decompressor implements these assumptions by selecting the type 756 of compressed header for which it may attempt decompression. In 757 other words, validity of the context refers to the ability of a 758 decompressor to attempt or not attempt decompression of specific 759 packet types. 761 5.3.1.3. No Context (NC) State 763 Initially, while working in the No Context (NC) state, the 764 decompressor has not yet successfully decompressed a packet. 766 Allowing decompression: 768 In the NC state, only packets carrying sufficient information on 769 the static fields (IR and IR-CR packets) can be decompressed; 770 otherwise, the packet MUST NOT be decompressed and MUST NOT be 771 delivered to upper layers. 773 Feedback logic: 775 In the NC state, the decompressor should send a STATIC-NACK if a 776 packet of a type other than IR is received, or if decompression of 777 an IR packet has failed, subject to the feedback rate limitation 778 as described in Section 5.3.2 780 Once a packet has been validated and decompressed correctly, the 781 decompressor MUST transit to the FC state. 783 5.3.1.4. Static Context (SC) State 785 When the decompressor is in the Static Context (SC) state, only the 786 static part of the decompressor context is valid. 788 From the SC state, the decompressor moves back to the NC state if 789 static context damage is detected. 791 Allowing decompression: 793 In the SC state, packets carrying sufficient information on the 794 dynamic fields covered by an 8-bit CRC (e.g., IR and IR-DYN) or CO 795 packets covered by a 7-bit CRC can be decompressed; otherwise, the 796 packet MUST NOT be decompressed and MUST NOT be delivered to upper 797 layers. 799 Feedback logic: 801 In the SC state, the decompressor should send a STATIC-NACK if CRC 802 validation of an IR/IR-DYN/IR-CR fails and static context damage 803 is assumed. If any other packet type is received, the 804 decompressor should send a NACK. Both of the above cases are 805 subject to the feedback rate limitation as described in 806 Section 5.3.2. 808 Once a packet has been validated and decompressed correctly, the 809 decompressor MUST transit to the FC state. 811 5.3.1.5. Full Context (FC) State 813 In the Full Context (FC) state, both the static and the dynamic parts 814 of the decompressor context are valid. From the FC state, the 815 decompressor moves back to the SC state if context damage is 816 detected. 818 Allowing decompression: 820 In the FC state, decompression can be attempted regardless of the 821 type of packet received. 823 Feedback logic: 825 In the FC state, the decompressor should send a NACK if the 826 decompression of any packet type fails and context damage is 827 assumed, subject to the feedback rate limitation as described in 828 Section 5.3.2. 830 5.3.2. Feedback Logic 832 The decompressor MAY send positive feedback (ACKs) to initially 833 establish the feedback channel for a particular flow. Either 834 positive feedback (ACKs) or negative feedback (NACKs) establishes 835 this channel. 837 Once the feedback channel is established, the decompressor is 838 REQUIRED to continue sending NACKs or STATIC-NACKs for as long as the 839 context is associated with the same profile, in this case with 840 profile 0x0006, as per the logic defined for each state in 841 Section 5.3.1. 843 The decompressor MAY send ACKs upon successful decompression of any 844 packet type. In particular, when a packet carrying a significant 845 context update is correctly decompressed, the decompressor MAY send 846 an ACK. 848 The decompressor should limit the rate at which it sends feedback, 849 for both ACKs and STATIC-NACK/NACKs, and should avoid sending 850 unnecessary duplicates of the same type of feedback message that may 851 be associated to the same event. 853 5.3.3. Context Replication 855 ROHC-TCP supports context replication; therefore, the decompressor 856 MUST implement the additional decompressor and feedback logic defined 857 in [RFC4164]. 859 6. Encodings in ROHC-TCP (Normative) 861 6.1. Control Fields in ROHC-TCP 863 In ROHC-TCP, a number of control fields are used by the decompressor 864 in its interpretation of the format of the packets received from the 865 compressor. 867 A control field is a field that is transmitted from the compressor to 868 the decompressor, but is not part of the uncompressed header. Values 869 for control fields can be set up in the context of both the 870 compressor and the decompressor. Once established at the 871 decompressor, the values of these fields should be kept until updated 872 by another packet. 874 6.1.1. Master Sequence Number (MSN) 876 There is no field in the TCP header that can act as the master 877 sequence number for TCP compression, as explained in [RFC4413], 878 Section 5.6. 880 To overcome this problem, ROHC-TCP introduces a control field called 881 the Master Sequence Number (MSN) field. The MSN field is created at 882 the compressor, rather than using one of the fields already present 883 in the uncompressed header. The compressor increments the value of 884 the MSN by one for each packet that it sends. 886 The MSN field has the following two functions: 888 1. Differentiating between packets when sending feedback data. 890 2. Inferring the value of incrementing fields such as the IP-ID. 892 The MSN field is present in every packet sent by the compressor. The 893 MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent 894 in full in IR/IR-DYN packets. The decompressor always sends the MSN 895 as part of the feedback information. The compressor can later use 896 the MSN to infer which packet the decompressor is acknowledging. 898 When the MSN is initialized, it SHOULD be initialized to a random 899 value. The compressor should only initialize a new MSN for the 900 initial IR or IR-CR packet sent for a CID that corresponds to a 901 context that is not already associated with this profile. In other 902 words, if the compressor reuses the same CID to compress many TCP 903 flows one after the other, the MSN is not reinitialized but rather 904 continues to increment monotonically. 906 For context replication, the compressor does not use the MSN of the 907 base context when sending the IR-CR packet, unless the replication 908 process overwrites the base context (i.e., Base CID == CID). 909 Instead, the compressor uses the value of the MSN if it already 910 exists in the ROHC-TCP context being associated with the new flow 911 (CID); otherwise, the MSN is initialized to a new value. 913 6.1.2. IP-ID Behavior 915 The IP-ID field of the IPv4 header can have different change 916 patterns. Conceptually, a compressor monitors changes in the value 917 of the IP-ID field and selects encoding methods and packet formats 918 that are the closest match to the observed change pattern. 920 ROHC-TCP defines different types of compression techniques for the 921 IP-ID, to provide the flexibility to compress any of the behaviors it 922 may observe for this field: sequential in network byte order (NBO), 923 sequential byte-swapped, random (RND), or constant to a value of 924 zero. 926 The compressor monitors changes in the value of the IP-ID field for a 927 number of packets, to identify which one of the above listed 928 compression alternatives is the closest match to the observed change 929 pattern. The compressor can then select packet formats and encoding 930 methods based on the identified field behavior. 932 If more than one level of IP headers is present, ROHC-TCP can assign 933 a sequential behavior (NBO or byte-swapped) only to the IP-ID of the 934 innermost IP header. This is because only this IP-ID can possibly 935 have a sufficiently close correlation with the MSN (see also 936 Section 6.1.1) to compress it as a sequentially changing field. 937 Therefore, a compressor MUST NOT assign either the sequential (NBO) 938 or the sequential byte-swapped behavior to tunneling headers. 940 The control field for the IP-ID behavior determines which set of 941 packet formats will be used. These control fields are also used to 942 determine the contents of the irregular chain item (see Section 6.2) 943 for each IP header. 945 6.1.3. Explicit Congestion Notification (ECN) 947 When ECN [RFC3168] is used once on a flow, the ECN bits could change 948 quite often. ROHC-TCP maintains a control field in the context to 949 indicate whether or not ECN is used. This control field is 950 transmitted in the dynamic chain of the TCP header, and its value can 951 be updated using specific compressed headers carrying a 7-bit CRC. 953 When this control field indicates that ECN is being used, items of 954 all IP and TCP headers in the irregular chain include bits used for 955 ECN. To preserve octet-alignment, all of the TCP reserved bits are 956 transmitted and, for outer IP headers, the entire Type of Service/ 957 Traffic Class (TOS/TC) field is included in the irregular chain. 958 When there is only one IP header present in the packet (i.e., no IP 959 tunneling is used), this compression behavior allows the compressor 960 to handle changes in the ECN bits by adding a single octet to the 961 compressed header. 963 The reason for including the ECN bits of all IP headers in the 964 compressed packet when the control field is set is that the profile 965 needs to efficiently compress flows containing IP tunnels using the 966 "full-functionality option" of Section 9.1 of [RFC3168]. For these 967 flows, a change in the ECN bits of an inner IP header is propagated 968 to the outer IP headers. When the "limited-functionality" option is 969 used, the compressor will therefore sometimes send one octet more 970 than necessary per tunnel header, but this has been considered a 971 reasonable tradeoff when designing this profile. 973 6.2. Compressed Header Chains 975 Some packet types use one or more chains containing sub-header 976 information. The function of a chain is to group fields based on 977 similar characteristics, such as static, dynamic, or irregular 978 fields. Chaining is done by appending an item for each header to the 979 chain in their order of appearance in the uncompressed packet, 980 starting from the fields in the outermost header. 982 Chains are defined for all headers compressed by ROHC-TCP, as listed 983 below. Also listed are the names of the encoding methods used to 984 encode each of these protocol headers. 986 o TCP [RFC0793], encoding method: "tcp" 988 o IPv4 [RFC0791], encoding method: "ipv4" 990 o IPv6 [RFC2460], encoding method: "ipv6" 992 o AH [RFC4302], encoding method: "ah" 994 o GRE [RFC2784][RFC2890], encoding method: "gre" 996 o MINE [RFC2004], encoding method: "mine" 998 o IPv6 Destination Options header [RFC2460], encoding method: 999 "ip_dest_opt" 1001 o IPv6 Hop-by-Hop Options header [RFC2460], encoding method: 1002 "ip_hop_opt" 1004 o IPv6 Routing header [RFC2460], encoding method: "ip_rout_opt" 1006 Static chain: 1008 The static chain consists of one item for each header of the chain 1009 of protocol headers to be compressed, starting from the outermost 1010 IP header and ending with a TCP header. In the formal description 1011 of the packet formats, this static chain item for each header is a 1012 format whose name is suffixed by "_static". The static chain is 1013 only used in IR packets. 1015 Dynamic chain: 1017 The dynamic chain consists of one item for each header of the 1018 chain of protocol headers to be compressed, starting from the 1019 outermost IP header and ending with a TCP header. The dynamic 1020 chain item for the TCP header also contains a compressed list of 1021 TCP options (see Section 6.3). In the formal description of the 1022 packet formats, the dynamic chain item for each header type is a 1023 format whose name is suffixed by "_dynamic". The dynamic chain is 1024 used in both IR and IR-DYN packets. 1026 Replicate chain: 1028 The replicate chain consists of one item for each header in the 1029 chain of protocol headers to be compressed, starting from the 1030 outermost IP header and ending with a TCP header. The replicate 1031 chain item for the TCP header also contains a compressed list of 1032 TCP options (see Section 6.3). In the formal description of the 1033 packet formats, the replicate chain item for each header type is a 1034 format whose name is suffixed by "_replicate". Header fields that 1035 are not present in the replicate chain are replicated from the 1036 base context. The replicate chain is only used in the IR-CR 1037 packet. 1039 Irregular chain: 1041 The structure of the irregular chain is analogous to the structure 1042 of the static chain. For each compressed packet, the irregular 1043 chain is appended at the specified location in the general format 1044 of the compressed packets as defined in Section 7.3. This chain 1045 also includes the irregular chain items for TCP options as defined 1046 in Section 6.3.6, which are placed directly after the irregular 1047 chain item of the TCP header, and in the same order as the options 1048 appear in the uncompressed packet. In the formal description of 1049 the packet formats, the irregular chain item for each header type 1050 is a format whose name is suffixed by "_irregular". The irregular 1051 chain is used only in CO packets. 1053 The format of the irregular chain for the innermost IP header 1054 differs from the format of outer IP headers, since this header is 1055 part of the compressed base header. 1057 6.3. Compressing TCP Options with List Compression 1059 This section describes in detail how list compression is applied to 1060 the TCP options. In the definition of the packet formats for ROHC- 1061 TCP, the most frequent TCP options have one encoding method each, as 1062 listed in the table below. 1064 +-----------------+------------------------+ 1065 | Option name | Encoding method name | 1066 +-----------------+------------------------+ 1067 | NOP | tcp_opt_nop | 1068 | EOL | tcp_opt_eol | 1069 | MSS | tcp_opt_mss | 1070 | WINDOW SCALE | tcp_opt_wscale | 1071 | TIMESTAMP | tcp_opt_ts | 1072 | SACK-PERMITTED | tcp_opt_sack_permitted | 1073 | SACK | tcp_opt_sack | 1074 | Generic options | tcp_opt_generic | 1075 +-----------------+------------------------+ 1077 Each of these encoding methods has an uncompressed format, a format 1078 suffixed by "_list_item" and a format suffixed by "_irregular". In 1079 some cases, a single encoding method may have multiple "_list_item" 1080 or "_irregular" formats, in which case bindings inside these formats 1081 determine what format is used. This is further described in the 1082 following sections. 1084 6.3.1. List Compression 1086 The TCP options in the uncompressed packet can be represented as an 1087 ordered list, whose order and presence are usually constant between 1088 packets. The generic structure of such a list is as follows: 1090 +--------+--------+--...--+--------+ 1091 list: | item 1 | item 2 | | item n | 1092 +--------+--------+--...--+--------+ 1094 To compress this list, ROHC-TCP uses a list compression scheme, which 1095 compresses each of these items individually and combines them into a 1096 compressed list. 1098 The basic principles of list-based compression are the following: 1100 1) When a context is being initialized, a complete representation 1101 of the compressed list of options is transmitted. All options 1102 that have any content are present in the compressed list of items 1103 sent by the compressor. 1105 Then, once the context has been initialized: 1107 2) When the structure AND the content of the list are unchanged, 1108 no information about the list is sent in compressed headers. 1110 3) When the structure of the list is constant, and when only the 1111 content defined within the irregular format for one or more 1112 options is changed, no information about the list needs to be sent 1113 in compressed base headers; the irregular content is sent as part 1114 of the irregular chain, as described in Section 6.3.6. 1116 4) When the structure of the list changes, a compressed list is 1117 sent in the compressed base header, including a representation of 1118 its structure and order. Content defined within the irregular 1119 format of an option can still be sent as part of the irregular 1120 chain (as described in Section 6.3.6), provided that the item 1121 content is not part of the compressed list. 1123 6.3.2. Table-Based Item Compression 1125 The Table-based item compression compresses individual items sent in 1126 compressed lists. The compressor assigns a unique identifier, 1127 "Index", to each item, "Item", of a list. 1129 Compressor Logic 1131 The compressor conceptually maintains an item table containing all 1132 items, indexed using "Index". The (Index, Item) pair is sent 1133 together in compressed lists until the compressor gains enough 1134 confidence that the decompressor has observed the mapping between 1135 items and their respective index. Confidence is obtained from the 1136 reception of an acknowledgment from the decompressor, or by 1137 sending (Index, Item) pairs using the optimistic approach. Once 1138 confidence is obtained, the index alone is sent in compressed 1139 lists to indicate the presence of the item corresponding to this 1140 index. 1142 The compressor may reassign an existing index to a new item, by 1143 re-establishing the mapping using the procedure described above. 1145 Decompressor Logic 1147 The decompressor conceptually maintains an item table that 1148 contains all (Index, Item) pairs received. The item table is 1149 updated whenever an (Index, Item) pair is received and 1150 decompression is successfully verified using the CRC. The 1151 decompressor retrieves the item from the table whenever an index 1152 without an accompanying item is received. 1154 If an index without an accompanying item is received and the 1155 decompressor does not have any context for this index, the header 1156 MUST be discarded and a NACK SHOULD be sent. 1158 6.3.3. Encoding of Compressed Lists 1160 Each item present in a compressed list is represented by: 1162 o an index into the table of items 1164 o a presence bit indicating if a compressed representation of the 1165 item is present in the list 1167 o an item (if the presence bit is set) 1169 Decompression of an item will fail if the presence bit is not set and 1170 the decompressor has no entry in the context for that item. 1172 A compressed list of TCP options uses the following encoding: 1174 0 1 2 3 4 5 6 7 1175 +---+---+---+---+---+---+---+---+ 1176 | Reserved |PS | m | 1177 +---+---+---+---+---+---+---+---+ 1178 | XI_1, ..., XI_m | m octets, or m * 4 bits 1179 / --- --- --- ---/ 1180 | : Padding : if PS = 0 and m is odd 1181 +---+---+---+---+---+---+---+---+ 1182 | | 1183 / item_1, ..., item_n / variable 1184 | | 1185 +---+---+---+---+---+---+---+---+ 1187 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1188 discard the packet. 1190 PS: Indicates size of XI fields: 1192 PS = 0 indicates 4-bit XI fields; 1194 PS = 1 indicates 8-bit XI fields. 1196 m: Number of XI item(s) in the compressed list. 1198 XI_1, ..., XI_m: m XI items. Each XI represents one TCP option in 1199 the uncompressed packet, in the same order as they appear in the 1200 uncompressed packet. 1202 The format of an XI item is as follows: 1204 +---+---+---+---+ 1205 PS = 0: | X | Index | 1206 +---+---+---+---+ 1208 0 1 2 3 4 5 6 7 1209 +---+---+---+---+---+---+---+---+ 1210 PS = 1: | X | Reserved | Index | 1211 +---+---+---+---+---+---+---+---+ 1213 X: Indicates whether the item is present in the list: 1215 X = 1 indicates that the item corresponding to the Index is 1216 sent in the item_1, ..., item_n list; 1218 X = 0 indicates that the item corresponding to the Index is 1219 not sent and is instead included in the irregular chain. 1221 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1222 discard the packet. 1224 Index: An index into the item table. See Section 6.3.4. 1226 When 4-bit XI items are used, the XI items are placed in octets 1227 in the following manner: 1229 0 1 2 3 4 5 6 7 1230 +---+---+---+---+---+---+---+---+ 1231 | XI_k | XI_k + 1 | 1232 +---+---+---+---+---+---+---+---+ 1234 Padding: A 4-bit padding field is present when PS = 0 and the 1235 number of XIs is odd. The Padding field MUST be set to zero; 1236 otherwise, the decompressor MUST discard the packet. 1238 Item 1, ..., item n: Each item corresponds to an XI with X = 1 in 1239 XI 1, ..., XI m. The format of the entries in the item list is 1240 described in Section 6.3. The compressed format(s) suffixed by 1241 "_list_item" in the encoding methods defines the item inside the 1242 compressed item list. 1244 6.3.4. Item Table Mappings 1246 The item table for TCP options list compression is limited to 16 1247 different items, since it is unlikely that any packet flow will 1248 contain a larger number of unique options. 1250 The mapping between the TCP option type and table indexes are listed 1251 in the table below: 1253 +-----------------+---------------+ 1254 | Option name | Table index | 1255 +-----------------+---------------+ 1256 | NOP | 0 | 1257 | EOL | 1 | 1258 | MSS | 2 | 1259 | WINDOW SCALE | 3 | 1260 | TIMESTAMP | 4 | 1261 | SACK-PERMITTED | 5 | 1262 | SACK | 6 | 1263 | Generic options | 7-15 | 1264 +-----------------+---------------+ 1266 Some TCP options are used more frequently than others. To simplify 1267 their compression, a part of the item table is reserved for these 1268 option types, as shown on the table above. Both the compressor and 1269 the decompressor MUST use these mappings between item and indexes to 1270 (de)compress TCP options when using list compression. 1272 It is expected that the option types for which an index is reserved 1273 in the item table will only appear once in a list. However, if an 1274 option type is detected twice in the same options list and if both 1275 options have a different content, the compressor should compress the 1276 second occurrence of the option type by mapping it to a generic 1277 compressed option. Otherwise, if the options have the exact same 1278 content, the compressor can still use the same table index for both. 1280 The NOP option 1282 The NOP option can appear more than once in the list. However, 1283 since its value is always the same, no context information needs 1284 to be transmitted. Multiple NOP options can thus be mapped to the 1285 same index. Since the NOP option does not have any content when 1286 compressed as a "_list_item", it will never be present in the item 1287 list. For consistency, the compressor should still establish an 1288 entry in the list by setting the presence bit, as done for the 1289 other type of options. 1291 List compression always preserves the original order of each item 1292 in the decompressed list, whether or not the item is present in 1293 the compressed "_list_item" or if multiple items of the same type 1294 can be mapped to the same index, as for the NOP option. 1296 The EOL option 1298 The size of the compressed format for the EOL option can be larger 1299 than one octet, and it is defined so that it includes the option 1300 padding. This is because the EOL should terminate the parsing of 1301 the options, but it can also be followed by padding octets that 1302 all have the value zero. 1304 The Generic option 1306 The Generic option can be used to compress any type of TCP option 1307 that does not have a reserved index in the item table. 1309 6.3.5. Compressed Lists in Dynamic Chain 1311 A compressed list for TCP options that is part of the dynamic chain 1312 (e.g., in IR or IR-DYN packets) must have all its list items present, 1313 i.e., all X-bits in the XI list MUST be set. 1315 6.3.6. Irregular Chain Items for TCP Options 1317 The "_list_item" represents the option inside the compressed item 1318 list, and the "_irregular" format is used for the option fields that 1319 are expected to change with each packet. When an item of the 1320 specified type is present in the current context, these irregular 1321 fields are present in each compressed packet, as part of the 1322 irregular chain. Since many of the TCP option types are not expected 1323 to change for the duration of a flow, many of the "_irregular" 1324 formats are empty. 1326 The irregular chain for TCP options is structured analogously to the 1327 structure of the TCP options in the uncompressed packet. If a 1328 compressed list is present in the compressed packet, then the 1329 irregular chain for TCP options must not contain irregular items for 1330 the list items that are transmitted inside the compressed list (i.e., 1331 items in the list that have the X-bit set in its XI). The items that 1332 are not present in the compressed list, but are present in the 1333 uncompressed list, must have their respective irregular items present 1334 in the irregular chain. 1336 6.3.7. Replication of TCP Options 1338 The entire table of TCP options items is always replicated when using 1339 the IR-CR packet. In the IR-CR packet, the list of options for the 1340 new flow is also transmitted as a compressed list in the IR-CR 1341 packet. 1343 6.4. Profile-Specific Encoding Methods 1345 This section defines encoding methods that are specific to this 1346 profile. These methods are used in the formal definition of the 1347 packet formats in Section 8. 1349 6.4.1. inferred_ip_v4_header_checksum 1351 This encoding method compresses the Header Checksum field of the IPv4 1352 header. This checksum is defined in [RFC0791] as follows: 1354 Header Checksum: 16 bits 1356 A checksum on the header only. Since some header fields change 1357 (e.g., time to live), this is recomputed and verified at each 1358 point that the internet header is processed. 1360 The checksum algorithm is: 1362 The checksum field is the 16 bit one's complement of the one's 1363 complement sum of all 16 bit words in the header. For purposes 1364 of computing the checksum, the value of the checksum field is 1365 zero. 1367 As described above, the header checksum protects individual hops from 1368 processing a corrupted header. When almost all IP header information 1369 is compressed away, and when decompression is verified by a CRC 1370 computed over the original header for every compressed packet, there 1371 is no point in having this additional checksum; instead, it can be 1372 recomputed at the decompressor side. 1374 The "inferred_ip_v4_header_checksum" encoding method thus compresses 1375 the IPv4 header checksum down to a size of zero bits. Using this 1376 encoding method, the decompressor infers the value of this field 1377 using the computation above. 1379 This encoding method implicitly assumes that the compressor will not 1380 process a corrupted header; otherwise, it cannot guarantee that the 1381 checksum as recomputed by the decompressor will be bitwise identical 1382 to its original value before compression. 1384 6.4.2. inferred_mine_header_checksum 1386 This encoding method compresses the minimal encapsulation header 1387 checksum. This checksum is defined in [RFC2004] as follows: 1389 Header Checksum 1391 The 16-bit one's complement of the one's complement sum of all 1392 16-bit words in the minimal forwarding header. For purposes of 1393 computing the checksum, the value of the checksum field is 0. 1394 The IP header and IP payload (after the minimal forwarding 1395 header) are not included in this checksum computation. 1397 The "inferred_mine_header_checksum" encoding method compresses the 1398 minimal encapsulation header checksum down to a size of zero bits, 1399 i.e., no bits are transmitted in compressed headers for this field. 1400 Using this encoding method, the decompressor infers the value of this 1401 field using the above computation. 1403 The motivations and the assumptions for inferring this checksum are 1404 similar to the ones explained above in Section 6.4.1. 1406 6.4.3. inferred_ip_v4_length 1408 This encoding method compresses the Total Length field of the IPv4 1409 header. The Total Length field of the IPv4 header is defined in 1410 [RFC0791] as follows: 1412 Total Length: 16 bits 1414 Total Length is the length of the datagram, measured in octets, 1415 including internet header and data. This field allows the 1416 length of a datagram to be up to 65,535 octets. 1418 The "inferred_ip_v4_length" encoding method compresses the IPv4 Total 1419 Length field down to a size of zero bits. Using this encoding 1420 method, the decompressor infers the value of this field by counting 1421 in octets the length of the entire packet after decompression. 1423 6.4.4. inferred_ip_v6_length 1425 This encoding method compresses the Payload Length field of the IPv6 1426 header. This length field is defined in [RFC2460] as follows: 1428 Payload Length: 16-bit unsigned integer 1430 Length of the IPv6 payload, i.e., the rest of the packet 1431 following this IPv6 header, in octets. (Note that any 1432 extension headers present are considered part of the payload, 1433 i.e., included in the length count.) 1435 The "inferred_ip_v6_length" encoding method compresses the Payload 1436 Length field of the IPv6 header down to a size of zero bits. Using 1437 this encoding method, the decompressor infers the value of this field 1438 by counting in octets the length of the entire packet after 1439 decompression. 1441 6.4.5. inferred_offset 1443 This encoding method compresses the data offset field of the TCP 1444 header. 1446 The "inferred_offset" encoding method is used on the Data Offset 1447 field of the TCP header. This field is defined in [RFC0793] as: 1449 Data Offset: 4 bits 1451 The number of 32 bit words in the TCP Header. This indicates 1452 where the data begins. The TCP header (even one including 1453 options) is an integral number of 32 bits long. 1455 The "inferred_offset" encoding method compresses the Data Offset 1456 field of the TCP header down to a size of zero bits. Using this 1457 encoding method, the decompressor infers the value of this field by 1458 first decompressing the TCP options list, and by then setting: 1460 data offset = (options length / 4) + 5 1462 The equation above uses integer arithmetic. 1464 6.4.6. baseheader_extension_headers 1466 In CO packets (see Section 7.3), the innermost IP header and the TCP 1467 header are combined to create a compressed base header. In some 1468 cases, the IP header will have a number of extension headers between 1469 itself and the TCP header. 1471 To remain formally correct, the base header must define some 1472 representation of these extension headers, which is what this 1473 encoding method is used for. This encoding method skips over all the 1474 extension headers and does not encode any of the fields. Changed 1475 fields in these headers are encoded in the irregular chain. 1477 6.4.7. baseheader_outer_headers 1479 This encoding method, as well as the baseheader_extension_headers 1480 encoding method described above, is needed for the specification to 1481 remain formally correct. It is used in CO packets (see Section 7.3) 1482 to describe tunneling IP headers and their respective extension 1483 headers (i.e., all headers located before the innermost IP header). 1485 This encoding method skips over all the fields in these headers and 1486 does not perform any encoding. Changed fields in outer headers are 1487 instead handled by the irregular chain. 1489 6.4.8. Scaled Encoding of Fields 1491 Some header fields will exhibit a change pattern where the field 1492 increases by a constant value or by multiples of the same value. 1494 Examples of fields that may have this behavior are the TCP Sequence 1495 Number and the TCP Acknowledgment Number. For such fields, ROHC-TCP 1496 provides the means to downscale the field value before applying LSB 1497 encoding, which allows the compressor to transmit fewer bits. 1499 To be able to use scaled encoding, the field is required to fulfill 1500 the following equation: 1502 unscaled_value = scaling_factor * scaled_value + residue 1504 To use the scaled encoding, the compressor must be confident that the 1505 decompressor has established values for the "residue" and the 1506 "scaling_factor", so that it can correctly decompress the field when 1507 only an LSB-encoded "scaled_value" is present in the compressed 1508 packet. 1510 Once the compressor is confident that the value of the scaling_factor 1511 and the value of the residue have been established in the 1512 decompressor, the compressor may send compressed packets using the 1513 scaled representation of the field. The compressor MUST NOT use 1514 scaled encoding with the value of the scaling_factor set to zero. 1516 If the compressor detects that the value of the residue has changed, 1517 or if the compressor uses a different value for the scaling factor, 1518 it MUST NOT use scaled encoding until it is confident that the 1519 decompressor has received the new value(s) of these fields. 1521 When the unscaled value of the field wraps around, the value of the 1522 residue is likely to change, even if the scaling_factor remains 1523 constant. In such a case, the compressor must act in the same way as 1524 for any other change in the residue. 1526 The following subsections describe how the scaled encoding is applied 1527 to specific fields in ROHC-TCP, in particular, how the scaling_factor 1528 and residue values are established for the different fields. 1530 6.4.8.1. Scaled TCP Sequence Number Encoding 1532 For some TCP flows, such as data transfers, the payload size will be 1533 constant over periods of time. For such flows, the TCP Sequence 1534 Number is bound to increase by multiples of the payload size between 1535 packets, which means that this field can be a suitable target for 1536 scaled encoding. When using this encoding, the payload size will be 1537 used as the scaling factor (i.e., as the value for scaling_factor) of 1538 this encoding. This means that the scaling factor does not need to 1539 be explicitly transmitted, but is instead inferred from the length of 1540 the payload in the compressed packet. 1542 Establishing scaling_factor: 1544 The scaling factor is established by sending unscaled TCP Sequence 1545 Number bits, so that the decompressor can infer the scaling_factor 1546 from the payload size. 1548 Establishing residue: 1550 The residue is established identically as the scaling_factor, 1551 i.e., by sending unscaled TCP Sequence Number bits. 1553 A detailed specification of how the TCP Sequence Number uses the 1554 scaled encoding can be found in the definitions of the packet 1555 formats, in Section 8.2. 1557 6.4.8.2. Scaled Acknowledgment Number Encoding 1559 Similar to the pattern exhibited by the TCP Sequence Number, the 1560 expected increase in the TCP Acknowledgment Number is often constant 1561 and is therefore suitable for scaled encoding. 1563 For the TCP Acknowledgment Number, the scaling factor depends on the 1564 size of packets flowing in the opposite direction; this information 1565 might not be available to the compressor/decompressor pair. For this 1566 reason, ROHC-TCP uses an explicitly transmitted scaling factor to 1567 compress the TCP Acknowledgment Number. 1569 Establishing scaling_factor: 1571 The scaling factor is established by explicitly transmitting the 1572 value of the scaling factor (called ack_stride in the formal 1573 notation in Section 8.2) to the decompressor, using one of the 1574 packet types that can carry this information. 1576 Establishing residue: 1578 The scaling residue is established by sending unscaled TCP 1579 Acknowledgment Number bits, so that the decompressor can infer its 1580 value from the unscaled value and the scaling factor (ack_stride). 1582 A detailed specification of how the TCP Acknowledgment Number uses 1583 the scaled encoding can be found in the definitions of the packet 1584 formats, in Section 8.2. 1586 The compressor MAY use the scaled acknowledgment number encoding; 1587 what value it will use as the scaling factor is up to the compressor 1588 implementation. In the case where there is a co-located decompressor 1589 processing packets of the same TCP flow in the opposite direction, 1590 the scaling factor for the sequence number used for that flow can be 1591 used by the compressor to determine a suitable scaling factor for the 1592 TCP Acknowledgment number for this flow. 1594 6.5. Encoding Methods With External Parameters 1596 A number of encoding methods in Section 8.2 have one or more 1597 arguments for which the derivation of the parameter's value is 1598 outside the scope of the ROHC-FN specification of the header formats. 1599 This section lists the encoding methods together with a definition of 1600 each of their parameters. 1602 o ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn): 1604 is_innermost: This Boolean flag is set to true when processing 1605 the innermost IP header; otherwise, it is set to false. 1607 ttl_irregular_chain_flag: This parameter must be set to the 1608 value that was used for the corresponding 1609 "ttl_irregular_chain_flag" parameter of the "co_baseheader" 1610 encoding method (as defined below) when extracting the 1611 irregular chain for a compressed header; otherwise, it is set 1612 to zero and ignored for other types of chains. 1614 ip_inner_ecn: This parameter is bound by the encoding method, 1615 and therefore it should be undefined when calling this encoding 1616 method. This value is then used to bind the corresponding 1617 parameter in the "tcp" encoding method, as its value is needed 1618 when processing the irregular chain for TCP. See the 1619 definition of the "ip_inner_ecn" parameter for the "tcp" 1620 encoding method below. 1622 o ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn, 1623 ip_id_behavior_value): 1625 See definition of arguments for "ipv6" above 1627 ip_id_behavior_value: Set to a 2-bit integer value, using one 1628 of the constants whose name begins with the prefix 1629 IP_ID_BEHAVIOR_ and as defined in Section 8.2. 1631 o tcp_opt_eol(nbits): 1633 nbits: This parameter is set to the length of the padding data 1634 located after the EOL option type octet to the end of the TCP 1635 options in the uncompressed header. 1637 o tcp_opt_sack(ack_value): 1639 ack_value: Set to the value of the Acknowledgment Number field 1640 of the TCP header. 1642 o tcp(payload_size, ack_stride_value, ip_inner_ecn): 1644 payload_size: Set to the length (in octets) of the payload 1645 following the TCP header. 1647 ack_stride_value: This parameter is the scaling factor used 1648 when scaling the TCP Acknowledgment Number. Its value is set 1649 by the compressor implementation. See Section 6.4.8.2 for 1650 recommendations on how to set this value. 1652 ip_inner_ecn: This parameter binds with the value given to the 1653 corresponding "ip_inner_ecn" parameter by the "ipv4" or the 1654 "ipv6" encoding method when processing the innermost IP header 1655 of this packet. See also the definition of the "ip_inner_ecn" 1656 parameter to the "ipv6" and "ipv4" encoding method above. 1658 o co_baseheader(payload_size, ack_stride_value, 1659 ttl_irregular_chain_flag, ip_id_behavior_value): 1661 payload_size: Set to the length (in octets) of the payload 1662 following the TCP header. 1664 ack_stride_value: This parameter is the scaling factor used 1665 when scaling the TCP Acknowledgment Number. Its value is set 1666 by the compressor implementation. See Section 6.4.8.2 for 1667 recommendations on how to set this value. 1669 ttl_irregular_chain_flag: This parameter is set to one if the 1670 TTL/Hop Limit of an outer header has changed compared to its 1671 reference in the context; otherwise, it is set to zero. The 1672 value used for this parameter is also used for the 1673 "ttl_irregular_chain_flag" argument for the "ipv4" and "ipv6" 1674 encoding methods when processing the irregular chain, as 1675 defined above for the "ipv6" and "ipv4" encoding methods. 1677 ip_id_behavior_value: Set to a 2-bit integer value, using one 1678 of the constants whose name begins with the prefix 1679 IP_ID_BEHAVIOR_ and as defined in Section 8.2. 1681 7. Packet Types (Normative) 1683 ROHC-TCP uses three different packet types: the Initialization and 1684 Refresh (IR) packet type, the Context Replication (IR-CR) packet 1685 type, and the Compressed (CO) packet type. 1687 Each packet type defines a number of packet formats: two packet 1688 formats are defined for the IR type, one packet format is defined for 1689 the IR-CR type, and two sets of eight base header formats are defined 1690 for the CO type with one additional format that is common to both 1691 sets. 1693 The profile identifier for ROHC-TCP is 0x0006. 1695 7.1. Initialization and Refresh (IR) Packets 1697 ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets 1698 as defined in [RFC5795] (Sections 5.2.2.1 and 5.2.2.2, respectively). 1700 Packet type: IR 1702 This packet type communicates the static part and the dynamic part 1703 of the context. 1705 For the ROHC-TCP IR packet, the value of the x bit MUST be set to 1706 one. It has the following format, which corresponds to the 1707 "Header" and "Payload" fields described in Section 5.2.1 of 1708 [RFC5795]: 1710 0 1 2 3 4 5 6 7 1711 --- --- --- --- --- --- --- --- 1712 : Add-CID octet : if for small CIDs and (CID != 0) 1713 +---+---+---+---+---+---+---+---+ 1714 | 1 1 1 1 1 1 0 1 | IR type octet 1715 +---+---+---+---+---+---+---+---+ 1716 : : 1717 / 0-2 octets of CID / 1-2 octets if for large CIDs 1718 : : 1719 +---+---+---+---+---+---+---+---+ 1720 | Profile = 0x06 | 1 octet 1721 +---+---+---+---+---+---+---+---+ 1722 | CRC | 1 octet 1723 +---+---+---+---+---+---+---+---+ 1724 | | 1725 / Static chain / variable length 1726 | | 1727 - - - - - - - - - - - - - - - - 1728 | | 1729 / Dynamic chain / variable length 1730 | | 1731 - - - - - - - - - - - - - - - - 1732 | | 1733 / Payload / variable length 1734 | | 1735 - - - - - - - - - - - - - - - - 1737 CRC: 8-bit CRC, computed according to Section 5.3.1.1. of 1738 [RFC5795]. The CRC covers the entire IR header, thus excluding 1739 payload, padding, and feedback, if any. 1741 Static chain: See Section 6.2. 1743 Dynamic chain: See Section 6.2. 1745 Payload: The payload of the corresponding original packet, if any. 1746 The payload consists of all data after the last octet of the TCP 1747 header to the end of the uncompressed packet. The presence of a 1748 payload is inferred from the packet length. 1750 Packet type: IR-DYN 1752 This packet type communicates the dynamic part of the context. 1754 The ROHC-TCP IR-DYN packet has the following format, which 1755 corresponds to the "Header" and "Payload" fields described in 1756 Section 5.2.1 of [RFC5795]: 1758 0 1 2 3 4 5 6 7 1759 --- --- --- --- --- --- --- --- 1760 : Add-CID octet : if for small CIDs and (CID != 0) 1761 +---+---+---+---+---+---+---+---+ 1762 | 1 1 1 1 1 0 0 0 | IR-DYN type octet 1763 +---+---+---+---+---+---+---+---+ 1764 : : 1765 / 0-2 octets of CID / 1-2 octets if for large CIDs 1766 : : 1767 +---+---+---+---+---+---+---+---+ 1768 | Profile = 0x06 | 1 octet 1769 +---+---+---+---+---+---+---+---+ 1770 | CRC | 1 octet 1771 +---+---+---+---+---+---+---+---+ 1772 | | 1773 / Dynamic chain / variable length 1774 | | 1775 - - - - - - - - - - - - - - - - 1776 | | 1777 / Payload / variable length 1778 | | 1779 - - - - - - - - - - - - - - - - 1781 CRC: 8-bit CRC, computed according to Section 5.3.1.1 of 1782 [RFC5795]. The CRC covers the entire IR-DYN header, thus 1783 excluding payload, padding, and feedback, if any. 1785 Dynamic chain: See Section 6.2. 1787 Payload: The payload of the corresponding original packet, if any. 1788 The payload consists of all data after the last octet of the TCP 1789 header to end of the uncompressed packet. The presence of a 1790 payload is inferred from the packet length. 1792 7.2. Context Replication (IR-CR) Packets 1794 Context replication requires a dedicated IR packet format that 1795 uniquely identifies the IR-CR packet for the ROHC-TCP profile. This 1796 section defines the profile-specific part of the IR-CR packet 1797 [RFC4164]. 1799 Packet type: IR-CR 1801 This packet type communicates a reference to a base context along 1802 with the static and dynamic parts of the replicated context that 1803 differs from the base context. 1805 The ROHC-TCP IR-CR packet follows the general format of the ROHC 1806 IR-CR packet, as defined in [RFC4164], Section 3.5.2. With 1807 consideration to the extensibility of the IR packet type defined in 1808 [RFC5795], the ROHC-TCP profile supports context replication through 1809 the profile-specific part of the IR packet. This is achieved using 1810 the bit (x) left in the IR header for "Profile specific information". 1811 For ROHC-TCP, this bit is defined as a flag indicating whether this 1812 packet is an IR packet or an IR-CR packet. For the ROHC-TCP IR-CR 1813 packet, the value of the x bit MUST be set to zero. 1815 The ROHC-TCP IR-CR has the following format, which corresponds to the 1816 "Header" and "Payload" fields described in Section 5.2.1 of 1817 [RFC5795]: 1819 0 1 2 3 4 5 6 7 1820 --- --- --- --- --- --- --- --- 1821 : Add-CID octet : if for small CIDs and (CID != 0) 1822 +---+---+---+---+---+---+---+---+ 1823 | 1 1 1 1 1 1 0 0 | IR-CR type octet 1824 +---+---+---+---+---+---+---+---+ 1825 : : 1826 / 0-2 octets of CID / 1-2 octets if for large CIDs 1827 : : 1828 +---+---+---+---+---+---+---+---+ 1829 | Profile = 0x06 | 1 octet 1830 +---+---+---+---+---+---+---+---+ 1831 | CRC | 1 octet 1832 +---+---+---+---+---+---+---+---+ 1833 | B | CRC7 | 1 octet 1834 +---+---+---+---+---+---+---+---+ 1835 : Reserved | Base CID : 1 octet, for small CID, if B=1 1836 +---+---+---+---+---+---+---+---+ 1837 : : 1838 / Base CID / 1-2 octets, for large CIDs, 1839 : : if B=1 1840 +---+---+---+---+---+---+---+---+ 1841 | | 1842 / Replicate chain / variable length 1843 | | 1844 - - - - - - - - - - - - - - - - 1845 | | 1846 / Payload / variable length 1847 | | 1848 - - - - - - - - - - - - - - - - 1850 B: B = 1 indicates that the Base CID field is present. 1852 CRC: This CRC covers the entire IR-CR header, thus excluding 1853 payload, padding, and feedback, if any. This 8-bit CRC is 1854 calculated according to Section 5.3.1.1 of [RFC5795]. 1856 CRC7: The CRC over the original, uncompressed, header. Calculated 1857 according to Section 3.5.1.1 of [RFC4164]. 1859 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1860 discard the packet. 1862 Base CID: CID of base context. Encoded according to [RFC4164], 1863 Section 3.5.3. 1865 Replicate chain: See Section 6.2. 1867 Payload: The payload of the corresponding original packet, if any. 1868 The presence of a payload is inferred from the packet length. 1870 7.3. Compressed (CO) Packets 1872 The ROHC-TCP CO packets communicate irregularities in the packet 1873 header. All CO packets carry a CRC and can update the context. 1875 The general format for a compressed TCP header is as follows, which 1876 corresponds to the "Header" and "Payload" fields described in Section 1877 5.2.1 of [RFC5795]: 1879 0 1 2 3 4 5 6 7 1880 --- --- --- --- --- --- --- --- 1881 : Add-CID octet : if for small CIDs and CID 1-15 1882 +---+---+---+---+---+---+---+---+ 1883 | First octet of base header | (with type indication) 1884 +---+---+---+---+---+---+---+---+ 1885 : : 1886 / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 1887 : : 1888 +---+---+---+---+---+---+---+---+ 1889 / Remainder of base header / variable number of octets 1890 +---+---+---+---+---+---+---+---+ 1891 : Irregular chain : 1892 / (including irregular chain / variable 1893 : items for TCP options) : 1894 --- --- --- --- --- --- --- --- 1895 | | 1896 / Payload / variable length 1897 | | 1898 - - - - - - - - - - - - - - - - 1900 Base header: The complete set of base headers is defined in 1901 Section 8. 1903 Irregular chain: See Section 6.2 and Section 6.3.6. 1905 Payload: The payload of the corresponding original packet, if any. 1906 The presence of a payload is inferred from the packet length. 1908 8. Header Formats (Normative) 1910 This section describes the set of compressed TCP/IP packet formats. 1911 The normative description of the packet formats is given using the 1912 formal notation for ROHC profiles defined in [RFC4997]. The formal 1913 description of the packet formats specifies all of the information 1914 needed to compress and decompress a header relative to the context. 1916 In particular, the notation provides a list of all the fields present 1917 in the uncompressed and compressed TCP/IP headers, and defines how to 1918 map from each uncompressed packet to its compressed equivalent and 1919 vice versa. 1921 8.1. Design Rationale for Compressed Base Headers 1923 The compressed header formats are defined as two separate sets: one 1924 set for the packets where the innermost IP header contains a 1925 sequential IP-ID (either network byte order or byte swapped), and one 1926 set for the packets without sequential IP-ID (either random, zero, or 1927 no IP-ID). 1929 These two sets of header formats are referred to as the "sequential" 1930 and the "random" set of header formats, respectively. 1932 In addition, there is one compressed format that is common to both 1933 sets of header formats and that can thus be used regardless of the 1934 type of IP-ID behavior. This format can transmit rarely changing 1935 fields and also send the frequently changing fields coded in variable 1936 lengths. It can also change the value of control fields such as 1937 IP-ID behavior and ECN behavior. 1939 All compressed base headers contain a 3-bit CRC, unless they update 1940 control fields such as "ip_id_behavior" or "ecn_used" that affect the 1941 interpretation of subsequent headers. Headers that can modify these 1942 control fields carry a 7-bit CRC instead. 1944 When discussing LSB-encoded fields below, "p" equals the 1945 "offset_param" and "k" equals the "num_lsbs_param" in [RFC4997]. 1947 The encoding methods used in the compressed base headers are based on 1948 the following design criteria: 1950 o MSN 1952 Since the MSN is a number generated by the compressor, it only 1953 needs to be large enough to ensure robust operation and to 1954 accommodate a small amount of reordering [RFC4163]. Therefore, 1955 each compressed base header has an MSN field that is LSB- 1956 encoded with k=4 and p=4 to handle a reordering depth of up to 1957 4 packets. Additional guidance to improve robustness when 1958 reordering is possible can be found in [RFC4224]. 1960 o TCP Sequence Number 1962 ROHC-TCP has the capability to handle bulk data transfers 1963 efficiently, for which the sequence number is expected to 1964 increase by about 1460 octets (which can be represented by 11 1965 bits). For the compressed base headers to handle 1966 retransmissions (i.e., negative delta to the sequence number), 1967 the LSB interpretation interval has to handle negative offsets 1968 about as large as positive offsets, which means that one more 1969 bit is needed. 1971 Also, for ROHC-TCP to be robust to losses, two additional bits 1972 are added to the LSB encoding of the sequence number. This 1973 means that the base headers should contain at least 14 bits of 1974 LSB-encoded sequence number when present. According to the 1975 logic above, the LSB offset value is set to be as large as the 1976 positive offset, i.e., p = 2^(k-1)-1. 1978 o TCP Acknowledgment Number 1980 The design criterion for the acknowledgment number is similar 1981 to that of the TCP Sequence Number. However, often only every 1982 other data packet is acknowledged, which means that the 1983 expected delta value is twice as large as for sequence numbers. 1985 Therefore, at least 15 bits of acknowledgment number should be 1986 used in compressed base headers. Since the acknowledgment 1987 number is expected to constantly increase, and the only 1988 exception to this is packet reordering (either on the ROHC 1989 channel [RFC3759] or prior to the compression point), the 1990 negative offset for LSB encoding is set to be 1/4 of the total 1991 interval, i.e., p = 2^(k-2)-1. 1993 o TCP Window 1995 The TCP Window field is expected to increase in increments of 1996 similar size as the TCP Sequence Number, and therefore the 1997 design criterion for the TCP window is to send at least 14 bits 1998 when used. 2000 o IP-ID 2001 For the "sequential" set of packet formats, all the compressed 2002 base headers contain LSB-encoded IP-ID offset bits, where the 2003 offset is the difference between the value of the MSN field and 2004 the value of the IP-ID field. The requirement is that at least 2005 3 bits of IP-ID should always be present, but it is preferable 2006 to use 4 to 7 bits. When k=3 then p=1, and if k>3 then p=3 2007 since the offset is expected to increase most of the time. 2009 Each set of header formats contains eight different compressed base 2010 headers. The reason for having this large number of header formats 2011 is that the TCP Sequence Number, TCP Acknowledgment Number, and TCP 2012 Window are frequently changing in a non-linear pattern. 2014 The design of the header formats is derived from the field behavior 2015 analysis found in [RFC4413]. 2017 All of the compressed base headers transmit LSB-encoded MSN bits, the 2018 TCP Push flag, and a CRC, and in addition to this, all the base 2019 headers in the sequential packet format set contain LSB-encoded IP-ID 2020 bits. 2022 The following header formats exist in both the sequential and random 2023 packet format sets: 2025 o Format 1: This header format carries changes to the TCP Sequence 2026 Number and is expected to be used on the downstream of a data 2027 transfer. 2029 o Format 2: This header format carries the TCP Sequence Number in 2030 scaled form and is expected to be useful for the downstream of a 2031 data transfer where the payload size is constant for multiple 2032 packets. 2034 o Format 3: This header format carries changes in the TCP 2035 Acknowledgment Number and is expected to be useful for the 2036 acknowledgment direction of a data transfer. 2038 o Format 4: This header format is similar to format 3, but carries a 2039 scaled TCP Acknowledgment Number. 2041 o Format 5: This header format carries both the TCP Sequence Number 2042 and the TCP Acknowledgment Number and is expected to be useful for 2043 flows that send data in both directions. 2045 o Format 6: This header format is similar to format 5, but carries 2046 the TCP Sequence Number in scaled form, when the payload size is 2047 static for certain intervals in a data flow. 2049 o Format 7: This header format carries changes to both the TCP 2050 Acknowledgment Number and the TCP Window and is expected to be 2051 useful for the acknowledgment flows of data connections. 2053 o Format 8: This header format is used to convey changes to some of 2054 the more seldom changing fields in the TCP flow, such as ECN 2055 behavior, RST/SYN/FIN flags, the TTL/Hop Limit, and the TCP 2056 options list. This format carries a 7-bit CRC, since it can 2057 change the structure of the contents of the irregular chain for 2058 subsequent packets. Note that this can be seen as a reduced form 2059 of the common packet format. 2061 o Common header format: The common header format can be used for all 2062 kinds of IP-ID behavior and should be useful when some of the more 2063 rarely changing fields in the IP or TCP header change. Since this 2064 header format can update control fields that decide how the 2065 decompressor interprets packets, it carries a 7-bit CRC to reduce 2066 the probability of context corruption. This header can basically 2067 convey changes to any of the dynamic fields in the IP and TCP 2068 headers, and it uses a large set of flags to provide information 2069 about which fields are present in the header format. 2071 8.2. Formal Definition of Header Formats 2073 // NOTE: The irregular, static, and dynamic chains (see Section 6.2) 2074 // are defined across multiple encoding methods and are embodied 2075 // in the correspondingly named formats within those encoding 2076 // methods. In particular, note that the static and dynamic 2077 // chains ordinarily go together. The uncompressed fields are 2078 // defined across these two formats combined, rather than in one 2079 // or the other of them. The irregular chain items are likewise 2080 // combined with a baseheader format. 2082 //////////////////////////////////////////// 2083 // Constants 2084 //////////////////////////////////////////// 2086 IP_ID_BEHAVIOR_SEQUENTIAL = 0; 2087 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; 2088 IP_ID_BEHAVIOR_RANDOM = 2; 2089 IP_ID_BEHAVIOR_ZERO = 3; 2091 //////////////////////////////////////////// 2092 // Global control fields 2093 //////////////////////////////////////////// 2095 CONTROL { 2096 ecn_used [ 1 ]; 2097 msn [ 16 ]; 2098 // ip_id fields are for innermost IP header only 2099 ip_id_offset [ 16 ]; 2100 ip_id_behavior_innermost [ 2 ]; 2101 // ACK-related 2102 ack_stride [ 32 ]; 2103 ack_number_scaled [ 32 ]; 2104 ack_number_residue [ 32 ]; 2105 seq_number_scaled [ 32 ]; 2106 seq_number_residue [ 32 ]; 2107 } 2109 /////////////////////////////////////////////// 2110 // Encoding methods not specified in FN syntax 2111 /////////////////////////////////////////////// 2113 list_tcp_options "defined in Section 6.3.3"; 2114 inferred_ip_v4_header_checksum "defined in Section 6.4.1"; 2115 inferred_mine_header_checksum "defined in Section 6.4.2"; 2116 inferred_ip_v4_length "defined in Section 6.4.3"; 2117 inferred_ip_v6_length "defined in Section 6.4.4"; 2118 inferred_offset "defined in Section 6.4.5"; 2119 baseheader_extension_headers "defined in Section 6.4.6"; 2120 baseheader_outer_headers "defined in Section 6.4.7"; 2122 //////////////////////////////////////////// 2123 // General encoding methods 2124 //////////////////////////////////////////// 2126 static_or_irreg(flag, width) 2127 { 2128 UNCOMPRESSED { 2129 field [ width ]; 2130 } 2132 COMPRESSED irreg_enc { 2133 field =:= irregular(width) [ width ]; 2134 ENFORCE(flag == 1); 2135 } 2137 COMPRESSED static_enc { 2138 field =:= static [ 0 ]; 2139 ENFORCE(flag == 0); 2140 } 2141 } 2143 zero_or_irreg(flag, width) 2144 { 2145 UNCOMPRESSED { 2146 field [ width ]; 2147 } 2149 COMPRESSED non_zero { 2150 field =:= irregular(width) [ width ]; 2151 ENFORCE(flag == 0); 2152 } 2154 COMPRESSED zero { 2155 field =:= uncompressed_value(width, 0) [ 0 ]; 2156 ENFORCE(flag == 1); 2157 } 2158 } 2160 variable_length_32_enc(flag) 2161 { 2162 UNCOMPRESSED { 2163 field [ 32 ]; 2164 } 2166 COMPRESSED not_present { 2167 field =:= static [ 0 ]; 2168 ENFORCE(flag == 0); 2169 } 2171 COMPRESSED lsb_8_bit { 2172 field =:= lsb(8, 63) [ 8 ]; 2173 ENFORCE(flag == 1); 2174 } 2176 COMPRESSED lsb_16_bit { 2177 field =:= lsb(16, 16383) [ 16 ]; 2178 ENFORCE(flag == 2); 2179 } 2181 COMPRESSED irreg_32_bit { 2182 field =:= irregular(32) [ 32 ]; 2183 ENFORCE(flag == 3); 2184 } 2185 } 2187 optional32(flag) 2188 { 2189 UNCOMPRESSED { 2190 item [ 0, 32 ]; 2191 } 2192 COMPRESSED present { 2193 item =:= irregular(32) [ 32 ]; 2194 ENFORCE(flag == 1); 2195 } 2197 COMPRESSED not_present { 2198 item =:= compressed_value(0, 0) [ 0 ]; 2199 ENFORCE(flag == 0); 2200 } 2201 } 2203 lsb_7_or_31 2204 { 2205 UNCOMPRESSED { 2206 item [ 32 ]; 2207 } 2209 COMPRESSED lsb_7 { 2210 discriminator =:= '0' [ 1 ]; 2211 item =:= lsb(7, 8) [ 7 ]; 2212 } 2214 COMPRESSED lsb_31 { 2215 discriminator =:= '1' [ 1 ]; 2216 item =:= lsb(31, 256) [ 31 ]; 2217 } 2218 } 2220 opt_lsb_7_or_31(flag) 2221 { 2222 UNCOMPRESSED { 2223 item [ 0, 32 ]; 2224 } 2226 COMPRESSED present { 2227 item =:= lsb_7_or_31 [ 8, 32 ]; 2228 ENFORCE(flag == 1); 2229 } 2231 COMPRESSED not_present { 2232 item =:= compressed_value(0, 0) [ 0 ]; 2233 ENFORCE(flag == 0); 2234 } 2235 } 2237 crc3(data_value, data_length) 2238 { 2239 UNCOMPRESSED { 2240 } 2242 COMPRESSED { 2243 crc_value =:= 2244 crc(3, 0x06, 0x07, data_value, data_length) [ 3 ]; 2245 } 2246 } 2248 crc7(data_value, data_length) 2249 { 2250 UNCOMPRESSED { 2251 } 2253 COMPRESSED { 2254 crc_value =:= 2255 crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ]; 2256 } 2257 } 2259 one_bit_choice 2260 { 2261 UNCOMPRESSED { 2262 field [ 1 ]; 2263 } 2265 COMPRESSED zero { 2266 field [ 1 ]; 2267 ENFORCE(field.UVALUE == 0); 2268 } 2270 COMPRESSED nonzero { 2271 field [ 1 ]; 2272 ENFORCE(field.UVALUE == 1); 2273 } 2274 } 2276 // Encoding method for updating a scaled field and its associated 2277 // control fields. Should be used both when the value is scaled 2278 // or unscaled in a compressed format. 2279 // Does not have an uncompressed side. 2280 field_scaling(stride_value, scaled_value, unscaled_value, residue_value) 2281 { 2282 UNCOMPRESSED { 2283 // Nothing 2284 } 2286 COMPRESSED no_scaling { 2287 ENFORCE(stride_value == 0); 2288 ENFORCE(residue_value == unscaled_value); 2289 ENFORCE(scaled_value == 0); 2290 } 2292 COMPRESSED scaling_used { 2293 ENFORCE(stride_value != 0); 2294 ENFORCE(residue_value == (unscaled_value % stride_value)); 2295 ENFORCE(unscaled_value == 2296 scaled_value * stride_value + residue_value); 2297 } 2298 } 2300 //////////////////////////////////////////// 2301 // IPv6 Destination options header 2302 //////////////////////////////////////////// 2304 ip_dest_opt 2305 { 2306 UNCOMPRESSED { 2307 next_header [ 8 ]; 2308 length [ 8 ]; 2309 value [ length.UVALUE * 64 + 48 ]; 2310 } 2312 DEFAULT { 2313 length =:= static; 2314 next_header =:= static; 2315 value =:= static; 2316 } 2318 COMPRESSED dest_opt_static { 2319 next_header =:= irregular(8) [ 8 ]; 2320 length =:= irregular(8) [ 8 ]; 2321 } 2323 COMPRESSED dest_opt_dynamic { 2324 value =:= 2325 irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; 2326 } 2328 COMPRESSED dest_opt_0_replicate { 2329 discriminator =:= '00000000' [ 8 ]; 2330 } 2332 COMPRESSED dest_opt_1_replicate { 2333 discriminator =:= '10000000' [ 8 ]; 2334 length =:= irregular(8) [ 8 ]; 2335 value =:= 2336 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2337 } 2339 COMPRESSED dest_opt_irregular { 2340 } 2341 } 2343 //////////////////////////////////////////// 2344 // IPv6 Hop-by-Hop options header 2345 //////////////////////////////////////////// 2347 ip_hop_opt 2348 { 2349 UNCOMPRESSED { 2350 next_header [ 8 ]; 2351 length [ 8 ]; 2352 value [ length.UVALUE * 64 + 48 ]; 2353 } 2355 DEFAULT { 2356 length =:= static; 2357 next_header =:= static; 2358 value =:= static; 2359 } 2361 COMPRESSED hop_opt_static { 2362 next_header =:= irregular(8) [ 8 ]; 2363 length =:= irregular(8) [ 8 ]; 2364 } 2366 COMPRESSED hop_opt_dynamic { 2367 value =:= 2368 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2369 } 2371 COMPRESSED hop_opt_0_replicate { 2372 discriminator =:= '00000000' [ 8 ]; 2373 } 2375 COMPRESSED hop_opt_1_replicate { 2376 discriminator =:= '10000000' [ 8 ]; 2377 length =:= irregular(8) [ 8 ]; 2378 value =:= 2379 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2380 } 2382 COMPRESSED hop_opt_irregular { 2383 } 2384 } 2386 //////////////////////////////////////////// 2387 // IPv6 Routing header 2388 //////////////////////////////////////////// 2390 ip_rout_opt 2391 { 2392 UNCOMPRESSED { 2393 next_header [ 8 ]; 2394 length [ 8 ]; 2395 value [ length.UVALUE * 64 + 48 ]; 2396 } 2398 DEFAULT { 2399 length =:= static; 2400 next_header =:= static; 2401 value =:= static; 2402 } 2404 COMPRESSED rout_opt_static { 2405 next_header =:= irregular(8) [ 8 ]; 2406 length =:= irregular(8) [ 8 ]; 2407 value =:= 2408 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2409 } 2411 COMPRESSED rout_opt_dynamic { 2412 } 2414 COMPRESSED rout_opt_0_replicate { 2415 discriminator =:= '00000000' [ 8 ]; 2416 } 2418 COMPRESSED rout_opt_0_replicate { 2419 discriminator =:= '10000000' [ 8 ]; 2420 length =:= irregular(8) [ 8 ]; 2421 value =:= 2422 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2423 } 2425 COMPRESSED rout_opt_irregular { 2426 } 2427 } 2429 //////////////////////////////////////////// 2430 // GRE Header 2431 //////////////////////////////////////////// 2433 optional_checksum(flag_value) 2434 { 2435 UNCOMPRESSED { 2436 value [ 0, 16 ]; 2437 reserved1 [ 0, 16 ]; 2438 } 2440 COMPRESSED cs_present { 2441 value =:= irregular(16) [ 16 ]; 2442 reserved1 =:= uncompressed_value(16, 0) [ 0 ]; 2443 ENFORCE(flag_value == 1); 2444 } 2446 COMPRESSED not_present { 2447 value =:= compressed_value(0, 0) [ 0 ]; 2448 reserved1 =:= compressed_value(0, 0) [ 0 ]; 2449 ENFORCE(flag_value == 0); 2450 } 2451 } 2453 gre_proto 2454 { 2455 UNCOMPRESSED { 2456 protocol [ 16 ]; 2457 } 2459 COMPRESSED ether_v4 { 2460 discriminator =:= compressed_value(1, 0) [ 1 ]; 2461 protocol =:= uncompressed_value(16, 0x0800) [ 0 ]; 2462 } 2464 COMPRESSED ether_v6 { 2465 discriminator =:= compressed_value(1, 1) [ 1 ]; 2466 protocol =:= uncompressed_value(16, 0x86DD) [ 0 ]; 2467 } 2468 } 2470 gre 2471 { 2472 UNCOMPRESSED { 2473 c_flag [ 1 ]; 2474 r_flag =:= uncompressed_value(1, 0) [ 1 ]; 2475 k_flag [ 1 ]; 2476 s_flag [ 1 ]; 2477 reserved0 =:= uncompressed_value(9, 0) [ 9 ]; 2478 version =:= uncompressed_value(3, 0) [ 3 ]; 2479 protocol [ 16 ]; 2480 checksum_and_res [ 0, 32 ]; 2481 key [ 0, 32 ]; 2482 sequence_number [ 0, 32 ]; 2483 } 2485 DEFAULT { 2486 c_flag =:= static; 2487 k_flag =:= static; 2488 s_flag =:= static; 2489 protocol =:= static; 2490 key =:= static; 2491 sequence_number =:= static; 2492 } 2494 COMPRESSED gre_static { 2495 ENFORCE((c_flag.UVALUE == 1 && checksum_and_res.ULENGTH == 32) 2496 || checksum_and_res.ULENGTH == 0); 2497 ENFORCE((s_flag.UVALUE == 1 && sequence_number.ULENGTH == 32) 2498 || sequence_number.ULENGTH == 0); 2499 protocol =:= gre_proto [ 1 ]; 2500 c_flag =:= irregular(1) [ 1 ]; 2501 k_flag =:= irregular(1) [ 1 ]; 2502 s_flag =:= irregular(1) [ 1 ]; 2503 padding =:= compressed_value(4, 0) [ 4 ]; 2504 key =:= optional32(k_flag.UVALUE) [ 0, 32 ]; 2505 } 2507 COMPRESSED gre_dynamic { 2508 checksum_and_res =:= 2509 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2510 sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ]; 2511 } 2513 COMPRESSED gre_0_replicate { 2514 discriminator =:= '00000000' [ 8 ]; 2515 checksum_and_res =:= 2516 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2517 sequence_number =:= 2518 optional32(s_flag.UVALUE) [ 0, 8, 32 ]; 2519 } 2521 COMPRESSED gre_1_replicate { 2522 discriminator =:= '10000' [ 5 ]; 2523 c_flag =:= irregular(1) [ 1 ]; 2524 k_flag =:= irregular(1) [ 1 ]; 2525 s_flag =:= irregular(1) [ 1 ]; 2526 checksum_and_res =:= 2527 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2528 key =:= optional32(k_flag.UVALUE) [ 0, 32 ]; 2529 sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ]; 2530 } 2532 COMPRESSED gre_irregular { 2533 checksum_and_res =:= 2534 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2535 sequence_number =:= 2536 opt_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ]; 2537 } 2538 } 2540 ///////////////////////////////////////////// 2541 // MINE header 2542 ///////////////////////////////////////////// 2544 mine 2545 { 2546 UNCOMPRESSED { 2547 next_header [ 8 ]; 2548 s_bit [ 1 ]; 2549 res_bits [ 7 ]; 2550 checksum [ 16 ]; 2551 orig_dest [ 32 ]; 2552 orig_src [ 0, 32 ]; 2553 } 2555 DEFAULT { 2556 next_header =:= static; 2557 s_bit =:= static; 2558 res_bits =:= static; 2559 checksum =:= inferred_mine_header_checksum; 2560 orig_dest =:= static; 2561 orig_src =:= static; 2562 } 2564 COMPRESSED mine_static { 2565 next_header =:= irregular(8) [ 8 ]; 2566 s_bit =:= irregular(1) [ 1 ]; 2567 // Reserved bits are included to achieve byte-alignment 2568 res_bits =:= irregular(7) [ 7 ]; 2569 orig_dest =:= irregular(32) [ 32 ]; 2570 orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ]; 2571 } 2573 COMPRESSED mine_dynamic { 2574 } 2575 COMPRESSED mine_0_replicate { 2576 discriminator =:= '00000000' [ 8 ]; 2577 } 2579 COMPRESSED mine_1_replicate { 2580 discriminator =:= '10000000' [ 8 ]; 2581 s_bit =:= irregular(1) [ 1 ]; 2582 res_bits =:= irregular(7) [ 7 ]; 2583 orig_dest =:= irregular(32) [ 32 ]; 2584 orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ]; 2585 } 2587 COMPRESSED mine_irregular { 2588 } 2589 } 2591 ///////////////////////////////////////////// 2592 // Authentication Header (AH) 2593 ///////////////////////////////////////////// 2595 ah 2596 { 2597 UNCOMPRESSED { 2598 next_header [ 8 ]; 2599 length [ 8 ]; 2600 res_bits [ 16 ]; 2601 spi [ 32 ]; 2602 sequence_number [ 32 ]; 2603 icv [ length.UVALUE*32-32 ]; 2604 } 2606 DEFAULT { 2607 next_header =:= static; 2608 length =:= static; 2609 res_bits =:= static; 2610 spi =:= static; 2611 sequence_number =:= static; 2612 } 2614 COMPRESSED ah_static { 2615 next_header =:= irregular(8) [ 8 ]; 2616 length =:= irregular(8) [ 8 ]; 2617 spi =:= irregular(32) [ 32 ]; 2618 } 2620 COMPRESSED ah_dynamic { 2621 res_bits =:= irregular(16) [ 16 ]; 2622 sequence_number =:= irregular(32) [ 32 ]; 2623 icv =:= 2624 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2625 } 2627 COMPRESSED ah_0_replicate { 2628 discriminator =:= '00000000' [ 8 ]; 2629 sequence_number =:= irregular(32) [ 32 ]; 2630 icv =:= 2631 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2632 } 2634 COMPRESSED ah_1_replicate { 2635 discriminator =:= '10000000' [ 8 ]; 2636 length =:= irregular(8) [ 8 ]; 2637 res_bits =:= irregular(16) [ 16 ]; 2638 spi =:= irregular(32) [ 32 ]; 2639 sequence_number =:= irregular(32) [ 32 ]; 2640 icv =:= 2641 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2642 } 2644 COMPRESSED ah_irregular { 2645 sequence_number =:= lsb_7_or_31 [ 8, 32 ]; 2646 icv =:= 2647 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2648 } 2649 } 2651 ///////////////////////////////////////////// 2652 // IPv6 Header 2653 ///////////////////////////////////////////// 2655 fl_enc 2656 { 2657 UNCOMPRESSED { 2658 flow_label [ 20 ]; 2659 } 2661 COMPRESSED fl_zero { 2662 discriminator =:= '0' [ 1 ]; 2663 flow_label =:= uncompressed_value(20, 0) [ 0 ]; 2664 reserved =:= '0000' [ 4 ]; 2665 } 2667 COMPRESSED fl_non_zero { 2668 discriminator =:= '1' [ 1 ]; 2669 flow_label =:= irregular(20) [ 20 ]; 2670 } 2672 } 2674 // The is_innermost flag is true if this is the innermost IP header 2675 // If extracting the irregular chain for a compressed packet: 2676 // - ttl_irregular_chain_flag must have the same value as it had when 2677 // processing co_baseheader. 2678 // - ip_inner_ecn is bound in this encoding method and the value that 2679 // it gets bound to should be passed to the tcp encoding method 2680 // For other formats than the irregular chain, these two are ignored 2681 ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn) 2682 { 2683 UNCOMPRESSED { 2684 version =:= uncompressed_value(4, 6) [ 4 ]; 2685 dscp [ 6 ]; 2686 ip_ecn_flags [ 2 ]; 2687 flow_label [ 20 ]; 2688 payload_length [ 16 ]; 2689 next_header [ 8 ]; 2690 ttl_hopl [ 8 ]; 2691 src_addr [ 128 ]; 2692 dst_addr [ 128 ]; 2693 } 2695 DEFAULT { 2696 dscp =:= static; 2697 ip_ecn_flags =:= static; 2698 flow_label =:= static; 2699 payload_length =:= inferred_ip_v6_length; 2700 next_header =:= static; 2701 ttl_hopl =:= static; 2702 src_addr =:= static; 2703 dst_addr =:= static; 2704 } 2706 COMPRESSED ipv6_static { 2707 version_flag =:= '1' [ 1 ]; 2708 reserved =:= '00' [ 2 ]; 2709 flow_label =:= fl_enc [ 5, 21 ]; 2710 next_header =:= irregular(8) [ 8 ]; 2711 src_addr =:= irregular(128) [ 128 ]; 2712 dst_addr =:= irregular(128) [ 128 ]; 2713 } 2715 COMPRESSED ipv6_dynamic { 2716 dscp =:= irregular(6) [ 6 ]; 2717 ip_ecn_flags =:= irregular(2) [ 2 ]; 2718 ttl_hopl =:= irregular(8) [ 8 ]; 2719 } 2720 COMPRESSED ipv6_replicate { 2721 dscp =:= irregular(6) [ 6 ]; 2722 ip_ecn_flags =:= irregular(2) [ 2 ]; 2723 reserved =:= '000' [ 3 ]; 2724 flow_label =:= fl_enc [ 5, 21 ]; 2725 } 2727 COMPRESSED ipv6_outer_without_ttl_irregular { 2728 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2729 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2730 ENFORCE(ttl_irregular_chain_flag == 0); 2731 ENFORCE(is_innermost == false); 2732 } 2734 COMPRESSED ipv6_outer_with_ttl_irregular { 2735 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2736 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2737 ttl_hopl =:= irregular(8) [ 8 ]; 2738 ENFORCE(ttl_irregular_chain_flag == 1); 2739 ENFORCE(is_innermost == false); 2740 } 2742 COMPRESSED ipv6_innermost_irregular { 2743 ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE); 2744 ENFORCE(is_innermost == true); 2745 } 2746 } 2748 ///////////////////////////////////////////// 2749 // IPv4 Header 2750 ///////////////////////////////////////////// 2752 ip_id_enc_dyn(behavior) 2753 { 2754 UNCOMPRESSED { 2755 ip_id [ 16 ]; 2756 } 2758 COMPRESSED ip_id_seq { 2759 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 2760 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 2761 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 2762 ip_id =:= irregular(16) [ 16 ]; 2763 } 2765 COMPRESSED ip_id_random { 2766 ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); 2767 ip_id =:= irregular(16) [ 16 ]; 2769 } 2771 COMPRESSED ip_id_zero { 2772 ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); 2773 ip_id =:= uncompressed_value(16, 0) [ 0 ]; 2774 } 2775 } 2777 ip_id_enc_irreg(behavior) 2778 { 2779 UNCOMPRESSED { 2780 ip_id [ 16 ]; 2781 } 2783 COMPRESSED ip_id_seq { 2784 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 2785 } 2787 COMPRESSED ip_id_seq_swapped { 2788 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 2789 } 2791 COMPRESSED ip_id_rand { 2792 ip_id =:= irregular(16) [ 16 ]; 2793 ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); 2794 } 2796 COMPRESSED ip_id_zero { 2797 ip_id =:= uncompressed_value(16, 0) [ 0 ]; 2798 ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); 2799 } 2800 } 2802 // The is_innermost flag is true if this is the innermost IP header 2803 // If extracting the irregular chain for a compressed packet: 2804 // - ttl_irregular_chain_flag must have the same value as it had when 2805 // processing co_baseheader. 2806 // - ip_inner_ecn is bound in this encoding method and the value that 2807 // it gets bound to should be passed to the tcp encoding method 2808 // For other formats than the irregular chain, these two are ignored 2809 ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn, 2810 ip_id_behavior_value) 2811 { 2812 UNCOMPRESSED { 2813 version =:= uncompressed_value(4, 4) [ 4 ]; 2814 hdr_length =:= uncompressed_value(4, 5) [ 4 ]; 2815 dscp [ 6 ]; 2816 ip_ecn_flags [ 2 ]; 2817 length =:= inferred_ip_v4_length [ 16 ]; 2818 ip_id [ 16 ]; 2819 rf =:= uncompressed_value(1, 0) [ 1 ]; 2820 df [ 1 ]; 2821 mf =:= uncompressed_value(1, 0) [ 1 ]; 2822 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 2823 ttl_hopl [ 8 ]; 2824 protocol [ 8 ]; 2825 checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 2826 src_addr [ 32 ]; 2827 dst_addr [ 32 ]; 2828 } 2830 CONTROL { 2831 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 2832 ENFORCE(innermost_ip.UVALUE == is_innermost); 2833 ip_id_behavior_outer [ 2 ]; 2834 innermost_ip [ 1 ]; 2835 } 2837 DEFAULT { 2838 dscp =:= static; 2839 ip_ecn_flags =:= static; 2840 df =:= static; 2841 ttl_hopl =:= static; 2842 protocol =:= static; 2843 src_addr =:= static; 2844 dst_addr =:= static; 2845 ip_id_behavior_outer =:= static; 2846 } 2848 COMPRESSED ipv4_static { 2849 version_flag =:= '0' [ 1 ]; 2850 reserved =:= '0000000' [ 7 ]; 2851 protocol =:= irregular(8) [ 8 ]; 2852 src_addr =:= irregular(32) [ 32 ]; 2853 dst_addr =:= irregular(32) [ 32 ]; 2854 } 2856 COMPRESSED ipv4_innermost_dynamic { 2857 ENFORCE(is_innermost == 1); 2858 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 2859 reserved =:= '00000' [ 5 ]; 2860 df =:= irregular(1) [ 1 ]; 2861 ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 2862 dscp =:= irregular(6) [ 6 ]; 2863 ip_ecn_flags =:= irregular(2) [ 2 ]; 2864 ttl_hopl =:= irregular(8) [ 8 ]; 2865 ip_id =:= 2866 ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2867 } 2869 COMPRESSED ipv4_outer_dynamic { 2870 ENFORCE(is_innermost == 0); 2871 ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value); 2872 reserved =:= '00000' [ 5 ]; 2873 df =:= irregular(1) [ 1 ]; 2874 ip_id_behavior_outer =:= irregular(2) [ 2 ]; 2875 dscp =:= irregular(6) [ 6 ]; 2876 ip_ecn_flags =:= irregular(2) [ 2 ]; 2877 ttl_hopl =:= irregular(8) [ 8 ]; 2878 ip_id =:= 2879 ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2880 } 2882 COMPRESSED ipv4_innermost_replicate { 2883 ENFORCE(is_innermost == 1); 2884 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 2885 reserved =:= '0000' [ 4 ]; 2886 ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 2887 ttl_flag =:= irregular(1) [ 1 ]; 2888 df =:= irregular(1) [ 1 ]; 2889 dscp =:= irregular(6) [ 6 ]; 2890 ip_ecn_flags =:= irregular(2) [ 2 ]; 2891 ip_id =:= 2892 ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2893 ttl_hopl =:= 2894 static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ]; 2895 } 2897 COMPRESSED ipv4_outer_replicate { 2898 ENFORCE(is_innermost == 0); 2899 ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value); 2900 reserved =:= '0000' [ 4 ]; 2901 ip_id_behavior_outer =:= irregular(2) [ 2 ] 2902 ttl_flag =:= irregular(1) [ 1 ]; 2903 df =:= irregular(1) [ 1 ]; 2904 dscp =:= irregular(6) [ 6 ]; 2905 ip_ecn_flags =:= irregular(2) [ 2 ]; 2906 ip_id =:= 2907 ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2908 ttl_hopl =:= 2909 static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ]; 2910 } 2912 COMPRESSED ipv4_outer_without_ttl_irregular { 2913 ENFORCE(is_innermost == 0); 2914 ip_id =:= 2915 ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2916 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2917 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2918 ENFORCE(ttl_irregular_chain_flag == 0); 2919 } 2921 COMPRESSED ipv4_outer_with_ttl_irregular { 2922 ENFORCE(is_innermost == 0); 2923 ip_id =:= 2924 ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2925 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2926 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2927 ttl_hopl =:= irregular(8) [ 8 ]; 2928 ENFORCE(ttl_irregular_chain_flag == 1); 2929 } 2931 COMPRESSED ipv4_innermost_irregular { 2932 ENFORCE(is_innermost == 1); 2933 ip_id =:= 2934 ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2935 ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE); 2936 } 2937 } 2939 ///////////////////////////////////////////// 2940 // TCP Options 2941 ///////////////////////////////////////////// 2943 // nbits is bound to the remaining length (in bits) of TCP 2944 // options, including the EOL type byte. 2945 tcp_opt_eol(nbits) 2946 { 2947 UNCOMPRESSED { 2948 type =:= uncompressed_value(8, 0) [ 8 ]; 2949 padding =:= 2950 uncompressed_value(nbits-8, 0) [ nbits-8 ]; 2951 } 2953 CONTROL { 2954 pad_len [ 8 ]; 2955 } 2957 COMPRESSED eol_list_item { 2958 pad_len =:= compressed_value(8, nbits-8) [ 8 ]; 2959 } 2960 COMPRESSED eol_irregular { 2961 pad_len =:= static; 2962 ENFORCE(nbits-8 == pad_len.UVALUE); 2963 } 2964 } 2966 tcp_opt_nop 2967 { 2968 UNCOMPRESSED { 2969 type =:= uncompressed_value(8, 1) [ 8 ]; 2970 } 2972 COMPRESSED nop_list_item { 2973 } 2975 COMPRESSED nop_irregular { 2976 } 2977 } 2979 tcp_opt_mss 2980 { 2981 UNCOMPRESSED { 2982 type =:= uncompressed_value(8, 2) [ 8 ]; 2983 length =:= uncompressed_value(8, 4) [ 8 ]; 2984 mss [ 16 ]; 2985 } 2987 COMPRESSED mss_list_item { 2988 mss =:= irregular(16) [ 16 ]; 2989 } 2991 COMPRESSED mss_irregular { 2992 mss =:= static; 2993 } 2994 } 2996 tcp_opt_wscale 2997 { 2998 UNCOMPRESSED { 2999 type =:= uncompressed_value(8, 3) [ 8 ]; 3000 length =:= uncompressed_value(8, 3) [ 8 ]; 3001 wscale [ 8 ]; 3002 } 3004 COMPRESSED wscale_list_item { 3005 wscale =:= irregular(8) [ 8 ]; 3006 } 3007 COMPRESSED wscale_irregular { 3008 wscale =:= static; 3009 } 3010 } 3012 ts_lsb 3013 { 3014 UNCOMPRESSED { 3015 tsval [ 32 ]; 3016 } 3018 COMPRESSED tsval_7 { 3019 discriminator =:= '0' [ 1 ]; 3020 tsval =:= lsb(7, -1) [ 7 ]; 3021 } 3023 COMPRESSED tsval_14 { 3024 discriminator =:= '10' [ 2 ]; 3025 tsval =:= lsb(14, -1) [ 14 ]; 3026 } 3028 COMPRESSED tsval_21 { 3029 discriminator =:= '110' [ 3 ]; 3030 tsval =:= lsb(21, 0x00040000) [ 21 ]; 3031 } 3033 COMPRESSED tsval_29 { 3034 discriminator =:= '111' [ 3 ]; 3035 tsval =:= lsb(29, 0x04000000) [ 29 ]; 3036 } 3037 } 3039 tcp_opt_ts 3040 { 3041 UNCOMPRESSED { 3042 type =:= uncompressed_value(8, 8) [ 8 ]; 3043 length =:= uncompressed_value(8, 10) [ 8 ]; 3044 tsval [ 32 ]; 3045 tsecho [ 32 ]; 3046 } 3048 COMPRESSED tsopt_list_item { 3049 tsval =:= irregular(32) [ 32 ]; 3050 tsecho =:= irregular(32) [ 32 ]; 3051 } 3053 COMPRESSED tsopt_irregular { 3054 tsval =:= ts_lsb [ 8, 16, 24, 32 ]; 3055 tsecho =:= ts_lsb [ 8, 16, 24, 32 ]; 3056 } 3057 } 3058 sack_pure_lsb(base) 3059 { 3060 UNCOMPRESSED { 3061 sack_field [ 32 ]; 3062 } 3064 CONTROL { 3065 ENFORCE(sack_field.CVALUE == (sack_field.UVALUE - base)); 3066 } 3068 COMPRESSED lsb_15 { 3069 ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x7fff); 3070 discriminator =:= '0' [ 1 ]; 3071 sack_field [ 15 ]; 3072 } 3074 COMPRESSED lsb_22 { 3075 ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x3fffff); 3076 discriminator =:= '10' [ 2 ]; 3077 sack_field [ 22 ]; 3078 } 3080 COMPRESSED lsb_29 { 3081 ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x1fffffff); 3082 discriminator =:= '110' [ 3 ]; 3083 sack_field [ 29 ]; 3084 } 3086 COMPRESSED full_offset { 3087 discriminator =:= '11111111' [ 8 ]; 3088 sack_field [ 32 ]; 3089 } 3090 } 3092 sack_block(reference) 3093 { 3094 UNCOMPRESSED { 3095 block_start [ 32 ]; 3096 block_end [ 32 ]; 3097 } 3099 COMPRESSED { 3100 block_start =:= 3101 sack_pure_lsb(reference) [ 16, 24, 32, 40 ]; 3102 block_end =:= 3103 sack_pure_lsb(block_start.UVALUE) [ 16, 24, 32, 40 ]; 3104 } 3105 } 3107 // The value of the parameter is set to the ack_number value 3108 // of the TCP header 3109 tcp_opt_sack(ack_value) 3110 { 3112 UNCOMPRESSED { 3113 type =:= uncompressed_value(8, 5) [ 8 ]; 3114 length [ 8 ]; 3115 block_1 [ 64 ]; 3116 block_2 [ 0, 64 ]; 3117 block_3 [ 0, 64 ]; 3118 block_4 [ 0, 64 ]; 3119 } 3121 DEFAULT { 3122 length =:= static; 3123 block_2 =:= uncompressed_value(0, 0); 3124 block_3 =:= uncompressed_value(0, 0); 3125 block_4 =:= uncompressed_value(0, 0); 3126 } 3128 COMPRESSED sack1_list_item { 3129 discriminator =:= '00000001'; 3130 block_1 =:= sack_block(ack_value); 3131 ENFORCE(length.UVALUE == 10); 3132 } 3134 COMPRESSED sack2_list_item { 3135 discriminator =:= '00000010'; 3136 block_1 =:= sack_block(ack_value); 3137 block_2 =:= sack_block(ack_value); 3138 ENFORCE(length.UVALUE == 18); 3139 } 3141 COMPRESSED sack3_list_item { 3142 discriminator =:= '00000011'; 3143 block_1 =:= sack_block(ack_value); 3144 block_2 =:= sack_block(ack_value); 3145 block_3 =:= sack_block(ack_value); 3146 ENFORCE(length.UVALUE == 26); 3147 } 3149 COMPRESSED sack4_list_item { 3150 discriminator =:= '00000100'; 3151 block_1 =:= sack_block(ack_value); 3152 block_2 =:= sack_block(ack_value); 3153 block_3 =:= sack_block(ack_value); 3154 block_4 =:= sack_block(ack_value); 3155 ENFORCE(length.UVALUE == 34); 3156 } 3158 COMPRESSED sack_unchanged_irregular { 3159 discriminator =:= '00000000'; 3160 block_1 =:= static; 3161 block_2 =:= static; 3162 block_3 =:= static; 3163 block_4 =:= static; 3164 } 3166 COMPRESSED sack1_irregular { 3167 discriminator =:= '00000001'; 3168 block_1 =:= sack_block(ack_value); 3169 ENFORCE(length.UVALUE == 10); 3170 } 3172 COMPRESSED sack2_irregular { 3173 discriminator =:= '00000010'; 3174 block_1 =:= sack_block(ack_value); 3175 block_2 =:= sack_block(ack_value); 3176 ENFORCE(length.UVALUE == 18); 3177 } 3179 COMPRESSED sack3_irregular { 3180 discriminator =:= '00000011'; 3181 block_1 =:= sack_block(ack_value); 3182 block_2 =:= sack_block(ack_value); 3183 block_3 =:= sack_block(ack_value); 3184 ENFORCE(length.UVALUE == 26); 3185 } 3187 COMPRESSED sack4_irregular { 3188 discriminator =:= '00000100'; 3189 block_1 =:= sack_block(ack_value); 3190 block_2 =:= sack_block(ack_value); 3191 block_3 =:= sack_block(ack_value); 3192 block_4 =:= sack_block(ack_value); 3193 ENFORCE(length.UVALUE == 34); 3194 } 3195 } 3197 tcp_opt_sack_permitted 3198 { 3199 UNCOMPRESSED { 3200 type =:= uncompressed_value(8, 4) [ 8 ]; 3201 length =:= uncompressed_value(8, 2) [ 8 ]; 3202 } 3204 COMPRESSED sack_permitted_list_item { 3205 } 3207 COMPRESSED sack_permitted_irregular { 3208 } 3209 } 3211 tcp_opt_generic 3212 { 3213 UNCOMPRESSED { 3214 type [ 8 ]; 3215 length_msb =:= uncompressed_value(1, 0) [ 1 ]; 3216 length_lsb [ 7 ]; 3217 contents [ length_lsb.UVALUE*8-16 ]; 3218 } 3220 CONTROL { 3221 option_static [ 1 ]; 3222 } 3224 DEFAULT { 3225 type =:= static; 3226 length_lsb =:= static; 3227 contents =:= static; 3228 } 3230 COMPRESSED generic_list_item { 3231 type =:= irregular(8) [ 8 ]; 3232 option_static =:= one_bit_choice [ 1 ]; 3233 length_lsb =:= irregular(7) [ 7 ]; 3234 contents =:= 3235 irregular(length_lsb.UVALUE*8-16) [ length_lsb.UVALUE*8-16 ]; 3236 } 3238 // Used when context of option has option_static set to one 3239 COMPRESSED generic_static_irregular { 3240 ENFORCE(option_static.UVALUE == 1); 3241 } 3243 // An item that can change, but currently is unchanged 3244 COMPRESSED generic_stable_irregular { 3245 discriminator =:= '11111111' [ 8 ]; 3246 ENFORCE(option_static.UVALUE == 0); 3248 } 3250 // An item that is assumed to change constantly. 3251 // Length is not allowed to change here, since a length change is 3252 // most likely to cause new NOPs or an EOL length change. 3253 COMPRESSED generic_full_irregular { 3254 discriminator =:= '00000000' [ 8 ]; 3255 contents =:= 3256 irregular(length_lsb.UVALUE*8-16) [ length_lsb.UVALUE*8-16 ]; 3257 ENFORCE(option_static.UVALUE == 0); 3258 } 3259 } 3261 tcp_list_presence_enc(presence) 3262 { 3263 UNCOMPRESSED { 3264 tcp_options; 3265 } 3267 COMPRESSED list_not_present { 3268 tcp_options =:= static [ 0 ]; 3269 ENFORCE(presence == 0); 3270 } 3272 COMPRESSED list_present { 3273 tcp_options =:= list_tcp_options [ VARIABLE ]; 3274 ENFORCE(presence == 1); 3275 } 3276 } 3278 ///////////////////////////////////////////// 3279 // TCP Header 3280 ///////////////////////////////////////////// 3282 port_replicate(flags) 3283 { 3284 UNCOMPRESSED { 3285 port [ 16 ]; 3286 } 3288 COMPRESSED port_static_enc { 3289 port =:= static [ 0 ]; 3290 ENFORCE(flags == 0b00); 3291 } 3293 COMPRESSED port_lsb8 { 3294 port =:= lsb(8, 64) [ 8 ]; 3295 ENFORCE(flags == 0b01); 3297 } 3299 COMPRESSED port_irr_enc { 3300 port =:= irregular(16) [ 16 ]; 3301 ENFORCE(flags == 0b10); 3302 } 3303 } 3305 tcp_irreg_ip_ecn(ip_inner_ecn) 3306 { 3307 UNCOMPRESSED { 3308 ip_ecn_flags [ 2 ]; 3309 } 3311 COMPRESSED ecn_present { 3312 // This field does not exist in the uncompressed header 3313 // and therefore cannot use uncompressed_value. 3314 ip_ecn_flags =:= 3315 compressed_value(2, ip_inner_ecn) [ 2 ]; 3316 ENFORCE(ecn_used.UVALUE == 1); 3317 } 3319 COMPRESSED ecn_not_present { 3320 ip_ecn_flags =:= static [ 0 ]; 3321 ENFORCE(ecn_used.UVALUE == 0); 3322 } 3323 } 3325 rsf_index_enc 3326 { 3327 UNCOMPRESSED { 3328 rsf_flag [ 3 ]; 3329 } 3331 COMPRESSED none { 3332 rsf_idx =:= '00' [ 2 ]; 3333 rsf_flag =:= uncompressed_value(3, 0x00); 3334 } 3336 COMPRESSED rst_only { 3337 rsf_idx =:= '01' [ 2 ]; 3338 rsf_flag =:= uncompressed_value(3, 0x04); 3339 } 3341 COMPRESSED syn_only { 3342 rsf_idx =:= '10' [ 2 ]; 3343 rsf_flag =:= uncompressed_value(3, 0x02); 3344 } 3345 COMPRESSED fin_only { 3346 rsf_idx =:= '11' [ 2 ]; 3347 rsf_flag =:= uncompressed_value(3, 0x01); 3348 } 3349 } 3351 optional_2bit_padding(used_flag) 3352 { 3353 UNCOMPRESSED { 3354 } 3356 COMPRESSED used { 3357 padding =:= compressed_value(2, 0x0) [ 2 ]; 3358 ENFORCE(used_flag == 1); 3359 } 3361 COMPRESSED unused { 3362 padding =:= compressed_value(0, 0x0); 3363 ENFORCE(used_flag == 0); 3364 } 3365 } 3367 // ack_stride_value is the user-selected stride for scaling the 3368 // TCP ack_number 3369 // ip_inner_ecn is the value bound when processing the innermost 3370 // IP header (ipv4 or ipv6 encoding method) 3371 tcp(payload_size, ack_stride_value, ip_inner_ecn) 3372 { 3373 UNCOMPRESSED { 3374 src_port [ 16 ]; 3375 dst_port [ 16 ]; 3376 seq_number [ 32 ]; 3377 ack_number [ 32 ]; 3378 data_offset [ 4 ]; 3379 tcp_res_flags [ 4 ]; 3380 tcp_ecn_flags [ 2 ]; 3381 urg_flag [ 1 ]; 3382 ack_flag [ 1 ]; 3383 psh_flag [ 1 ]; 3384 rsf_flags [ 3 ]; 3385 window [ 16 ]; 3386 checksum [ 16 ]; 3387 urg_ptr [ 16 ]; 3388 options [ (data_offset.UVALUE-5)*32 ]; 3389 } 3391 CONTROL { 3392 dummy_field_s =:= field_scaling(payload_size, 3393 seq_number_scaled.UVALUE, seq_number.UVALUE, 3394 seq_number_residue.UVALUE) [ 0 ]; 3395 dummy_field_a =:= field_scaling(ack_stride.UVALUE, 3396 ack_number_scaled.UVALUE, ack_number.UVALUE, 3397 ack_number_residue.UVALUE) [ 0 ]; 3398 ENFORCE(ack_stride.UVALUE == ack_stride_value); 3399 } 3401 INITIAL { 3402 ack_stride =:= uncompressed_value(16, 0); 3403 } 3405 DEFAULT { 3406 src_port =:= static; 3407 dst_port =:= static; 3408 seq_number =:= static; 3409 ack_number =:= static; 3410 data_offset =:= inferred_offset; 3411 tcp_res_flags =:= static; 3412 tcp_ecn_flags =:= static; 3413 urg_flag =:= static; 3414 ack_flag =:= uncompressed_value(1, 1); 3415 rsf_flags =:= uncompressed_value(3, 0); 3416 window =:= static; 3417 urg_ptr =:= static; 3418 ack_stride =:= static; 3419 ack_number_scaled =:= static; 3420 seq_number_scaled =:= static; 3421 ack_number_residue =:= static; 3422 seq_number_residue =:= static; 3423 } 3425 COMPRESSED tcp_static { 3426 src_port =:= irregular(16) [ 16 ]; 3427 dst_port =:= irregular(16) [ 16 ]; 3428 } 3430 COMPRESSED tcp_dynamic { 3431 ecn_used =:= one_bit_choice [ 1 ]; 3432 ack_stride_flag =:= irregular(1) [ 1 ]; 3433 ack_zero =:= irregular(1) [ 1 ]; 3434 urp_zero =:= irregular(1) [ 1 ]; 3435 tcp_res_flags =:= irregular(4) [ 4 ]; 3436 tcp_ecn_flags =:= irregular(2) [ 2 ]; 3437 urg_flag =:= irregular(1) [ 1 ]; 3438 ack_flag =:= irregular(1) [ 1 ]; 3439 psh_flag =:= irregular(1) [ 1 ]; 3440 rsf_flags =:= irregular(3) [ 3 ]; 3441 msn =:= irregular(16) [ 16 ]; 3442 seq_number =:= irregular(32) [ 32 ]; 3443 ack_number =:= 3444 zero_or_irreg(ack_zero.CVALUE, 32) [ 0, 32 ]; 3445 window =:= irregular(16) [ 16 ]; 3446 checksum =:= irregular(16) [ 16 ]; 3447 urg_ptr =:= 3448 zero_or_irreg(urp_zero.CVALUE, 16) [ 0, 16 ]; 3449 ack_stride =:= 3450 static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; 3451 options =:= list_tcp_options [ VARIABLE ]; 3452 } 3454 COMPRESSED tcp_replicate { 3455 reserved =:= '0' [ 1 ]; 3456 window_presence =:= irregular(1) [ 1 ]; 3457 list_present =:= irregular(1) [ 1 ]; 3458 src_port_presence =:= irregular(2) [ 2 ]; 3459 dst_port_presence =:= irregular(2) [ 2 ]; 3460 ack_stride_flag =:= irregular(1) [ 1 ]; 3461 ack_presence =:= irregular(1) [ 1 ]; 3462 urp_presence =:= irregular(1) [ 1 ]; 3463 urg_flag =:= irregular(1) [ 1 ]; 3464 ack_flag =:= irregular(1) [ 1 ]; 3465 psh_flag =:= irregular(1) [ 1 ]; 3466 rsf_flags =:= rsf_index_enc [ 2 ]; 3467 ecn_used =:= one_bit_choice [ 1 ]; 3468 msn =:= irregular(16) [ 16 ]; 3469 seq_number =:= irregular(32) [ 32 ]; 3470 src_port =:= 3471 port_replicate(src_port_presence) [ 0, 8, 16 ]; 3472 dst_port =:= 3473 port_replicate(dst_port_presence) [ 0, 8, 16 ]; 3474 window =:= 3475 static_or_irreg(window_presence, 16) [ 0, 16 ]; 3476 urg_point =:= 3477 static_or_irreg(urp_presence, 16) [ 0, 16 ]; 3478 ack_number =:= 3479 static_or_irreg(ack_presence, 32) [ 0, 32 ]; 3480 ecn_padding =:= 3481 optional_2bit_padding(ecn_used.CVALUE) [ 0, 2 ]; 3482 tcp_res_flags =:= 3483 static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; 3484 tcp_ecn_flags =:= 3485 static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ]; 3486 checksum =:= irregular(16) [ 16 ]; 3487 ack_stride =:= 3488 static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; 3490 options =:= 3491 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3492 } 3494 COMPRESSED tcp_irregular { 3495 ip_ecn_flags =:= tcp_irreg_ip_ecn(ip_inner_ecn) [ 0, 2 ]; 3496 tcp_res_flags =:= 3497 static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; 3498 tcp_ecn_flags =:= 3499 static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ]; 3500 checksum =:= irregular(16) [ 16 ]; 3501 } 3502 } 3504 /////////////////////////////////////////////////// 3505 // Encoding methods used in compressed base headers 3506 /////////////////////////////////////////////////// 3508 dscp_enc(flag) 3509 { 3510 UNCOMPRESSED { 3511 dscp [ 6 ]; 3512 } 3514 COMPRESSED static_enc { 3515 dscp =:= static [ 0 ]; 3516 ENFORCE(flag == 0); 3517 } 3519 COMPRESSED irreg { 3520 dscp =:= irregular(6) [ 6 ]; 3521 padding =:= compressed_value(2, 0) [ 2 ]; 3522 ENFORCE(flag == 1); 3523 } 3524 } 3526 ip_id_lsb(behavior, k, p) 3527 { 3528 UNCOMPRESSED { 3529 ip_id [ 16 ]; 3530 } 3532 CONTROL { 3533 ip_id_nbo [ 16 ]; 3534 } 3536 COMPRESSED nbo { 3537 ip_id_offset =:= lsb(k, p) [ k ]; 3538 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 3539 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 3540 } 3542 COMPRESSED non_nbo { 3543 ip_id_offset =:= lsb(k, p) [ k ]; 3544 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 3545 ENFORCE(ip_id_nbo.UVALUE == 3546 (ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256); 3547 ENFORCE(ip_id_nbo.ULENGTH == 16); 3548 ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE); 3549 } 3550 } 3552 optional_ip_id_lsb(behavior, indicator) 3553 { 3554 UNCOMPRESSED { 3555 ip_id [ 16 ]; 3556 } 3558 COMPRESSED short { 3559 ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ]; 3560 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 3561 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3562 ENFORCE(indicator == 0); 3563 } 3565 COMPRESSED long { 3566 ip_id =:= irregular(16) [ 16 ]; 3567 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 3568 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3569 ENFORCE(indicator == 1); 3570 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 3571 } 3573 COMPRESSED not_present { 3574 ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || 3575 (behavior == IP_ID_BEHAVIOR_ZERO)); 3576 } 3577 } 3579 dont_fragment(version) 3580 { 3581 UNCOMPRESSED { 3582 df [ 1 ]; 3583 } 3585 COMPRESSED v4 { 3586 df =:= irregular(1) [ 1 ]; 3587 ENFORCE(version == 4); 3588 } 3590 COMPRESSED v6 { 3591 df =:= compressed_value(1, 0) [ 1 ]; 3592 ENFORCE(version == 6); 3593 } 3594 } 3596 ////////////////////////////////// 3597 // Actual start of compressed packet formats 3598 // Important note: 3599 // The base header is the compressed representation 3600 // of the innermost IP header AND the TCP header. 3601 ////////////////////////////////// 3603 // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit 3604 // of an outer header has changed. The same value must be passed as 3605 // an argument to the ipv4/ipv6 encoding methods when extracting 3606 // the irregular chain items. 3607 co_baseheader(payload_size, ack_stride_value, 3608 ttl_irregular_chain_flag, ip_id_behavior_value) 3609 { 3610 UNCOMPRESSED v4 { 3611 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3612 version =:= uncompressed_value(4, 4) [ 4 ]; 3613 header_length =:= uncompressed_value(4, 5) [ 4 ]; 3614 dscp [ 6 ]; 3615 ip_ecn_flags [ 2 ]; 3616 length [ 16 ]; 3617 ip_id [ 16 ]; 3618 rf =:= uncompressed_value(1, 0) [ 1 ]; 3619 df [ 1 ]; 3620 mf =:= uncompressed_value(1, 0) [ 1 ]; 3621 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 3622 ttl_hopl [ 8 ]; 3623 next_header [ 8 ]; 3624 checksum [ 16 ]; 3625 src_addr [ 32 ]; 3626 dest_addr [ 32 ]; 3627 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3628 src_port [ 16 ]; 3629 dest_port [ 16 ]; 3630 seq_number [ 32 ]; 3631 ack_number [ 32 ]; 3632 data_offset [ 4 ]; 3633 tcp_res_flags [ 4 ]; 3634 tcp_ecn_flags [ 2 ]; 3635 urg_flag [ 1 ]; 3636 ack_flag [ 1 ]; 3637 psh_flag [ 1 ]; 3638 rsf_flags [ 3 ]; 3639 window [ 16 ]; 3640 tcp_checksum [ 16 ]; 3641 urg_ptr [ 16 ]; 3642 options [ (data_offset.UVALUE-5)*32 ]; 3643 } 3645 UNCOMPRESSED v6 { 3646 ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM); 3647 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3648 version =:= uncompressed_value(4, 6) [ 4 ]; 3649 dscp [ 6 ]; 3650 ip_ecn_flags [ 2 ]; 3651 flow_label [ 20 ]; 3652 payload_length [ 16 ]; 3653 next_header [ 8 ]; 3654 ttl_hopl [ 8 ]; 3655 src_addr [ 128 ]; 3656 dest_addr [ 128 ]; 3657 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3658 src_port [ 16 ]; 3659 dest_port [ 16 ]; 3660 seq_number [ 32 ]; 3661 ack_number [ 32 ]; 3662 data_offset [ 4 ]; 3663 tcp_res_flags [ 4 ]; 3664 tcp_ecn_flags [ 2 ]; 3665 urg_flag [ 1 ]; 3666 ack_flag [ 1 ]; 3667 psh_flag [ 1 ]; 3668 rsf_flags [ 3 ]; 3669 window [ 16 ]; 3670 tcp_checksum [ 16 ]; 3671 urg_ptr [ 16 ]; 3672 options [ (data_offset.UVALUE-5)*32 ]; 3673 df =:= uncompressed_value(0,0) [ 0 ]; 3674 ip_id =:= uncompressed_value(0,0) [ 0 ]; 3675 } 3677 CONTROL { 3678 dummy_field_s =:= field_scaling(payload_size, 3679 seq_number_scaled.UVALUE, seq_number.UVALUE, 3680 seq_number_residue.UVALUE) [ 0 ]; 3681 dummy_field_a =:= field_scaling(ack_stride.UVALUE, 3682 ack_number_scaled.UVALUE, ack_number.UVALUE, 3683 ack_number_residue.UVALUE) [ 0 ]; 3684 ENFORCE(ack_stride.UVALUE == ack_stride_value); 3685 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 3686 } 3688 INITIAL { 3689 ack_stride =:= uncompressed_value(16, 0); 3690 } 3692 DEFAULT { 3693 tcp_ecn_flags =:= static; 3694 data_offset =:= inferred_offset; 3695 tcp_res_flags =:= static; 3696 rsf_flags =:= uncompressed_value(3, 0); 3697 dest_port =:= static; 3698 dscp =:= static; 3699 src_port =:= static; 3700 urg_flag =:= uncompressed_value(1, 0); 3701 window =:= static; 3702 dest_addr =:= static; 3703 version =:= static; 3704 ttl_hopl =:= static; 3705 src_addr =:= static; 3706 df =:= static; 3707 ack_number =:= static; 3708 urg_ptr =:= static; 3709 seq_number =:= static; 3710 ack_flag =:= uncompressed_value(1, 1); 3711 // The default for "options" is case 2) and 3) from 3712 // the list in section 6.3.1 (i.e. nothing present in the 3713 // baseheader itself). 3714 payload_length =:= inferred_ip_v6_length; 3715 checksum =:= inferred_ip_v4_header_checksum; 3716 length =:= inferred_ip_v4_length; 3717 flow_label =:= static; 3718 next_header =:= static; 3719 ip_ecn_flags =:= static; 3720 // The tcp_checksum has no default, 3721 // it is considered a part of tcp_irregular 3722 ip_id_behavior_innermost =:= static; 3723 ecn_used =:= static; 3724 ack_stride =:= static; 3725 ack_number_scaled =:= static; 3726 seq_number_scaled =:= static; 3727 ack_number_residue =:= static; 3728 seq_number_residue =:= static; 3729 // Default is to have no TTL in irregular chain 3730 // Can only be nonzero if co_common is used 3731 ENFORCE(ttl_irregular_chain_flag == 0); 3732 } 3734 //////////////////////////////////////////// 3735 // Common compressed packet format 3736 //////////////////////////////////////////// 3738 COMPRESSED co_common { 3739 discriminator =:= '1111101' [ 7 ]; 3740 ttl_hopl_outer_flag =:= 3741 compressed_value(1, ttl_irregular_chain_flag) [ 1 ]; 3742 ack_flag =:= irregular(1) [ 1 ]; 3743 psh_flag =:= irregular(1) [ 1 ]; 3744 rsf_flags =:= rsf_index_enc [ 2 ]; 3745 msn =:= lsb(4, 4) [ 4 ]; 3746 seq_indicator =:= irregular(2) [ 2 ]; 3747 ack_indicator =:= irregular(2) [ 2 ]; 3748 ack_stride_indicator =:= irregular(1) [ 1 ]; 3749 window_indicator =:= irregular(1) [ 1 ]; 3750 ip_id_indicator =:= irregular(1) [ 1 ]; 3751 urg_ptr_present =:= irregular(1) [ 1 ]; 3752 reserved =:= compressed_value(1, 0) [ 1 ]; 3753 ecn_used =:= one_bit_choice [ 1 ]; 3754 dscp_present =:= irregular(1) [ 1 ]; 3755 ttl_hopl_present =:= irregular(1) [ 1 ]; 3756 list_present =:= irregular(1) [ 1 ]; 3757 ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 3758 urg_flag =:= irregular(1) [ 1 ]; 3759 df =:= dont_fragment(version.UVALUE) [ 1 ]; 3760 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3761 seq_number =:= 3762 variable_length_32_enc(seq_indicator.CVALUE) [ 0, 8, 16, 32 ]; 3763 ack_number =:= 3764 variable_length_32_enc(ack_indicator.CVALUE) [ 0, 8, 16, 32 ]; 3765 ack_stride =:= 3766 static_or_irreg(ack_stride_indicator.CVALUE, 16) [ 0, 16 ]; 3767 window =:= 3768 static_or_irreg(window_indicator.CVALUE, 16) [ 0, 16 ]; 3769 ip_id =:= 3770 optional_ip_id_lsb(ip_id_behavior_innermost.UVALUE, 3771 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 3772 urg_ptr =:= 3773 static_or_irreg(urg_ptr_present.CVALUE, 16) [ 0, 16 ]; 3774 dscp =:= 3775 dscp_enc(dscp_present.CVALUE) [ 0, 8 ]; 3776 ttl_hopl =:= 3777 static_or_irreg(ttl_hopl_present.CVALUE, 8) [ 0, 8 ]; 3778 options =:= 3779 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3780 } 3782 // Send LSBs of sequence number 3783 COMPRESSED rnd_1 { 3784 discriminator =:= '101110' [ 6 ]; 3785 seq_number =:= lsb(18, 65535) [ 18 ]; 3786 msn =:= lsb(4, 4) [ 4 ]; 3787 psh_flag =:= irregular(1) [ 1 ]; 3788 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3789 ENFORCE((ip_id_behavior_innermost.UVALUE == 3790 IP_ID_BEHAVIOR_RANDOM) || 3791 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3792 } 3794 // Send scaled sequence number LSBs 3795 COMPRESSED rnd_2 { 3796 discriminator =:= '1100' [ 4 ]; 3797 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3798 msn =:= lsb(4, 4) [ 4 ]; 3799 psh_flag =:= irregular(1) [ 1 ]; 3800 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3801 ENFORCE(payload_size != 0); 3802 ENFORCE((ip_id_behavior_innermost.UVALUE == 3803 IP_ID_BEHAVIOR_RANDOM) || 3804 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3805 } 3807 // Send acknowledgment number LSBs 3808 COMPRESSED rnd_3 { 3809 discriminator =:= '0' [ 1 ]; 3810 ack_number =:= lsb(15, 8191) [ 15 ]; 3811 msn =:= lsb(4, 4) [ 4 ]; 3812 psh_flag =:= irregular(1) [ 1 ]; 3813 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3814 ENFORCE((ip_id_behavior_innermost.UVALUE == 3815 IP_ID_BEHAVIOR_RANDOM) || 3816 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3817 } 3819 // Send acknowledgment number scaled 3820 COMPRESSED rnd_4 { 3821 discriminator =:= '1101' [ 4 ]; 3822 ack_number_scaled =:= lsb(4, 3) [ 4 ]; 3823 msn =:= lsb(4, 4) [ 4 ]; 3824 psh_flag =:= irregular(1) [ 1 ]; 3825 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3826 ENFORCE(ack_stride.UVALUE != 0); 3827 ENFORCE((ip_id_behavior_innermost.UVALUE == 3828 IP_ID_BEHAVIOR_RANDOM) || 3829 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3830 } 3832 // Send ACK and sequence number 3833 COMPRESSED rnd_5 { 3834 discriminator =:= '100' [ 3 ]; 3835 psh_flag =:= irregular(1) [ 1 ]; 3836 msn =:= lsb(4, 4) [ 4 ]; 3837 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3838 seq_number =:= lsb(14, 8191) [ 14 ]; 3839 ack_number =:= lsb(15, 8191) [ 15 ]; 3840 ENFORCE((ip_id_behavior_innermost.UVALUE == 3841 IP_ID_BEHAVIOR_RANDOM) || 3842 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3843 } 3845 // Send both ACK and scaled sequence number LSBs 3846 COMPRESSED rnd_6 { 3847 discriminator =:= '1010' [ 4 ]; 3848 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3849 psh_flag =:= irregular(1) [ 1 ]; 3850 ack_number =:= lsb(16, 16383) [ 16 ]; 3851 msn =:= lsb(4, 4) [ 4 ]; 3852 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3853 ENFORCE(payload_size != 0); 3854 ENFORCE((ip_id_behavior_innermost.UVALUE == 3855 IP_ID_BEHAVIOR_RANDOM) || 3856 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3857 } 3859 // Send ACK and window 3860 COMPRESSED rnd_7 { 3861 discriminator =:= '101111' [ 6 ]; 3862 ack_number =:= lsb(18, 65535) [ 18 ]; 3863 window =:= irregular(16) [ 16 ]; 3864 msn =:= lsb(4, 4) [ 4 ]; 3865 psh_flag =:= irregular(1) [ 1 ]; 3866 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3867 ENFORCE((ip_id_behavior_innermost.UVALUE == 3868 IP_ID_BEHAVIOR_RANDOM) || 3869 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3870 } 3872 // An extended packet type for seldom-changing fields 3873 // Can send LSBs of TTL, RSF flags, change ECN behavior, and 3874 // options list 3875 COMPRESSED rnd_8 { 3876 discriminator =:= '10110' [ 5 ]; 3877 rsf_flags =:= rsf_index_enc [ 2 ]; 3878 list_present =:= irregular(1) [ 1 ]; 3879 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3880 msn =:= lsb(4, 4) [ 4 ]; 3881 psh_flag =:= irregular(1) [ 1 ]; 3882 ttl_hopl =:= lsb(3, 3) [ 3 ]; 3883 ecn_used =:= one_bit_choice [ 1 ]; 3884 seq_number =:= lsb(16, 65535) [ 16 ]; 3885 ack_number =:= lsb(16, 16383) [ 16 ]; 3886 options =:= 3887 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3888 ENFORCE((ip_id_behavior_innermost.UVALUE == 3889 IP_ID_BEHAVIOR_RANDOM) || 3890 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3891 } 3893 // Send LSBs of sequence number 3894 COMPRESSED seq_1 { 3895 discriminator =:= '1010' [ 4 ]; 3896 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 3897 seq_number =:= lsb(16, 32767) [ 16 ]; 3898 msn =:= lsb(4, 4) [ 4 ]; 3899 psh_flag =:= irregular(1) [ 1 ]; 3900 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3901 ENFORCE((ip_id_behavior_innermost.UVALUE == 3902 IP_ID_BEHAVIOR_SEQUENTIAL) || 3903 (ip_id_behavior_innermost.UVALUE == 3904 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3905 } 3907 // Send scaled sequence number LSBs 3908 COMPRESSED seq_2 { 3909 discriminator =:= '11010' [ 5 ]; 3910 ip_id =:= 3911 ip_id_lsb(ip_id_behavior_innermost.UVALUE, 7, 3) [ 7 ]; 3912 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3913 msn =:= lsb(4, 4) [ 4 ]; 3914 psh_flag =:= irregular(1) [ 1 ]; 3915 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3916 ENFORCE(payload_size != 0); 3917 ENFORCE((ip_id_behavior_innermost.UVALUE == 3918 IP_ID_BEHAVIOR_SEQUENTIAL) || 3919 (ip_id_behavior_innermost.UVALUE == 3920 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3922 } 3924 // Send acknowledgment number LSBs 3925 COMPRESSED seq_3 { 3926 discriminator =:= '1001' [ 4 ]; 3927 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 3928 ack_number =:= lsb(16, 16383) [ 16 ]; 3929 msn =:= lsb(4, 4) [ 4 ]; 3930 psh_flag =:= irregular(1) [ 1 ]; 3931 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3932 ENFORCE((ip_id_behavior_innermost.UVALUE == 3933 IP_ID_BEHAVIOR_SEQUENTIAL) || 3934 (ip_id_behavior_innermost.UVALUE == 3935 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3936 } 3938 // Send scaled acknowledgment number scaled 3939 COMPRESSED seq_4 { 3940 discriminator =:= '0' [ 1 ]; 3941 ack_number_scaled =:= lsb(4, 3) [ 4 ]; 3942 // Due to having very few ip_id bits, no negative offset 3943 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 3, 1) [ 3 ]; 3944 msn =:= lsb(4, 4) [ 4 ]; 3945 psh_flag =:= irregular(1) [ 1 ]; 3946 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3947 ENFORCE(ack_stride.UVALUE != 0); 3948 ENFORCE((ip_id_behavior_innermost.UVALUE == 3949 IP_ID_BEHAVIOR_SEQUENTIAL) || 3950 (ip_id_behavior_innermost.UVALUE == 3951 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3952 } 3954 // Send ACK and sequence number 3955 COMPRESSED seq_5 { 3956 discriminator =:= '1000' [ 4 ]; 3957 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 3958 ack_number =:= lsb(16, 16383) [ 16 ]; 3959 seq_number =:= lsb(16, 32767) [ 16 ]; 3960 msn =:= lsb(4, 4) [ 4 ]; 3961 psh_flag =:= irregular(1) [ 1 ]; 3962 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3963 ENFORCE((ip_id_behavior_innermost.UVALUE == 3964 IP_ID_BEHAVIOR_SEQUENTIAL) || 3965 (ip_id_behavior_innermost.UVALUE == 3966 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3967 } 3969 // Send both ACK and scaled sequence number LSBs 3970 COMPRESSED seq_6 { 3971 discriminator =:= '11011' [ 5 ]; 3972 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3973 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 7, 3) [ 7 ]; 3974 ack_number =:= lsb(16, 16383) [ 16 ]; 3975 msn =:= lsb(4, 4) [ 4 ]; 3976 psh_flag =:= irregular(1) [ 1 ]; 3977 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3978 ENFORCE(payload_size != 0); 3979 ENFORCE((ip_id_behavior_innermost.UVALUE == 3980 IP_ID_BEHAVIOR_SEQUENTIAL) || 3981 (ip_id_behavior_innermost.UVALUE == 3982 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3983 } 3985 // Send ACK and window 3986 COMPRESSED seq_7 { 3987 discriminator =:= '1100' [ 4 ]; 3988 window =:= lsb(15, 16383) [ 15 ]; 3989 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5, 3) [ 5 ]; 3990 ack_number =:= lsb(16, 32767) [ 16 ]; 3991 msn =:= lsb(4, 4) [ 4 ]; 3992 psh_flag =:= irregular(1) [ 1 ]; 3993 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3994 ENFORCE((ip_id_behavior_innermost.UVALUE == 3995 IP_ID_BEHAVIOR_SEQUENTIAL) || 3996 (ip_id_behavior_innermost.UVALUE == 3997 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3998 } 4000 // An extended packet type for seldom-changing fields 4001 // Can send LSBs of TTL, RSF flags, change ECN behavior, and 4002 // options list 4003 COMPRESSED seq_8 { 4004 discriminator =:= '1011' [ 4 ]; 4005 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ]; 4006 list_present =:= irregular(1) [ 1 ]; 4007 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4008 msn =:= lsb(4, 4) [ 4 ]; 4009 psh_flag =:= irregular(1) [ 1 ]; 4010 ttl_hopl =:= lsb(3, 3) [ 3 ]; 4011 ecn_used =:= one_bit_choice [ 1 ]; 4012 ack_number =:= lsb(15, 8191) [ 15 ]; 4013 rsf_flags =:= rsf_index_enc [ 2 ]; 4014 seq_number =:= lsb(14, 8191) [ 14 ]; 4015 options =:= 4016 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 4017 ENFORCE((ip_id_behavior_innermost.UVALUE == 4018 IP_ID_BEHAVIOR_SEQUENTIAL) || 4019 (ip_id_behavior_innermost.UVALUE == 4020 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4021 } 4022 } 4024 8.3. Feedback Formats and Options 4026 8.3.1. Feedback Formats 4028 This section describes the feedback formats for the ROHC-TCP profile, 4029 following the general ROHC feedback format described in Section 5.2.3 4030 of [RFC5795]. 4032 All feedback formats carry a field labeled MSN. The MSN field 4033 contains LSBs of the MSN control field described in Section 6.1.1. 4034 The sequence number to use is the MSN corresponding to the last 4035 header that was successfully CRC-8 validated or CRC verified. 4037 FEEDBACK-1 4039 0 1 2 3 4 5 6 7 4040 +---+---+---+---+---+---+---+---+ 4041 | MSN | 4042 +---+---+---+---+---+---+---+---+ 4044 MSN: The LSB-encoded master sequence number. 4046 A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, 4047 FEEDBACK-2 must be used. 4049 FEEDBACK-2 4051 0 1 2 3 4 5 6 7 4052 +---+---+---+---+---+---+---+---+ 4053 |Acktype| MSN | 4054 +---+---+---+---+---+---+---+---+ 4055 | MSN | 4056 +---+---+---+---+---+---+---+---+ 4057 | CRC | 4058 +---+---+---+---+---+---+---+---+ 4059 / Feedback options / 4060 +---+---+---+---+---+---+---+---+ 4061 Acktype: 4063 0 = ACK 4065 1 = NACK 4067 2 = STATIC-NACK 4069 3 is reserved (MUST NOT be used for parsability) 4071 MSN: The LSB-encoded master sequence number. 4073 CRC: 8-bit CRC computed over the entire feedback element (as 4074 defined in Section 5.3.1.1 of [RFC5795]). For the purpose of 4075 computing the CRC, the CRC field is zero. The CRC is calculated 4076 using the polynomial defined in [RFC5795]. 4078 Feedback options: A variable number of feedback options, see 4079 Section 8.3.2. Options may appear in any order. 4081 A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an 4082 acknowledgment for a successfully decompressed packet, which packet 4083 corresponds to the MSN of the feedback element, unless the MSN-NOT- 4084 VALID option (Section 8.3.2.2) appears in the feedback element. 4086 The FEEDBACK-2 format always carries a CRC and is thus more robust 4087 than the FEEDBACK-1 format. When receiving FEEDBACK-2, the 4088 compressor MUST verify the information by computing the CRC and by 4089 comparing the result with the CRC carried in the feedback format. If 4090 the two are not identical, the feedback element MUST be discarded. 4092 8.3.2. Feedback Options 4094 A ROHC-TCP feedback option has variable length and the following 4095 general format: 4097 0 1 2 3 4 5 6 7 4098 +---+---+---+---+---+---+---+---+ 4099 | Opt Type | Opt Len | 4100 +---+---+---+---+---+---+---+---+ 4101 / option data / Opt Length (octets) 4102 +---+---+---+---+---+---+---+---+ 4104 Each ROHC-TCP feedback option can appear at most once within a 4105 FEEDBACK-2. 4107 8.3.2.1. The REJECT Option 4109 The REJECT option informs the compressor that the decompressor does 4110 not have sufficient resources to handle the flow. 4112 +---+---+---+---+---+---+---+---+ 4113 | Opt Type = 2 | Opt Len = 0 | 4114 +---+---+---+---+---+---+---+---+ 4116 When receiving a REJECT option, the compressor MUST stop compressing 4117 the packet flow, and SHOULD refrain from attempting to increase the 4118 number of compressed packet flows for some time. The REJECT option 4119 MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, 4120 the compressor MUST discard the entire feedback element. 4122 8.3.2.2. The MSN-NOT-VALID Option 4124 The MSN-NOT-VALID option indicates that the MSN of the feedback is 4125 not valid. 4127 +---+---+---+---+---+---+---+---+ 4128 | Opt Type = 3 | Opt Len = 0 | 4129 +---+---+---+---+---+---+---+---+ 4131 A compressor MUST ignore the MSN of the feedback element when this 4132 option is present. Consequently, a NACK or a STATIC-NACK feedback 4133 type sent with the MSN-NOT-VALID option is equivalent to a STATIC- 4134 NACK with respect to the semantics of the feedback message. 4136 The MSN-NOT-VALID option MUST NOT appear more than once in the 4137 FEEDBACK-2 format and MUST NOT appear in the same feedback element as 4138 the MSN option; otherwise, the compressor MUST discard the entire 4139 feedback element. 4141 8.3.2.3. The MSN Option 4143 The MSN option provides 2 additional bits of MSN. 4145 +---+---+---+---+---+---+---+---+ 4146 | Opt Type = 4 | Opt Len = 1 | 4147 +---+---+---+---+---+---+---+---+ 4148 | MSN | Reserved | 4149 +---+---+---+---+---+---+---+---+ 4151 These 2 bits are the least significant bits of the MSN and are thus 4152 concatenated with the 14 bits already present in the FEEDBACK-2 4153 format. 4155 The MSN option MUST NOT appear more than once in the FEEDBACK-2 4156 format and MUST NOT appear in the same feedback element as the MSN- 4157 NOT-VALID option; otherwise, the compressor MUST discard the entire 4158 feedback element. 4160 8.3.2.4. The CONTEXT_MEMORY Feedback Option 4162 The CONTEXT_MEMORY option means that the decompressor does not have 4163 sufficient memory resources to handle the context of the packet flow, 4164 as the flow is currently compressed. 4166 0 1 2 3 4 5 6 7 4167 +---+---+---+---+---+---+---+---+ 4168 | Opt Type = 9 | Opt Len = 0 | 4169 +---+---+---+---+---+---+---+---+ 4171 When receiving a CONTEXT_MEMORY option, the compressor SHOULD take 4172 actions to compress the packet flow in a way that requires less 4173 decompressor memory resources, or stop compressing the packet flow. 4175 The CONTEXT_MEMORY option MUST NOT appear more than once in the 4176 FEEDBACK-2 format; otherwise, the compressor MUST discard the entire 4177 feedback element. 4179 8.3.2.5. Unknown Option Types 4181 If an option type unknown to the compressor is encountered, the 4182 compressor MUST continue parsing the rest of the FEEDBACK element, 4183 which is possible since the length of the option is explicit, but 4184 MUST otherwise ignore the unknown option. 4186 9. Changes from RFC 4996 4188 This RFC revises RFC 4996. It is mostly backwards-compatible with 4189 RFC 4996 except for two cases that did not interoperate as described 4190 below. 4192 9.1. Functional Changes 4194 o The SACK option compression in [RFC4996] assumed that multiple 4195 SACK blocks within the same option would be in sorted order so 4196 that the block starts were LSB-encoded from the end of the 4197 previous block. This meant that SACK blocks that are not in 4198 sorted order could be impossible to compress in some cases. 4199 Therefore, the SACK compression in the formal notation has changed 4200 and therefore also the bits-on-the-wire. 4202 o The ESP NULL header compression has been deprecated due to 4203 interoperability problems with needing to know information from 4204 the trailer. The ESP NULL compression was already removed from 4205 ROHCv2 [RFC5225] for the same reason and it was considered better 4206 to remove it from this profile rather than try to fix the 4207 interoperability issue. 4209 9.2. Non-functional Changes 4211 o The way sequential IP-ID compression was described in the FN code 4212 was incorrect and the code used for ROHCv2 [RFC5225] has been 4213 imported into this specification (e.g. offset is made into a 4214 global control field). This does not change the bits-on-the-wire. 4215 The only change is how this encoding is described in the formal 4216 notation, not how the compression occurs. 4218 o Default encoding for the 'df' and 'ip_id' fields have been added 4219 for IPv6 with 0-bit uncompressed format to clarify that these 4220 never appear in IPv6. 4222 o The scaled encoding of the Acknowledgment Number and Sequence 4223 Number were incorrectly described in the FN code in [RFC4996] and 4224 have been updated in the same style as in ROHCv2 [RFC5225]. This 4225 does not change the bits-on-the-wire, only the way the compression 4226 is described in the FN code. 4228 o The external arguments to ipv4 and co_baseheader have been 4229 updated. This is again only a change for FN correctness and does 4230 not affect interoperability. 4232 o Erratas for [RFC4996] related to minor errors in the FN and 4233 textual errors have also been corrected. 4235 10. Security Considerations 4237 A malfunctioning or malicious header compressor could cause the 4238 header decompressor to reconstitute packets that do not match the 4239 original packets but still have valid IP and TCP headers, and 4240 possibly also valid TCP checksums. Such corruption may be detected 4241 with end-to-end authentication and integrity mechanisms that will not 4242 be affected by the compression. Moreover, this header compression 4243 scheme uses an internal checksum for verification of reconstructed 4244 headers. This reduces the probability of producing decompressed 4245 headers not matching the original ones without this being noticed. 4247 Denial-of-service attacks are possible if an intruder can introduce 4248 (for example) bogus IR, CO, or FEEDBACK packets onto the link and 4249 thereby cause compression efficiency to be reduced. However, an 4250 intruder having the ability to inject arbitrary packets at the link 4251 layer in this manner raises additional security issues that dwarf 4252 those related to the use of header compression. 4254 11. IANA Considerations 4256 This document requests that the reference for ROHC profile identifier 4257 0x0006 is updated to point to this document instead of RFC4996. 4259 A ROHC profile identifier has been reserved by the IANA for the 4260 profile defined in this document. Profiles 0x0000-0x0005 have 4261 previously been reserved; this profile is 0x0006. As for previous 4262 ROHC profiles, profile numbers 0xnn06 have been reserved for future 4263 updates of this profile. 4265 Profile Usage Document 4266 identifier 4268 0x0006 ROHC TCP [RFCthis] 4269 0xnn06 Reserved 4271 12. Acknowledgments 4273 The authors would like to thank Qian Zhang, Hong Bin Liao, Richard 4274 Price, and Fredrik Lindstroem for their work with early versions of 4275 this specification. Thanks also to Robert Finking and Carsten 4276 Bormann for valuable input and to Carl Knutsson and Gilbert Strom for 4277 suggestions and review of the updates made in this document. 4279 Additional thanks: this document was reviewed during working group 4280 last-call by committed reviewers Joe Touch and Ted Faber, as well as 4281 by Sally Floyd, who provided a review at the request of the Transport 4282 Area Directors. 4284 13. References 4286 13.1. Normative References 4288 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4289 September 1981. 4291 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 4292 RFC 793, September 1981. 4294 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 4295 October 1996. 4297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4298 Requirement Levels", BCP 14, RFC 2119, March 1997. 4300 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4301 (IPv6) Specification", RFC 2460, December 1998. 4303 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 4304 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 4305 March 2000. 4307 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 4308 RFC 2890, September 2000. 4310 [RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context 4311 Replication for ROHC Profiles", RFC 4164, August 2005. 4313 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 4314 December 2005. 4316 [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust 4317 Header Compression (ROHC-FN)", RFC 4997, July 2007. 4319 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 4320 Header Compression (ROHC) Framework", RFC 5795, 4321 March 2010. 4323 13.2. Informative References 4325 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 4326 serial links", RFC 1144, February 1990. 4328 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 4329 for High Performance", RFC 1323, May 1992. 4331 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 4332 Selective Acknowledgment Options", RFC 2018, October 1996. 4334 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 4335 Compression", RFC 2507, February 1999. 4337 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 4338 Extension to the Selective Acknowledgement (SACK) Option 4339 for TCP", RFC 2883, July 2000. 4341 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 4342 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 4343 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 4344 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 4345 Compression (ROHC): Framework and four profiles: RTP, UDP, 4346 ESP, and uncompressed", RFC 3095, July 2001. 4348 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 4349 of Explicit Congestion Notification (ECN) to IP", 4350 RFC 3168, September 2001. 4352 [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): 4353 Terminology and Channel Mapping Examples", RFC 3759, 4354 April 2004. 4356 [RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC): 4357 Requirements on TCP/IP Header Compression", RFC 4163, 4358 August 2005. 4360 [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust 4361 Header Compression (ROHC): ROHC over Channels That Can 4362 Reorder Packets", RFC 4224, January 2006. 4364 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 4365 March 2006. 4367 [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 4368 "RObust Header Compression (ROHC): A Profile for TCP/IP 4369 (ROHC-TCP)", RFC 4996, July 2007. 4371 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 4372 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 4373 UDP-Lite", RFC 5225, April 2008. 4375 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 4376 Control", RFC 5681, September 2009. 4378 Authors' Addresses 4380 Ghyslain Pelletier 4381 InterDigital Communications 4382 1000, rue Sherbrooke ouest, 10th floor 4383 Montreal, Quebec H3A 3G4 4384 Canada 4386 Phone: +46 (0) 70 609 27 73 4387 Email: ghyslain.pelletier@interdigital.com 4388 Kristofer Sandlund 4389 Ericsson 4390 Box 920 4391 Lulea SE-971 28 4392 Sweden 4394 Phone: +46 (0) 8 404 41 58 4395 Email: kristofer.sandlund@ericsson.com 4397 Lars-Erik Jonsson 4398 Optand 737 4399 Ostersund SE-831 92 4400 Sweden 4402 Phone: +46 70 365 20 58 4403 Email: lars-erik@lejonsson.com 4405 Mark A West 4406 Siemens/Roke Manor 4407 Roke Manor Research Ltd. 4408 Romsey, Hampshire SO51 0ZN 4409 UK 4411 Phone: +44 1794 833311 4412 Email: mark.a.west@roke.co.uk 4413 URI: http://www.roke.co.uk