idnits 2.17.1 draft-ietf-rohc-tcp-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4338. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2, 2007) is 6287 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) == Outdated reference: A later version (-04) exists of draft-ietf-rohc-rfc3095bis-framework-02 ** 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 2001 (Obsoleted by RFC 2581) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Robust Header Compression G. Pelletier 3 Internet-Draft L. Jonsson 4 Intended status: Standards Track K. Sandlund 5 Expires: August 6, 2007 Ericsson 6 M. West 7 Siemens/Roke Manor 8 February 2, 2007 10 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) 11 draft-ietf-rohc-tcp-16 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 6, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies a ROHC (Robust Header Compression) profile 45 for compression of TCP/IP packets. The profile, called ROHC-TCP, 46 provides efficient and robust compression of TCP headers, including 47 frequently used TCP options such as SACK (Selective Acknowledgments) 48 and Timestamps. 50 ROHC-TCP works well when used over links with significant error rates 51 and long round-trip times. For many bandwidth-limited links where 52 header compression is essential, such characteristics are common. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Existing TCP/IP Header Compression Schemes . . . . . . . . 6 60 3.2. Classification of TCP/IP Header Fields . . . . . . . . . . 7 61 4. Overview of the TCP/IP Profile (Informative) . . . . . . . . . 9 62 4.1. General Concepts . . . . . . . . . . . . . . . . . . . . . 9 63 4.2. Compressor and Decompressor Interactions . . . . . . . . . 9 64 4.2.1. Compressor Operation . . . . . . . . . . . . . . . . . 9 65 4.2.2. Decompressor Feedback . . . . . . . . . . . . . . . . 9 66 4.3. Packet Formats and Encoding Methods . . . . . . . . . . . 10 67 4.3.1. Compressing TCP Options . . . . . . . . . . . . . . . 10 68 4.3.2. Compressing Extension Headers . . . . . . . . . . . . 10 69 4.4. Expected Compression Ratios with ROHC-TCP . . . . . . . . 10 70 5. Compressor and Decompressor Logic (Normative) . . . . . . . . 11 71 5.1. Context Initialization . . . . . . . . . . . . . . . . . . 12 72 5.2. Compressor Operation . . . . . . . . . . . . . . . . . . . 12 73 5.2.1. Compression Logic . . . . . . . . . . . . . . . . . . 12 74 5.2.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 13 75 5.2.3. Context Replication . . . . . . . . . . . . . . . . . 14 76 5.3. Decompressor Operation . . . . . . . . . . . . . . . . . . 14 77 5.3.1. Decompressor States and Logic . . . . . . . . . . . . 14 78 5.3.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 18 79 5.3.3. Context Replication . . . . . . . . . . . . . . . . . 19 80 6. Encodings in ROHC-TCP (Normative) . . . . . . . . . . . . . . 19 81 6.1. Control Fields in ROHC-TCP . . . . . . . . . . . . . . . . 19 82 6.1.1. Master Sequence Number (MSN) . . . . . . . . . . . . . 19 83 6.1.2. IP-ID Behavior . . . . . . . . . . . . . . . . . . . . 20 84 6.1.3. Explicit Congestion Notification (ECN) . . . . . . . . 20 85 6.2. Compressed Header Chains . . . . . . . . . . . . . . . . . 21 86 6.3. Compressing TCP Options with List Compression . . . . . . 22 87 6.3.1. List Compression . . . . . . . . . . . . . . . . . . . 23 88 6.3.2. Table-based Item Compression . . . . . . . . . . . . . 24 89 6.3.3. Encoding of Compressed Lists . . . . . . . . . . . . . 25 90 6.3.4. Item Table Mappings . . . . . . . . . . . . . . . . . 26 91 6.3.5. Compressed Lists in Dynamic Chain . . . . . . . . . . 28 92 6.3.6. Irregular Chain Items for TCP Options . . . . . . . . 28 93 6.3.7. Replication of TCP Options . . . . . . . . . . . . . . 28 94 6.4. Profile-specific Encoding Methods . . . . . . . . . . . . 29 95 6.4.1. inferred_ip_v4_header_checksum . . . . . . . . . . . . 29 96 6.4.2. inferred_mine_header_checksum . . . . . . . . . . . . 29 97 6.4.3. inferred_ip_v4_length . . . . . . . . . . . . . . . . 30 98 6.4.4. inferred_ip_v6_length . . . . . . . . . . . . . . . . 30 99 6.4.5. inferred_offset . . . . . . . . . . . . . . . . . . . 31 100 6.4.6. baseheader_extension_headers . . . . . . . . . . . . . 31 101 6.4.7. baseheader_outer_headers . . . . . . . . . . . . . . . 31 102 6.4.8. Scaled Encoding of Fields . . . . . . . . . . . . . . 32 103 6.5. Encoding Methods With External Parameters . . . . . . . . 34 104 7. Packet Types (Normative) . . . . . . . . . . . . . . . . . . . 36 105 7.1. Initialization and Refresh Packets (IR) . . . . . . . . . 36 106 7.2. Context Replication Packets (IR-CR) . . . . . . . . . . . 38 107 7.3. Compressed Packets (CO) . . . . . . . . . . . . . . . . . 40 108 8. Header Formats (Normative) . . . . . . . . . . . . . . . . . . 41 109 8.1. Design Rationale for Compressed Base Headers . . . . . . . 42 110 8.2. Formal Definition of Header Formats . . . . . . . . . . . 45 111 8.3. Feedback Formats and Options . . . . . . . . . . . . . . . 85 112 8.3.1. Feedback Formats . . . . . . . . . . . . . . . . . . . 85 113 8.3.2. Feedback Options . . . . . . . . . . . . . . . . . . . 87 114 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 89 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 89 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 90 118 12.1. Normative References . . . . . . . . . . . . . . . . . . . 90 119 12.2. Informative References . . . . . . . . . . . . . . . . . . 91 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 92 121 Intellectual Property and Copyright Statements . . . . . . . . . . 93 123 1. Introduction 125 There are several reasons to perform header compression on low- or 126 medium-speed links for TCP/IP traffic, and these have already been 127 discussed in [RFC2507]. Additional considerations that make 128 robustness an important objective for a TCP [RFC0793] compression 129 scheme are introduced in [RFC4163]. Finally, existing TCP/IP header 130 compression schemes ([RFC1144], [RFC2507]) are limited in their 131 handling of the TCP options field and cannot compress the headers of 132 handshaking packets (SYNs and FINs). 134 It is thus desirable for a header compression scheme to be able to 135 handle loss on the link between the compression and decompression 136 point as well as loss before the compression point. The header 137 compression scheme also needs to consider how to efficiently compress 138 short-lived TCP transfers and TCP options, such as SACK ([RFC2018], 139 [RFC2883]) and Timestamps ([RFC1323]). 141 The ROHC WG has developed a header compression framework on top of 142 which various profiles can be defined for different protocol sets, or 143 for different compression strategies. This document defines a TCP/IP 144 compression profile for the ROHC framework 145 [I-D.ietf-rohc-rfc3095bis-framework], compliant with the requirements 146 listed in [RFC4163]. 148 Specifically, it describes a header compression scheme for TCP/IP 149 header compression (ROHC-TCP) that is robust against packet loss and 150 that offers enhanced capabilities, in particular for the compression 151 of header fields including TCP options. The profile identifier for 152 TCP/IP compression is 0x0006. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 This document reuses some of the terminology found in 161 [I-D.ietf-rohc-rfc3095bis-framework]. In addition, this document 162 uses or defines the following terms: 164 Base context 165 The base context is a context that has been validated by both the 166 compressor and the decompressor. A base context can be used as 167 the reference when building a new context using replication. 169 Base Context Identifier, Base CID 171 The Base CID is the CID that identifies the Base Context, where 172 information needed for context replication can be extracted from. 174 Base header 176 A compressed representation of the innermost IP and TCP headers of 177 the uncompressed packet. 179 Chaining of Items 181 A chain groups fields based on similar characteristics. ROHC-TCP 182 defines chain items for static, dynamic, replicable or irregular 183 fields. Chaining is done by appending an item for e.g. each 184 header to the chain in their order of appearance in the 185 uncompressed packet. Chaining is useful to construct compressed 186 headers from an arbitrary number of any of the protocol headers 187 for which ROHC-TCP defines a compressed format. 189 Context Replication (CR) 191 Context replication is the mechanism that establishes and 192 initializes a new context based on another existing valid context 193 (a base context). This mechanism is introduced to reduce the 194 overhead of the context establishment procedure, and is especially 195 useful for compression of multiple short-lived TCP connections 196 that may be occurring simultaneously or near-simultaneously. 198 ROHC-TCP packet types 200 ROHC-TCP uses three different packet types: the Initialization and 201 Refresh (IR) packet type, the Context Replication (IR-CR) packet 202 type and the Compressed packet type (CO). 204 Short-lived TCP transfer 206 Short-lived TCP transfers refer to TCP connections transmitting 207 only small amounts of packets for each single connection. 209 3. Background 211 This section provides some background information on TCP/IP header 212 compression. The fundamentals of general header compression can be 213 found in [I-D.ietf-rohc-rfc3095bis-framework]. In the following sub- 214 sections, two existing TCP/IP header compression schemes are first 215 described along with a discussion of their limitations, followed by 216 the classification of TCP/IP header fields. Finally, some of the 217 characteristics of short-lived TCP transfers are summarized. 219 A behavior analysis of TCP/IP header fields is found in [RFC4413]. 221 3.1. Existing TCP/IP Header Compression Schemes 223 Compressed TCP (CTCP) and IP Header Compression (IPHC) are two 224 different schemes that may be used to compress TCP/IP headers. Both 225 schemes transmit only the differences from the previous header in 226 order to reduce the size of the TCP/IP header. 228 The CTCP [RFC1144] compressor detects transport-level retransmissions 229 and sends a header that updates the context completely when they 230 occur. While CTCP works well over reliable links, it is vulnerable 231 when used over less reliable links as even a single packet loss 232 results in loss of synchronization between the compressor and the 233 decompressor. This in turn leads to the TCP receiver discarding all 234 remaining packets in the current window because of a checksum error. 235 This effectively prevents the TCP Fast Retransmit algorithm [RFC2001] 236 from being triggered. In such case, the compressor must wait until 237 TCP times out and retransmits a packet to resynchronize. 239 To reduce the errors due to the inconsistent contexts between 240 compressor and decompressor when compressing TCP, IPHC [RFC2507] 241 improves somewhat on CTCP by augmenting the repair mechanism of CTCP 242 with a local repair mechanism called TWICE and with a link layer 243 mechanism based on negative acknowledgements to request a header that 244 updates the context. 246 The TWICE algorithm assumes that only the sequence number field of 247 TCP segments is changing with the deltas between consecutive packets 248 being constant in most cases. This assumption is however not always 249 true, especially when TCP Timestamps and SACK options are used. 251 The full header request mechanism requires a feedback channel that 252 may be unavailable in some circumstances. This channel is used to 253 explicitly request that the next packet be sent with an uncompressed 254 header to allow resynchronization without waiting for a TCP timeout. 255 In addition, this mechanism does not perform well on links with long 256 round-trip time. 258 Both CTCP and IPHC are also limited in their handling of the TCP 259 options field. For IPHC, any change in the options field (caused by 260 timestamps or SACK, for example) renders the entire field 261 uncompressible, while for CTCP such a change in the options field 262 effectively disables TCP/IP header compression altogether. 264 Finally, existing TCP/IP compression schemes do not compress the 265 headers of handshaking packets (SYNs and FINs). Compressing these 266 packets may greatly improve the overall header compression ratio for 267 the cases where many short-lived TCP connections share the same 268 channel. 270 3.2. Classification of TCP/IP Header Fields 272 Header compression is possible due to the fact that there is much 273 redundancy between header field values within packets, especially 274 between consecutive packets. To utilize these properties for TCP/IP 275 header compression, it is important to understand the change patterns 276 of the various header fields. 278 All fields of the TCP/IP packet header have been classified in detail 279 in [RFC4413]. The main conclusion is that most of the header fields 280 can easily be compressed away since they seldom or never change. The 281 following fields do however require more sophisticated mechanisms: 283 - IPv4 Identification (16 bits) - IP-ID 284 - TCP Sequence number (32 bits) - SN 285 - TCP Acknowledgment number (32 bits) 286 - TCP Reserved ( 4 bits) 287 - TCP ECN flags ( 2 bits) - ECN 288 - TCP Window (16 bits) 289 - TCP Options 290 o Maximum Segment Size (32 bits) - MSS 291 o Window Scale (24 bits) - WSCALE 292 o SACK Permitted (16 bits) 293 o TCP SACK (80, 144, 208 or 272 bits) - SACK 294 o TCP Timestamp (80 bits) - TS 296 The assignment of IP-ID values can be done in various ways, most 297 usually one of sequential, sequential jump or random, as described in 298 Section 4.1.3 of [RFC4413]. Some IPv4 stacks do use a sequential 299 assignment when generating IP-ID values but do not transmit the 300 contents of this field in network byte order; instead it is sent with 301 the two octets reversed. In this case, the compressor can compress 302 the IP-ID field after swapping the bytes. Consequently, the 303 decompressor also swaps the bytes of the IP-ID after decompression to 304 regenerate the original IP-ID. With respect to TCP compression, the 305 analysis in [RFC4413] reveals that there is no obvious candidate 306 among the TCP fields suitable to infer the IP-ID. 308 The change pattern of several TCP fields (Sequence Number, 309 Acknowledgment Number, Window, etc.) is very hard to predict. Of 310 particular importance to a TCP/IP header compression scheme is the 311 understanding of the sequence and acknowledgment numbers [RFC4413]. 313 Specifically, the TCP Sequence Number can be anywhere within a range 314 defined by the TCP Window at any point on the path (i.e. wherever a 315 compressor might be deployed). Missing packets or retransmissions 316 can cause the TCP Sequence Number to fluctuate within the limits of 317 this window. The TCP Window also bounds the jumps in acknowledgment 318 number. 320 Another important behavior of the TCP/IP header is the dependency 321 between the sequence number and the acknowledgment number. TCP 322 connections can be either near-symmetrical or show a strong 323 asymmetrical bias with respect to the data traffic. In the latter 324 case, the TCP connections mainly have one-way traffic (web browsing 325 and file downloading, for example). This means that on the forward 326 path (from server to client), only the sequence number is changing 327 while the acknowledgment number remains constant for most packets; on 328 the backward path (from client to server), only the acknowledgment 329 number is changing and the sequence number remains constant for most 330 packets. A compression scheme for TCP should thus have packet 331 formats suitable for either cases, i.e. packet formats that can carry 332 either only sequence number bits, only acknowledgment number bits, or 333 both. 335 In addition, TCP flows can be short-lived transfers. Short-lived TCP 336 transfers will degrade the performance of header compression schemes 337 that establish a new context by initially sending full headers. 338 Multiple simultaneous or near simultaneous TCP connections may 339 exhibit much similarity in header field values and context values 340 among each other, which would make it possible to reuse information 341 between flows when initializing a new context. A mechanism to this 342 end, context replication [RFC4164], makes the context establishment 343 step faster and more efficient, by replicating part of an existing 344 context to a new flow. The conclusion from [RFC4413] is that part of 345 the IP sub-context, some TCP fields, and some context values can be 346 replicated since they seldom change or change with only a small jump. 348 ROHC-TCP also compresses the following headers: IPv6 Destination 349 Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by- 350 hop Options header [RFC2460], AH [RFC4302], NULL-encrypted ESP header 351 [RFC4303], GRE [RFC2784][RFC2890] and the Minimal Encapsulation 352 header (MINE) [RFC2004]. 354 Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any 355 special treatment in this document, for reasons similar as those 356 described in [RFC3095]. 358 4. Overview of the TCP/IP Profile (Informative) 360 4.1. General Concepts 362 ROHC-TCP uses the ROHC protocol as described in 363 [I-D.ietf-rohc-rfc3095bis-framework]. ROHC-TCP supports context 364 replication as defined in [RFC4164]. Context replication can be 365 particularly useful for short-lived TCP flows [RFC4413]. 367 4.2. Compressor and Decompressor Interactions 369 4.2.1. Compressor Operation 371 Header compression with ROHC can be conceptually characterized as the 372 interaction of a compressor with a decompressor state machine. The 373 compressor's task is to minimally send the information needed to 374 successfully decompress a packet, based on a certain confidence 375 regarding the state of the decompressor context. 377 For ROHC-TCP compression, the compressor normally starts compression 378 with the initial assumption that the decompressor has no useful 379 information to process the new flow, and sends Initialization and 380 Refresh (IR) packets. Alternatively, the compressor may also support 381 Context Replication (CR) and use IR-CR packets [RFC4164] which 382 attempts to reuse context information related to another flow. 384 The compressor can then adjust the compression level based on its 385 confidence that the decompressor has the necessary information to 386 successfully process the compressed packets (CO) that it selects. In 387 other words, the task of the compressor is to ensure that the 388 decompressor operates in the state that allows decompression of the 389 most efficient CO packet(s), and to allow the decompressor to move to 390 that state as soon as possible otherwise. 392 4.2.2. Decompressor Feedback 394 The ROHC-TCP profile can be used in environments with or without 395 feedback capabilities from decompressor to compressor. ROHC-TCP 396 however assumes that if a ROHC feedback channel is available and if 397 this channel is used at least once by the decompressor for a specific 398 ROHC-TCP context, this channel will be used during the entire 399 compression operation for that context. If the feedback channel 400 disappears, compression should be restarted. 402 The reception of either positive feedback (ACKs) or negative feedback 403 (NACKs) establishes the feedback channel from the decompressor for 404 the context for which the feedback was received. Once there is an 405 established feedback channel for a specific context, the compressor 406 should make use of this feedback to estimate the current state of the 407 decompressor. This helps increasing the compression efficiency by 408 providing the information needed for the compressor to achieve the 409 necessary confidence level. 411 The ROHC-TCP feedback mechanism is limited in its applicability by 412 the number of (LSB encoded) MSN (see Section 6.1.1) bits used in the 413 FEEDBACK-2 format (see Section 8.3). It is not suitable for a 414 decompressor to use feedback altogether where the MSN bits in the 415 feedback could wraparound within one round-trip time. Instead, 416 unidirectional operation -- where the compressor periodically sends 417 larger context updating packets -- is more appropriate. 419 4.3. Packet Formats and Encoding Methods 421 The packet formats and encoding methods used for ROHC-TCP are defined 422 using the formal notation [I-D.ietf-rohc-formal-notation]. The 423 formal notation is used to provide an unambiguous representation of 424 the packet formats and a clear definition of the encoding methods. 426 4.3.1. Compressing TCP Options 428 The TCP options in ROHC-TCP are compressed using a list compression 429 encoding that allows option content to be established so that TCP 430 options can be added to the context without having to send all TCP 431 options uncompressed. 433 4.3.2. Compressing Extension Headers 435 ROHC-TCP compresses the extension headers as listed in Section 3.2. 436 These headers are treated exactly as other headers and thus have a 437 static chain, a dynamic chain, an irregular chain and a chain for 438 context replication (Section 6.2). 440 This means that headers appearing in or disappearing from the flow 441 being compressed will lead to changes to the static chain. However, 442 the change pattern of extension headers is not deemed to impair 443 compression efficiency with respect to this design strategy. 445 4.4. Expected Compression Ratios with ROHC-TCP 447 The following table illustrates typical compression ratios that can 448 be expected when using ROHC-TCP and IPHC [RFC2507]. 450 The figures in the table assume that the compression context has 451 already been properly initialized. For the TS option, the timestamp 452 is assumed to change with small values. All TCP options include a 453 suitable number of NOP options [RFC0793] for padding and/or 454 alignment. Finally, in the examples for IPv4, a sequential IP-ID 455 behavior is assumed. 457 Total Header Size (octets) 458 ROHC-TCP IPHC 459 Unc. DATA ACK DATA ACK 460 IPv4+TCP+TS 52 8 8 18 18 461 IPv4+TCP+TS 52 7 6 16 16 (1) 462 IPv6+TCP+TS 72 8 7 18 18 463 IPv6+TCP+no opt 60 6 5 6 6 464 IPv6+TCP+SACK 80 - 15 - 80 (2) 465 IPv6+TCP+SACK 80 - 9 - 26 (3) 467 (1) The payload size of the data stream is constant 468 (2) The SACK option appears in the header, but was not present 469 in the previous packet. Two SACK blocks are assumed. 470 (3) The SACK option appears in the header, and was also present 471 in the previous packet (with different SACK blocks). 472 Two SACK blocks are assumed. 474 The table below illustrates the typical initial compression ratios 475 for ROHC-TCP and IPHC. The data stream in the example is assumed to 476 be IPv4+TCP, with a sequential behavior for the IP-ID. The following 477 options are assumed present in the SYN packet: TS, MSS and WSCALE, 478 with an appropriate number of NOP options. 480 Total Header Size (octets) 481 Unc. ROHC-TCP IPHC 482 1st packet (SYN) 60 49 60 483 2nd packet 52 12 52 485 The figures in the table assume that the compressor has received an 486 acknowledgement from the decompressor before compressing the second 487 packet, which can be expected when feedback is used in ROHC-TCP; this 488 is because in the most common case the TCP ACKs are expected to take 489 the same return path, and because TCP does not send more packets 490 until the TCP SYN packet has been acknowledged. 492 5. Compressor and Decompressor Logic (Normative) 493 5.1. Context Initialization 495 The static context of ROHC TCP flows can be initialized in either of 496 two ways: 498 1. By using an IR packet as in Section 7.1, where the profile number 499 is 0x06 and the static chain ends with the static part of a TCP 500 header. 501 2. By replicating an existing context using the mechanism defined by 502 [RFC4164]. This is done with the IR-CR packet defined in 503 Section 7.2, where the profile number is 0x06. 505 5.2. Compressor Operation 507 5.2.1. Compression Logic 509 The task of the compressor is to determine what data must be sent 510 when compressing a TCP/IP packet, so that the decompressor can 511 successfully reconstruct the original packet based on its current 512 state. The selection of the type of compressed header to send thus 513 depends on a number of factors, including: 515 o The change behavior of header fields in the flow, e.g. conveying 516 the necessary information within the restrictions of the set of 517 available packet formats; 518 o The compressor's level of confidence regarding decompressor state, 519 e.g. by selecting header formats updating the same type of 520 information for a number of consecutive packets or from the 521 reception of decompressor feedback (ACKs and/or NACKs); 522 o Additional robustness required for the flow, e.g. periodic 523 refreshes of static and dynamic information using IR and IR-DYN 524 packets when decompressor feedback is not expected. 526 The impact of these factors on the compressor's packet type selection 527 is described more in detail in the following subsections. 529 In this section, a "higher compression state" means that less data 530 will be sent in compressed packets, i.e. smaller compressed headers 531 are used, while a lower compression state means that a larger amount 532 of data will be sent using larger compressed headers. 534 5.2.1.1. Optimistic Approach 536 The optimistic approach is the principle by which a compressor send 537 the same type of information for a number of packets (consecutively 538 or not) until it is fairly confident that the decompressor has 539 received the information. The optimistic approach is useful to 540 ensure robustness when ROHC-TCP is used to compress packet over lossy 541 links. 543 Therefore, if field X in the uncompressed packet changes value, the 544 compressor MUST use a packet type that contains an encoding for field 545 X until it has gained confidence that the decompressor has received 546 at least one packet containing the new value for X. The compressor 547 SHOULD choose a compressed format with the smallest header that can 548 convey the changes needed to fulfill the optimistic approach 549 condition used. 551 5.2.1.2. Periodic Context Refreshes 553 When the optimistic approach is used, there will always be a 554 possibility of decompression failures since the decompressor may not 555 have received sufficient information for correct decompression. 557 Therefore, until the decompressor has established a feedback channel, 558 the compressor SHOULD periodically move to a lower compression state 559 and send IR and/or IR-DYN packets. These refreshes can be based on 560 timeouts, on the number of compressed packets sent for the flow or 561 any other strategy specific to the implementation. Once the feedback 562 channel is established, the decompressor MAY stop performing periodic 563 refreshes. 565 5.2.2. Feedback Logic 567 The semantics of feedback messages, acknowledgements (ACKs) and 568 negative acknowledgments (NACKs or STATIC-NACKs), are defined in 569 section 5.2.4.1 of [I-D.ietf-rohc-rfc3095bis-framework]. 571 5.2.2.1. Optional Acknowledgments (ACKs) 573 The compressor MAY use acknowledgment feedback (ACKs) to move to a 574 higher compression state. 576 Upon reception of an ACK for a context-updating packet, the 577 compressor obtains confidence that the decompressor has received the 578 acknowledged packet and that it has observed changes in the packet 579 flow up to the acknowledged packet. 581 This functionality is optional, so a compressor MUST NOT expect to 582 get such ACKs, even if a feedback channel is available and has been 583 established for that flow. 585 5.2.2.2. Negative Acknowledgments (NACKs) 587 The compressor uses feedback from the decompressor to move to a lower 588 compression state (NACKs). 590 On reception of a NACK feedback, the compressor SHOULD: 592 o assume that only the static part of the decompressor is valid, and 593 o re-send all dynamic information (via an IR or IR-DYN packet) next 594 time it compresses a packet for the indicated flow 596 unless it has confidence that information sent after the packet being 597 acknowledged already provides a suitable response to the NACK 598 feedback. In addition, the compressor MAY use a CO packet carrying a 599 7-bit CRC if it can determine with enough confidence what information 600 consists a suitable response to the NACK feedback. 602 On reception of a STATIC-NACK feedback, the compressor SHOULD: 604 o assume that the decompressor has no valid context, and 605 o re-send all static and all dynamic information (via an IR packet) 606 next time it compresses a packet for the indicated flow. 608 unless it has confidence that information sent after the packet that 609 is being acknowledged already provides a suitable response to the 610 STATIC-NACK feedback. 612 5.2.3. Context Replication 614 A compressor MAY support context replication by implementing the 615 additional compression and feedback logic defined in [RFC4164]. 617 5.3. Decompressor Operation 619 5.3.1. Decompressor States and Logic 621 The three states of the decompressor are No Context (NC), Static 622 Context (SC) and Full Context (FC). The decompressor starts in its 623 lowest compression state, the NC state. Successful decompression 624 will always move the decompressor to the FC state. The decompressor 625 state machine normally never leaves the FC state once it has entered 626 this state; only repeated decompression failures will force the 627 decompressor to transit downwards to a lower state. 629 Below is the state machine for the decompressor. Details of the 630 transitions between states and decompression logic are given in the 631 sub-sections following the figure. 633 Success 634 +-->------>------>------>------>------>--+ 635 | | 636 No Static | No Dynamic Success | Success 637 +-->--+ | +-->--+ +--->----->---+ +-->--+ 638 | | | | | | | | | 639 | v | | v | v | v 640 +-----------------+ +---------------------+ +-------------------+ 641 | No Context (NC) | | Static Context (SC) | | Full Context (FC) | 642 +-----------------+ +---------------------+ +-------------------+ 643 ^ | ^ | 644 | Static Context | | Context Damage Assumed | 645 | Damage Assumed | | | 646 +-----<------<------<-----+ +-----<------<------<-----+ 648 5.3.1.1. Reconstruction and Verification 650 When decompressing an IR or an IR-DYN packet, the decompressor MUST 651 validate the integrity of the received header using CRC-8 validation 652 [I-D.ietf-rohc-rfc3095bis-framework]. If validation fails, the 653 packet MUST NOT be delivered to upper layers. 655 Upon receiving an IR-CR packet, the decompressor MUST perform the 656 actions as specified in [RFC4164]. 658 When decompressing other packet types (CO packets), the decompressor 659 MUST validate the outcome of the decompression attempt using CRC 660 verification [I-D.ietf-rohc-rfc3095bis-framework]. If verification 661 fails, a decompressor implementation MAY attempt corrective or repair 662 measures on the packet, and the result of any attempt MUST be 663 validated using the CRC verification; otherwise, the packet MUST NOT 664 be delivered to upper layers. 666 When the CRC-8 validation or the CRC verification of the received 667 header is successful, the decompressor SHOULD update its context with 668 the information received in the current header; the decompressor then 669 passes the reconstructed packet to the system's network layer. 670 Otherwise, the decompressor context MUST NOT be updated. 672 If the received packet is older than the current reference packet, 673 e.g based on the Master Sequence number (MSN) in the compressed 674 packet, the decompressor MAY refrain from updating the context using 675 the information received in the current packet, even if the 676 correctness of its header was successfully verified. 678 5.3.1.2. Detecting Context Damage 680 All header formats carry a CRC and are context updating. A packet 681 for which the CRC succeeds updates the reference values of all header 682 fields, either explicitly (from the information about a field carried 683 within the compressed header) or implicitly (fields that are inferred 684 from other fields). 686 The decompressor may assume that some or the entire context is 687 invalid, following one or more failures to validate or verify a 688 header using the CRC. Because the decompressor cannot know the exact 689 reason(s) of a CRC failure or what field caused it, the validity of 690 the context hence does not refer to what exact context entry is 691 deemed valid or not. 693 Validity of the context rather relates to the detection of a problem 694 with the context. The decompressor first assumes that the type of 695 information that most likely caused the failure(s) is the state that 696 normally changes for each packet, i.e. context damage of the dynamic 697 part of the context. Upon repeated failures and unsuccessful 698 repairs, the decompressor then assume that the entire context, 699 including the static part, needs to be repaired, i.e. static context 700 damage. 702 Context Damage Detection 704 The assumption of context damage means that the decompressor will 705 not attempt decompression of a CO header that carries a 3-bit CRC, 706 and only attempt decompression of IR, IR-DYN or IR-CR headers, or 707 CO headers protected by a CRC-7. 709 Static Context Damage Detection 711 The assumption of static context damage means that the 712 decompressor refrains from attempting decompression of any type of 713 header other than the IR header, as it cannot know what part of 714 its context can be relied upon after first assuming context damage 715 and failed to repair its context, and as a result of too many 716 failures. 718 How these assumptions are made, i.e. how context damage is detected, 719 is open to implementations. It can be based on the residual error 720 rate, where a low error rate makes the decompressor assume damage 721 more often than on a high rate link. 723 The decompressor implements these assumptions by selecting the type 724 of compressed header for which it may attempt decompression. In 725 other words, validity of the context refers to the ability of a 726 decompressor to attempt or not decompression of specific packet 727 types. 729 5.3.1.3. No Context (NC) State 731 Initially, while working in the No Context (NC) state, the 732 decompressor has not yet successfully decompressed a packet. 734 Allowing decompression: 736 In the NC state, only packets carrying sufficient information on 737 the static fields (IR and IR-CR packets) can be decompressed; 738 otherwise, the packet MUST NOT be decompressed and MUST NOT be 739 delivered to upper layers. 741 Feedback logic: 743 In the NC state, the decompressor should send a STATIC- NACK if a 744 packet of a type other than IR is received, or if decompression of 745 an IR packet has failed, subject to the feedback rate limitation 746 as described in Section 5.3.2 748 Once a packet has been validated and decompressed correctly, the 749 decompressor MUST transit to the FC state. 751 5.3.1.4. Static Context (SC) State 753 When the decompressor is in the Static Context (SC) state, only the 754 static part of the decompressor context is valid. 756 From the SC state, the decompressor moves back to the NC state if 757 static context damage is detected. 759 Allowing decompression: 761 In the SC state, packets carrying sufficient information on the 762 dynamic fields covered by an 8-bit CRC (e.g. IR and IR-DYN) or CO 763 packets covered by a 7-bit CRC can be decompressed; otherwise, the 764 packet MUST NOT be decompressed and MUST NOT be delivered to upper 765 layers. 767 Feedback logic: 769 In the SC state, the decompressor should send a STATIC-NACK if CRC 770 validation of an IR/IR-DYN/IR-CR fails and static context damage 771 is assumed. If any other packet type is received, the 772 decompressor should send a NACK. Both of the above cases are 773 subject to the feedback rate limitation as described in 774 Section 5.3.2. 776 Once a packet has been validated and decompressed correctly, the 777 decompressor MUST transit to the FC state. 779 5.3.1.5. Full Context (FC) State 781 In the Full Context (FC) state, both the static and the dynamic parts 782 of the decompressor context are valid. From the FC state, the 783 decompressor moves back to the SC state if context damage is 784 detected. 786 Allowing decompression: 788 In the FC state, decompression can be attempted regardless of the 789 type of packet received. 791 Feedback logic: 793 In the FC, the decompressor should send a NACK if the 794 decompression of any packet type fails and context damage is 795 assumed, subject to the feedback rate limitation as described in 796 Section 5.3.2. 798 5.3.2. Feedback Logic 800 The decompressor MAY send positive feedback (ACKs) to initially 801 establish the feedback channel for a particular flow. Either 802 positive feedback (ACKs) or negative feedback (NACKs) establishes 803 this channel. 805 Once the feedback channel is established, the decompressor is 806 REQUIRED to continue sending NACKs or STATIC-NACKs for as long as the 807 context is associated with the same profile, in this case with 808 profile 0x0006, as per the logic defined for each state in 809 Section 5.3.1. 811 The decompressor MAY send ACKs upon successful decompression of any 812 packet type. In particular, when a packet carrying a significant 813 context update is correctly decompressed, the decompressor MAY send 814 an ACK. 816 The decompressor should limit the rate at which it sends feedback, 817 for both ACKs and STATIC-NACK/NACKs, and should avoid sending 818 unnecessary duplicates of the same type of feedback message that may 819 be associated to the same event. 821 5.3.3. Context Replication 823 ROHC-TCP supports context replication, therefore the decompressor 824 MUST implement the additional decompressor and feedback logic defined 825 in [RFC4164]. 827 6. Encodings in ROHC-TCP (Normative) 829 6.1. Control Fields in ROHC-TCP 831 In ROHC-TCP, a number of control fields are used by the decompressor 832 in its interpretation of the format of the packets received from the 833 compressor. 835 A control field is a field that is transmitted from the compressor to 836 the decompressor, but is not part of the uncompressed header. Values 837 for control fields can be set up in the context of both the 838 compressor and the decompressor. Once established at the 839 decompressor, the values of these fields should be kept until updated 840 by another packet. 842 6.1.1. Master Sequence Number (MSN) 844 There is no field in the TCP header that can act as the master 845 sequence number for TCP compression, as explained in [RFC4413], 846 section 5.6. 848 To overcome this problem, ROHC-TCP introduces a control field called 849 the Master Sequence Number (MSN) field. The MSN field is created at 850 the compressor, rather than using one of the fields already present 851 in the uncompressed header. The compressor increments the value of 852 the MSN by one for each packet that it sends. 854 The MSN field has the following two functions: 856 1. Differentiating between packets when sending feedback data. 857 2. Inferring the value of incrementing fields such as the IP-ID. 859 The MSN field is present in every packet sent by the compressor. The 860 MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent 861 in full in IR/IR-DYN packets. The decompressor always sends the MSN 862 as part of the feedback information. The compressor can later use 863 the MSN to infer which packet the decompressor is acknowledging. 865 When the MSN is initialized, it SHOULD be initialized to a random 866 value. The compressor should only initialize a new MSN for the 867 initial IR or IR-CR packet sent for a CID that corresponds to a 868 context that is not already associated with this profile. In other 869 words, if the compressor reuses the same CID to compress many TCP 870 flows one after the other, the MSN is not reinitialized but rather 871 continues to increment monotonically. 873 For context replication, the compressor does not use the MSN of the 874 base context when sending the IR-CR packet, unless the replication 875 process overwrites the base context (i.e. Base CID == CID). 876 Instead, the compressor uses the value of the MSN if it already 877 exists in the ROHC-TCP context being associated with the new flow 878 (CID); otherwise, the MSN is initialized to a new value. 880 6.1.2. IP-ID Behavior 882 The IP-ID field of the IPv4 header can have different change 883 patterns. Conceptually, a compressor monitors changes in the value 884 of the IP-ID field and selects encoding methods and packet formats 885 that are the closest match to the observed change pattern. 887 RoHC-TCP defines different types of compression techniques for the 888 IP-ID, to provide the flexibility to compress any of the behavior it 889 may observe for this field: sequential in network byte order (NBO), 890 sequential byte-swapped, random (RND) or constant to a value of zero. 892 The compressor monitors changes in the value of the IP-ID field for a 893 number of packets, to identify which one of the above listed 894 compression alternative is the closest match to the observed change 895 pattern. The compressor can then select packet formats and encoding 896 methods based on the identified field behavior. 898 If more than one level of IP headers is present, ROHC-TCP can assign 899 a sequential behavior (NBO or byte-swapped) only to the IP-ID of the 900 innermost IP header. This is because only this IP-ID can possibly 901 have a sufficiently close correlation with the MSN (see also 902 Section 6.1.1) to compress it as a sequentially changing field. 903 Therefore, a compressor MUST NOT assign either the sequential (NBO) 904 or the sequential byte-swapped behavior to tunneling headers. 906 The control field for the IP-ID behavior determines which set of 907 packet formats will be used. These control fields are also used to 908 determine the contents of the irregular chain item (see Section 6.2) 909 for each IP header. 911 6.1.3. Explicit Congestion Notification (ECN) 913 When ECN [RFC3168] is used once on a flow, the ECN bits could change 914 quite often. ROHC-TCP maintains a control field in the context to 915 indicate if ECN is used or not. This control field is transmitted in 916 the dynamic chain of the TCP header, and its value can be updated 917 using specific compressed headers carrying a 7-bit CRC. 919 When this control field indicates that ECN is being used, items of IP 920 and TCP headers in the irregular chain include bits used for ECN. To 921 preserve octet-alignment, all of the TCP reserved bits are 922 transmitted and, for outer IP headers, the entire TOS/TC field is 923 included in the irregular chain. 925 The design rationale behind this is the possible use of the "full- 926 functionality option" of section 9.1 of [RFC3168]. 928 6.2. Compressed Header Chains 930 Some packet types use one or more chains containing sub-header 931 information. The function of a chain is to group fields based on 932 similar characteristics, such as static, dynamic or irregular fields. 933 Chaining is done by appending an item for each header to the chain in 934 their order of appearance in the uncompressed packet, starting from 935 the fields in the outermost header. 937 Chains are defined for all headers compressed by ROHC-TCP, as listed 938 below. Also listed are the names of the encoding methods used to 939 encode each of these protocol headers. 941 o TCP [RFC0793], encoding method: "tcp" 942 o IPv4 [RFC0791], encoding method: "ipv4" 943 o IPv6 [RFC2460], encoding method: "ipv6" 944 o AH [RFC4302], encoding method: "ah" 945 o GRE [RFC2784][RFC2890], encoding method: "gre" 946 o MINE [RFC2004], encoding method: "mine" 947 o NULL-encrupted ESP [RFC4303], encoding method: "esp_null" 948 o IPv6 Destination Options header[RFC2460], encoding method: 949 "ip_dest_opt" 950 o IPv6 Hop-by-hop Options header[RFC2460], encoding method: 951 "ip_hop_opt" 952 o IPv6 Routing header [RFC2460], encoding method: "ip_rout_opt" 954 Static chain: 956 The static chain consists of one item for each header of the chain 957 of protocol headers to be compressed, starting from the outermost 958 IP header and ending with a TCP header. In the formal description 959 of the packet formats, this static chain item for each header is a 960 format whose name is suffixed by "_static". The static chain is 961 only used in IR packets. 963 Dynamic chain: 965 The dynamic chain consists of one item for each header of the 966 chain of protocol headers to be compressed, starting from the 967 outermost IP header and ending with a TCP header. The dynamic 968 chain item for the TCP header also contains a compressed list of 969 TCP options (see Section 6.3). In the formal description of the 970 packet formats, the dynamic chain item for each header type is a 971 format whose name is suffixed by "_dynamic". The dynamic chain is 972 used both in IR and IR-DYN packets. 974 Replicate chain: 976 The replicate chain consists of one item for each header in the 977 chain of protocol headers to be compressed, starting from the 978 outermost IP header and ending with a TCP header. The replicate 979 chain item for the TCP header also contains a compressed list of 980 TCP options (see Section 6.3). In the formal description of the 981 packet formats, the replicate chain item for each header type is a 982 format whose name is suffixed by "_replicate". Header fields that 983 are not present in the replicate chain are replicated from the 984 base context. The replicate chain is only used in the IR-CR 985 packet. 987 Irregular chain: 989 The structure of the irregular chain is analogous to the structure 990 of the static chain. For each compressed packet, the irregular 991 chain is appended at the specified location in the general format 992 of the compressed packets as defined in Section 7.3. This chain 993 also includes the irregular chain items for TCP options as defined 994 in Section 6.3.6, which are placed directly after the irregular 995 chain item of the TCP header, and in the same order as the options 996 appear in the uncompressed packet. In the formal description of 997 the packet formats, the irregular chain item for each header type 998 is a format whose name is suffixed by "_irregular". The irregular 999 chain is used only in CO packets. 1001 The format of the irregular chain for the innermost IP header 1002 differs from the format of outer IP headers, since this header is 1003 part of the compressed base header. 1005 6.3. Compressing TCP Options with List Compression 1007 This section describes in detail how list compression is applied to 1008 the TCP options. In the definition of the packet formats for ROHC- 1009 TCP, the most frequent TCP options have one encoding method each, as 1010 listed in the table below. 1012 +-----------------+------------------------+ 1013 | Option name | Encoding method name | 1014 +-----------------+------------------------+ 1015 | NOP | tcp_opt_nop | 1016 | EOL | tcp_opt_eol | 1017 | MSS | tcp_opt_mss | 1018 | WINDOW SCALE | tcp_opt_wscale | 1019 | TIMESTAMP | tcp_opt_ts | 1020 | SACK-PERMITTED | tcp_opt_sack_permitted | 1021 | SACK | tcp_opt_sack | 1022 | Generic options | tcp_opt_generic | 1023 +-----------------+------------------------+ 1025 Each of these encoding methods has an uncompressed format, a format 1026 suffixed by "_list_item" and a format suffixed by "_irregular". In 1027 some cases, a single encoding method may have multiple "_list_item" 1028 or "_irregular" formats, in which case bindings inside these formats 1029 determines what format is used. This is further described in the 1030 following sections. 1032 6.3.1. List Compression 1034 The TCP options in the uncompressed packet can be represented as an 1035 ordered list, whose order and presence are usually constant between 1036 packets. The generic structure of such a list is as follows: 1038 +--------+--------+--...--+--------+ 1039 list: | item 1 | item 2 | | item n | 1040 +--------+--------+--...--+--------+ 1042 To compress this list, ROHC-TCP uses a list compression scheme which 1043 compresses each of these items individually, and combines them into a 1044 compressed list. 1046 The basic principles of list-based compression are the following: 1048 1) When a context is being initialized, a complete representation 1049 of the compressed list of options is transmitted. All options 1050 that have any content are present in the compressed list of items 1051 sent by the compressor. 1053 Then, once the context has been initialized: 1055 2) When the structure AND the content of the list are unchanged, 1056 no information about the list is sent in compressed headers. 1057 3) When the structure of the list is constant, and when only the 1058 content defined within the irregular format for one or more 1059 options is changed, no information about the list needs to be sent 1060 in compressed base headers; the irregular content is sent as part 1061 of the irregular chain, as described in Section 6.3.6. 1062 4) When the structure of the list changes, a compressed list is 1063 sent in the compressed base header, including a representation of 1064 its structure and order. Content defined within the irregular 1065 format of an option can still be sent as part of the irregular 1066 chain (as described in Section 6.3.6), provided that the item 1067 content is not part of the compressed list. 1069 6.3.2. Table-based Item Compression 1071 The Table-based item compression compresses individual items sent in 1072 compressed lists. The compressor assigns a unique identifier, 1073 "Index", to each item, "Item", of a list. 1075 Compressor Logic 1077 The compressor conceptually maintains an Item Table containing all 1078 items, indexed using "Index". The (Index, Item) pair is sent 1079 together in compressed lists until the compressor gains enough 1080 confidence that the decompressor has observed the mapping between 1081 items and their respective index. Confidence is obtained from the 1082 reception of an acknowledgment from the decompressor, or by 1083 sending (Index, Item) pairs using the optimistic approach. Once 1084 confidence is obtained, the index alone is sent in compressed 1085 lists to indicate the presence of the item corresponding to this 1086 index. 1088 The compressor may reassign an existing index to a new item, by 1089 re-establishing the mapping using the procedure described above. 1091 Decompressor Logic 1093 The decompressor conceptually maintains an Item Table that 1094 contains all (Index, Item) pairs received. The Item Table is 1095 updated whenever an (Index, Item) pair is received and 1096 decompression is successfully verified using the CRC. The 1097 decompressor retrieves the item from the table whenever an Index 1098 without an accompanying Item is received. 1100 If an index without an accompanying item is received and the 1101 decompressor does not have any context for this index, the header 1102 MUST be discarded and a NACK SHOULD be sent. 1104 6.3.3. Encoding of Compressed Lists 1106 Each item present in a compressed list is represented by: 1108 o an index into the table of items 1109 o a presence bit indicating if a compressed representation of the 1110 item is present in the list 1111 o an item (if the presence bit is set) 1113 Decompression of an item will fail if the presence bit is not set and 1114 the decompressor has no entry in the context for that item. 1116 A compressed list of TCP options uses the following encoding: 1118 0 1 2 3 4 5 6 7 1119 +---+---+---+---+---+---+---+---+ 1120 | Reserved |PS | m | 1121 +---+---+---+---+---+---+---+---+ 1122 | XI_1, ..., XI_m | m octets, or m * 4 bits 1123 / --- --- --- ---/ 1124 | : Padding : if PS = 0 and m is odd 1125 +---+---+---+---+---+---+---+---+ 1126 | | 1127 / item_1, ..., item_n / variable 1128 | | 1129 +---+---+---+---+---+---+---+---+ 1131 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1132 discard the packet. 1134 PS: Indicates size of XI fields: 1135 PS = 0 indicates 4-bit XI fields; 1136 PS = 1 indicates 8-bit XI fields. 1138 m: Number of XI item(s) in the compressed list. 1140 XI_1, ..., XI_m: m XI items. Each XI represents one TCP option in 1141 the uncompressed packet, in the same order as they appear in the 1142 uncompressed packet. 1144 The format of an XI item is as follows: 1146 +---+---+---+---+ 1147 PS = 0: | X | Index | 1148 +---+---+---+---+ 1150 0 1 2 3 4 5 6 7 1151 +---+---+---+---+---+---+---+---+ 1152 PS = 1: | X | Reserved | Index | 1153 +---+---+---+---+---+---+---+---+ 1155 X: Indicates whether the item is present in the list: 1157 X = 1 indicates that the item corresponding to the Index is 1158 sent in the item_1, ..., item_n list; 1159 X = 0 indicates that the item corresponding to the Index is 1160 not sent and is instead included in the irregular chain. 1162 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1163 discard the packet. 1165 Index: An index into the item table. See Section 6.3.4. 1167 When 4-bit XI items are used, the XI items are placed in octets 1168 in the following manner: 1170 0 1 2 3 4 5 6 7 1171 +---+---+---+---+---+---+---+---+ 1172 | XI_k | XI_k + 1 | 1173 +---+---+---+---+---+---+---+---+ 1175 Padding: A 4-bit padding field is present when PS = 0 and the 1176 number of XIs is odd. The Padding field MUST be set to zero; 1177 otherwise the decompressor MUST discard the packet. 1179 Item 1, ..., item n: Each item corresponds to an XI with X = 1 in 1180 XI 1, ..., XI m. The format of the entries in the item list is 1181 described in Section 6.2. 1183 6.3.4. Item Table Mappings 1185 The item table for TCP options list compression is limited to 16 1186 different items, since it is unlikely that any packet flow will 1187 contain a larger number of unique options. 1189 The mapping between TCP option type and table indexes are listed in 1190 the table below: 1192 +-----------------+---------------+ 1193 | Option name | Table index | 1194 +-----------------+---------------+ 1195 | NOP | 0 | 1196 | EOL | 1 | 1197 | MSS | 2 | 1198 | WINDOW SCALE | 3 | 1199 | TIMESTAMP | 4 | 1200 | SACK-PERMITTED | 5 | 1201 | SACK | 6 | 1202 | Generic options | 7-15 | 1203 +-----------------+---------------+ 1205 Some TCP options are used more frequently than others. To simplify 1206 their compression, a part of the item table is reserved for these 1207 option types, as shown on the table above. Both the compressor and 1208 the decompressor MUST use these mappings between item and indexes to 1209 (de)compress TCP options when using list compression. 1211 It is expected that the option types for which an index is reserved 1212 in the item table will only appear once in a list. However, if an 1213 option type is detected twice in the same options list and if both 1214 options have a different content, the compressor should compress the 1215 second occurrence of the option type by mapping it to a generic 1216 compressed option. Otherwise, if the options have the exact same 1217 content, the compressor can still use the same table index for both. 1219 The NOP option 1221 The NOP option can appear more than once in the list. However, 1222 since its value is always the same, no context information needs 1223 to be transmitted. Multiple NOP options can thus be mapped to the 1224 same index. Since the NOP option does not have any content when 1225 compressed as a "_list_item", it will never be present in the item 1226 list. For consistency, the compressor should still establish an 1227 entry in the list by setting the presence bit, as done for the 1228 other type of options. 1230 List compression always preserves the original order of each item 1231 in the decompressed list, no matter if the item is present or not 1232 in the compressed "_list_item" or if multiple items of the same 1233 type can be mapped to the same index, as for the NOP option. 1235 The EOL option 1236 The size of the compressed format for the EOL option can be larger 1237 than one octet, and it is defined so that it includes the option 1238 padding. This is because the EOL should terminate the parsing of 1239 the options, but it can also be followed by padding octets that 1240 all have the value zero. 1242 The Generic option 1244 The generic option can be used to compress any type of TCP option 1245 that does not have a reserved index in the item table. 1247 6.3.5. Compressed Lists in Dynamic Chain 1249 A compressed list for TCP options that is part of the dynamic chain 1250 (e.g. in IR or IR-DYN packets) must have all its list items present, 1251 i.e. all X-bits in the XI list MUST be set. 1253 6.3.6. Irregular Chain Items for TCP Options 1255 The "_list_item" represents the option inside the compressed item 1256 list, and the "_irregular" format is used for the option fields that 1257 are expected to change with each packet. When an item of the 1258 specified type is present in the current context, these irregular 1259 fields are present in each compressed packet, as part of the 1260 irregular chain. Since many of the TCP option types are not expected 1261 to change for the duration of a flow, many of the "_irregular" 1262 formats are empty. 1264 The irregular chain for TCP options is structured analogously to the 1265 structure of the TCP options in the uncompressed packet. If a 1266 compressed list is present in the compressed packet, then the 1267 irregular chain for TCP options must not contain irregular items for 1268 the list items that are transmitted inside the compressed list (i.e. 1269 items in the list that have the X-bit set in its XI). The items that 1270 are not present in the compressed list, but are present in the 1271 uncompressed list, must have their respective irregular items present 1272 in the irregular chain. 1274 6.3.7. Replication of TCP Options 1276 The entire table of TCP options items is always replicated when using 1277 the IR-CR packet. In the IR-CR packet, the list of options for the 1278 new flow is also transmitted as a compressed list in the IR-CR 1279 packet. 1281 6.4. Profile-specific Encoding Methods 1283 This section defines encoding methods that are specific to this 1284 profile. These methods are used in the formal definition of the 1285 packet formats in Section 8. 1287 6.4.1. inferred_ip_v4_header_checksum 1289 This encoding method compresses the header checksum field of the IPv4 1290 header. This checksum is defined in [RFC0791] as follows: 1292 Header Checksum: 16 bits 1294 A checksum on the header only. Since some header fields change 1295 (e.g., time to live), this is recomputed and verified at each 1296 point that the internet header is processed. 1298 The checksum algorithm is: 1300 The checksum field is the 16 bit one's complement of the one's 1301 complement sum of all 16 bit words in the header. For purposes 1302 of computing the checksum, the value of the checksum field is 1303 zero. 1305 As described above, the header checksum protects individual hops from 1306 processing a corrupted header. When almost all IP header information 1307 is compressed away, and when decompression is verified by a CRC 1308 computed over the original header for every compressed packet, there 1309 is no point in having this additional checksum; instead it can be 1310 recomputed at the decompressor side. 1312 The "inferred_ip_v4_header_checksum" encoding method thus compresses 1313 the IPv4 header checksum down to a size of zero bits. Using this 1314 encoding method, the decompressor infers the value of this field 1315 using the computation above. 1317 This encoding method implicitely assumes that the compressor will not 1318 process a corrupted header; otherwise it cannot guarantee that the 1319 checksum as recomputed by the decompressor will be bitwise identical 1320 to its original value before compression. 1322 6.4.2. inferred_mine_header_checksum 1324 This encoding method compresses the minimal encapsulation header 1325 checksum. This checksum is defined in [RFC2004] as follows: 1327 Header Checksum 1329 The 16-bit one's complement of the one's complement sum of all 1330 16-bit words in the minimal forwarding header. For purposes of 1331 computing the checksum, the value of the checksum field is 0. 1332 The IP header and IP payload (after the minimal forwarding 1333 header) are not included in this checksum computation. 1335 The "inferred_mine_header_checksum" encoding method compresses the 1336 minimal encapsulation header checksum down to a size of zero bit, 1337 i.e. no bits are transmitted in compressed headers for this field. 1338 Using this encoding method, the decompressor infers the value of this 1339 field using the above computation. 1341 The motivations and the assumptions for inferring this checksum are 1342 similar to the ones explained above in Section 6.4.1. 1344 6.4.3. inferred_ip_v4_length 1346 This encoding method compresses the total length field of the IPv4 1347 header. The total length field of the IPv4 header is defined in 1348 [RFC0791] as follows: 1350 Total Length: 16 bits 1352 Total Length is the length of the datagram, measured in octets, 1353 including internet header and data. This field allows the 1354 length of a datagram to be up to 65,535 octets. 1356 The "inferred_ip_v4_length" encoding method compresses the IPv4 1357 header checksum down to a size of zero bits. Using this encoding 1358 method, the decompressor infers the value of this field by counting 1359 in octets the length of the entire packet after decompression. 1361 6.4.4. inferred_ip_v6_length 1363 This encoding method compresses the payload length field in the IPv6 1364 header. This length field is defined in [RFC2460] as follows: 1366 Payload Length: 16-bit unsigned integer 1368 Length of the IPv6 payload, i.e., the rest of the packet 1369 following this IPv6 header, in octets. (Note that any 1370 extension headers present are considered part of the payload, 1371 i.e., included in the length count.) 1373 The "inferred_ip_v6_length" encoding method compresses the payload 1374 length field of the IPv6 header down to a size of zero bits. Using 1375 this encoding method, the decompressor infers the value of this field 1376 by counting in octets the length of the entire packet after 1377 decompression. 1379 6.4.5. inferred_offset 1381 This encoding method compresses the data offset field of the TCP 1382 header. 1384 The "inferred_offset" encoding method is used on the data offset 1385 field of the TCP header. This field is defined in [RFC0793] as: 1387 Data Offset: 4 bits 1389 The number of 32 bit words in the TCP Header. This indicates 1390 where the data begins. The TCP header (even one including 1391 options) is an integral number of 32 bits long. 1393 The "inferred_offset" encoding method compresses the data offset 1394 field of the TCP header down to a size of zero bits. Using this 1395 encoding method, the decompressor infers the value of this field by 1396 first decompressing the TCP options list, and by then setting: 1398 data offset = (options length / 4) + 5 1400 The equation above uses integer arithmetic. 1402 6.4.6. baseheader_extension_headers 1404 In CO packets (see Section 7.3), the innermost IP header and the TCP 1405 header are combined to create a compressed base header. In some 1406 cases the IP header will have a number of extension headers between 1407 itself and the TCP header. 1409 To remain formally correct, the base header must define some 1410 representation of these extension headers, which is what this 1411 encoding method is used for. This encoding method skips over all the 1412 extension headers and does not encode any of the fields. Changed 1413 fields in these headers are encoded in the irregular chain. 1415 6.4.7. baseheader_outer_headers 1417 This encoding method, as well as the baseheader_extension_headers 1418 encoding method described above, is needed for the specification to 1419 remain formally correct. It is used in CO packets (see Section 7.3) 1420 to describe tunneling IP headers and their respective extension 1421 headers (i.e. all headers located before the innermost IP header). 1423 This encoding method skips over all the fields in these headers and 1424 does not perform any encoding. Changed fields in outer headers are 1425 instead handled by the irregular chain. 1427 6.4.8. Scaled Encoding of Fields 1429 Some header fields will exhibit a change pattern where the field 1430 increases by a constant value or by multiples of the same value. 1432 Examples of fields that may have this behavior are the TCP Sequence 1433 Number and the TCP Acknowledgment Number. For such fields, ROHC-TCP 1434 provides the means to downscale the field value before applying LSB 1435 encoding, which allows the compressor to transmit fewer bits. 1437 To be able to use scaled encoding, the field is required to fulfill 1438 the following equation: 1440 unscaled_value = scaling_factor * scaled_value + residue 1442 To use the scaled encoding, the compressor must be confident that the 1443 decompressor has established values for the residue "residue" and the 1444 scaling factor "scaling_factor", so that it can correctly decompress 1445 the field when only an LSB-encoded "scaled_value" is present in the 1446 compressed packet. 1448 Once the compressor is confident that the value of the scaling_factor 1449 and the value of the residue have been established in the 1450 decompressor, the compressor may send compressed packets using the 1451 scaled representation of the field. The compressor MUST NOT use 1452 scaled encoding with the value of the scaling_factor set to zero. 1454 If the compressor detects that the value of the residue has changed, 1455 or if the compressor uses a different value for the scaling factor, 1456 it MUST NOT use scaled encoding until it is confident that the 1457 decompressor has received the new value(s) of these fields. 1459 When the unscaled value of the field wraps around, the value of the 1460 residue is likely to change, even if the scaling_factor remains 1461 constant. In such a case, the compressor must act in the same way as 1462 for any other change in the residue. 1464 The following subsections describe how the scaled encoding is applied 1465 to specific fields in ROHC-TCP, in particular how the scaling_factor 1466 and residue values are established for the different fields. 1468 6.4.8.1. Scaled TCP Sequence Number Encoding 1470 For some TCP flows, such as data transfers, the payload size will be 1471 constant over periods of time. For such flows, the TCP Sequence 1472 Number is bound to increase by multiples of the payload size between 1473 packets, which means that this field can be a suitable target for 1474 scaled encoding. When using this encoding, the payload size will be 1475 used as the scaling factor (i.e. as the value for scaling_factor) of 1476 this encoding. This means that the scaling factor does not need to 1477 be explicitly transmitted, but is instead inferred from the length of 1478 the payload in the compressed packet. 1480 Establishing scaling_factor: 1482 The scaling factor is established by sending unscaled TCP Sequence 1483 Number bits, so that the decompressor can infer the scaling_factor 1484 from the payload size. 1486 Establishing residue: 1488 The residue is established identically as the scaling_factor, i.e. 1489 by sending unscaled TCP Sequence Number bits. 1491 A detailed specification of how the TCP Sequence Number uses the 1492 scaled encoding can be found in the definitions of the packet 1493 formats, Section 8.2. 1495 6.4.8.2. Scaled Acknowledgment Number Encoding 1497 Similar to the pattern exhibited by the TCP Sequence Number, the 1498 expected increase in the TCP Acknowledgment Number is often constant 1499 and is therefore suitable for scaled encoding. 1501 For the TCP Acknowledgment Number, the scaling factor depends on the 1502 size of packets flowing in the opposite direction; this information 1503 might not be available to the compressor/decompressor pair. For this 1504 reason, ROHC-TCP uses an explicitly transmitted scaling factor to 1505 compress the TCP Acknowledgment Number. 1507 Establishing scaling_factor: 1509 The scaling factor is established by explicitly transmitting the 1510 value of the scaling factor (called ack_stride in the formal 1511 notation in Section 8.2) to the decompressor, using one of the 1512 packet types that can carry this information. 1514 Establishing residue: 1516 The scaling factor is established by sending unscaled TCP 1517 Acknowledgment Number bits, so that the decompressor can infer its 1518 value from the unscaled value and the scaling factor (ack_stride). 1520 A detailed specification of how the TCP Acknowledgment Number uses 1521 the scaled encoding can be found in the definitions of the packet 1522 formats, in Section 8.2. 1524 The compressor MAY use the scaled acknowledgment number encoding; 1525 what value it will use as the scaling factor is up to the compressor 1526 implementation. In the case where there is a co-located decompressor 1527 processing packets of the same TCP flow in the opposite direction, 1528 the scaling factor for the sequence number used for that flow can be 1529 used by the compressor to determine a suitable scaling factor for the 1530 TCP Acknowledgment number for this flow. 1532 6.5. Encoding Methods With External Parameters 1534 A number of encoding methods in Section 8.2 have one or more 1535 arguments for which the derivation of the parameter's value is 1536 outside the scope of the ROHC-FN specification of the header formats. 1537 This section lists the encoding methods together with a definition of 1538 each of their parameters. 1540 o esp_null(next_header_value): 1542 next_header_value: Set to the value of the Next Header field 1543 located in the ESP trailer, usually 12 octets from the end of 1544 the packet. Compression of null-encrypted ESP headers should 1545 only be performed when the compressor has prior knowledge of 1546 the exact location of the next header field. 1548 o ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn): 1550 is_innermost: This boolean flag is set to true when processing 1551 the innermost IP header; otherwise it is set to false. 1553 ttl_irregular_chain_flag: This parameter must be set to the 1554 value that was used for the corresponding 1555 "ttl_irregular_chain_flag" parameter of the "co_baseheader" 1556 encoding method (as defined below) when extracting the 1557 irregular chain for a compressed header; otherwise it is set to 1558 zero and ignored for other types of chains. 1560 ip_inner_ecn: This parameter is bound by the encoding method, 1561 and therefore it should be undefined when calling this encoding 1562 method. This value is then used to bind the corresponding 1563 parameter in the "tcp" encoding method, as its value is needed 1564 when processing the irregular chain for TCP. See the 1565 definition of the "ip_inner_ecn" parameter for the "tcp" 1566 encoding method below. 1568 o ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn): 1570 See definition of arguments for "ipv6" above. 1572 o tcp_opt_eol(nbits): 1574 nbits: This parameter is set to the length of the padding data 1575 located after the EOL option type octet to the end of the TCP 1576 options in the uncompressed header. 1578 o tcp_opt_sack(ack_value): 1580 ack_value: Set to the value of the Acknowledgment Number field 1581 of the TCP header. 1583 o tcp(payload_size, ack_stride_value, ip_inner_ecn): 1585 payload_size: Set to the length (in octets) of the payload 1586 following the TCP header. 1588 ack_stride_value: This parameter is the scaling factor used 1589 when scaling the TCP Acknowledgement Number. Its value is set 1590 by the compressor implementation. See Section 6.4.8.2 for 1591 recommendations on how to set this value. 1593 ip_inner_ecn: This parameter binds with the value given to the 1594 corresponding "ip_inner_ecn" parameter by the "ipv4" or the 1595 "ipv6" encoding method when processing the innermost IP header 1596 of this packet. See also the definition of the "ip_inner_ecn" 1597 parameter to the "ipv6" and "ipv4" encoding method above. 1599 o co_baseheader(payload_size, ack_stride_value, 1600 ttl_irregular_chain_flag): 1602 payload_size: Set to the length (in octets) of the payload 1603 following the TCP header. 1605 ack_stride_value: This parameter is the scaling factor used 1606 when scaling the TCP Acknowledgement Number. Its value is set 1607 by the compressor implementation. See Section 6.4.8.2 for 1608 recommendations on how to set this value. 1610 ttl_irregular_chain_flag: This parameter is set to 1 if the 1611 TTL/Hop Limit of an outer header has changed compared to its 1612 reference in the context, otherwise it is set to 0. The value 1613 used for this parameter is also used for the 1614 "ttl_irregular_chain_flag" argument for the "ipv4" or "ipv6" 1615 encoding methods when processing the irregular chain, as 1616 defined above for the "ipv6" and "ipv4" encoding methods. 1618 7. Packet Types (Normative) 1620 ROHC-TCP uses three different packet types: the Initialization and 1621 Refresh (IR) packet type, the Context Replication (IR-CR) packet type 1622 and the Compressed packet type (CO). 1624 Each packet type defines a number of packet formats: two packet 1625 formats are defined for the IR type, one packet format is defined for 1626 the IR-CR type and two sets of eight base header formats are defined 1627 for the CO type with one additional format that is common to both 1628 sets. 1630 The profile identifier for ROHC-TCP is 0x0006. 1632 7.1. Initialization and Refresh Packets (IR) 1634 ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets 1635 as defined in [I-D.ietf-rohc-rfc3095bis-framework] (section 5.2.2.1. 1636 and 5.2.2.2. respectively). 1638 Packet type: IR 1640 This packet type communicates the static part and the dynamic part 1641 of the context. 1643 For the ROHC-TCP IR packet, the value of the x bit MUST be set to 1644 one. It has the following format, which corresponds to the 1645 "Header" and "Payload" fields described in section 5.2.1 of 1646 [I-D.ietf-rohc-rfc3095bis-framework]: 1648 0 1 2 3 4 5 6 7 1649 --- --- --- --- --- --- --- --- 1650 : Add-CID octet : if for small CIDs and (CID != 0) 1651 +---+---+---+---+---+---+---+---+ 1652 | 1 1 1 1 1 1 0 1 | IR type octet 1653 +---+---+---+---+---+---+---+---+ 1654 : : 1655 / 0-2 octets of CID / 1-2 octets if for large CIDs 1656 : : 1657 +---+---+---+---+---+---+---+---+ 1658 | Profile = 0x06 | 1 octet 1659 +---+---+---+---+---+---+---+---+ 1660 | CRC | 1 octet 1661 +---+---+---+---+---+---+---+---+ 1662 | | 1663 / Static chain / variable length 1664 | | 1665 - - - - - - - - - - - - - - - - 1666 | | 1667 / Dynamic chain / variable length 1668 | | 1669 - - - - - - - - - - - - - - - - 1670 | | 1671 / Payload / variable length 1672 | | 1673 - - - - - - - - - - - - - - - - 1675 CRC: 8-bit CRC, computed according to section 5.3.1.1. of 1676 [I-D.ietf-rohc-rfc3095bis-framework]. The CRC covers the entire 1677 IR header, thus excluding payload, padding and feedback, if any. 1679 Static chain: See Section 6.2. 1681 Dynamic chain: See Section 6.2. 1683 Payload: The payload of the corresponding original packet, if any. 1684 The payload consists of all data after the last octet of the TCP 1685 header to end of the uncompressed packet. The presence of a 1686 payload is inferred from the packet length. 1688 Packet type: IR-DYN 1690 This packet type communicates the dynamic part of the context. 1691 The ROHC-TCP IR-DYN packet has the following format, which 1692 corresponds to the "Header" and "Payload" fields described in 1693 section 5.2.1 of [I-D.ietf-rohc-rfc3095bis-framework]: 1695 0 1 2 3 4 5 6 7 1696 --- --- --- --- --- --- --- --- 1697 : Add-CID octet : if for small CIDs and (CID != 0) 1698 +---+---+---+---+---+---+---+---+ 1699 | 1 1 1 1 1 0 0 0 | IR-DYN type octet 1700 +---+---+---+---+---+---+---+---+ 1701 : : 1702 / 0-2 octets of CID / 1-2 octets if for large CIDs 1703 : : 1704 +---+---+---+---+---+---+---+---+ 1705 | Profile = 0x06 | 1 octet 1706 +---+---+---+---+---+---+---+---+ 1707 | CRC | 1 octet 1708 +---+---+---+---+---+---+---+---+ 1709 | | 1710 / Dynamic chain / variable length 1711 | | 1712 - - - - - - - - - - - - - - - - 1713 | | 1714 / Payload / variable length 1715 | | 1716 - - - - - - - - - - - - - - - - 1718 CRC: 8-bit CRC, computed according to section 5.3.1.1. of 1719 [I-D.ietf-rohc-rfc3095bis-framework]. The CRC covers the entire 1720 IR-DYN header, thus excluding payload, padding and feedback, if 1721 any. 1723 Dynamic chain: See Section 6.2. 1725 Payload: The payload of the corresponding original packet, if any. 1726 The payload consists of all data after the last octet of the TCP 1727 header to end of the uncompressed packet. The presence of a 1728 payload is inferred from the packet length. 1730 7.2. Context Replication Packets (IR-CR) 1732 Context replication requires a dedicated IR packet format that 1733 uniquely identifies the IR-CR packet for the ROHC-TCP profile. This 1734 section defines the profile-specific part of the IR-CR packet 1735 [RFC4164]. 1737 Packet type: IR-CR 1738 This packet type communicates a reference to a base context along 1739 with the static and dynamic parts of the replicated context that 1740 differs from the base context. 1742 The ROHC-TCP IR-CR packet follows the general format of the ROHC CR 1743 packet, as defined in [RFC4164], section 3.4.2. With consideration 1744 to the extensibility of the IR packet type defined in 1745 [I-D.ietf-rohc-rfc3095bis-framework], the ROHC-TCP profile supports 1746 context replication through the profile specific part of the IR 1747 packet. This is achieved using the bit (x) left in the IR header for 1748 "Profile specific information". For ROHC-TCP, this bit is defined as 1749 a flag indicating whether this packet is an IR packet or an IR-CR 1750 packet. For the ROHC-TCP IR-CR packet, the value of the x bit MUST 1751 be set to zero. 1753 The ROHC-TCP IR-CR has the following format, which corresponds to the 1754 "Header" and "Payload" fields described in section 5.2.1 of 1755 [I-D.ietf-rohc-rfc3095bis-framework]: 1757 0 1 2 3 4 5 6 7 1758 --- --- --- --- --- --- --- --- 1759 : Add-CID octet : if for small CIDs and (CID != 0) 1760 +---+---+---+---+---+---+---+---+ 1761 | 1 1 1 1 1 1 0 0 | IR-CR type octet 1762 +---+---+---+---+---+---+---+---+ 1763 : : 1764 / 0-2 octets of CID / 1-2 octets if for large CIDs 1765 : : 1766 +---+---+---+---+---+---+---+---+ 1767 | Profile = 0x06 | 1 octet 1768 +---+---+---+---+---+---+---+---+ 1769 | CRC | 1 octet 1770 +---+---+---+---+---+---+---+---+ 1771 | B | CRC7 | 1 octet 1772 +---+---+---+---+---+---+---+---+ 1773 : Reserved | Base CID : 1 octet, for small CID, if B=1 1774 +---+---+---+---+---+---+---+---+ 1775 : : 1776 / Base CID / 1-2 octets, for large CIDs, 1777 : : if B=1 1778 +---+---+---+---+---+---+---+---+ 1779 | | 1780 / Replicate chain / variable length 1781 | | 1782 - - - - - - - - - - - - - - - - 1783 | | 1784 / Payload / variable length 1785 | | 1786 - - - - - - - - - - - - - - - - 1788 B: B = 1 indicates that the Base CID field is present. 1790 CRC: This CRC covers the entire IR-CR header, thus excluding 1791 payload, padding and feedback, if any. This 8-bit CRC is 1792 calculated according to section 5.3.1.1. of 1793 [I-D.ietf-rohc-rfc3095bis-framework]. 1795 CRC7: The CRC over the original, uncompressed, header. Calculated 1796 according to section 3.5.1.1. of [RFC4164]. 1798 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1799 discard the packet. 1801 Base CID: CID of base context. Encoded according to [RFC4164], 1802 Section 3.5.3. 1804 Replicate chain: See Section 6.2. 1806 Payload: The payload of the corresponding original packet, if any. 1807 The presence of a payload is inferred from the packet length. 1809 7.3. Compressed Packets (CO) 1811 The ROHC-TCP CO packets communicate irregularities in the packet 1812 header. All CO packets carry a CRC and can update the context. 1814 The general format for a compressed TCP header is as follows, which 1815 corresponds to the "Header" and "Payload" fields described in section 1816 5.2.1 of [I-D.ietf-rohc-rfc3095bis-framework]: 1818 0 1 2 3 4 5 6 7 1819 --- --- --- --- --- --- --- --- 1820 : Add-CID octet : if for small CIDs and CID 1-15 1821 +---+---+---+---+---+---+---+---+ 1822 | First octet of base header | (with type indication) 1823 +---+---+---+---+---+---+---+---+ 1824 : : 1825 / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 1826 : : 1827 +---+---+---+---+---+---+---+---+ 1828 / Remainder of base header / variable number of octets 1829 +---+---+---+---+---+---+---+---+ 1830 : Irregular chain : 1831 / (including irregular chain / variable 1832 : items for TCP options) : 1833 --- --- --- --- --- --- --- --- 1834 | | 1835 / Payload / variable length 1836 | | 1837 - - - - - - - - - - - - - - - - 1839 Base header: The complete set of base headers is defined in 1840 Section 8. 1842 Irregular chain: See Section 6.2 and Section 6.3.6. 1844 Payload: The payload of the corresponding original packet, if any. 1845 The presence of a payload is inferred from the packet length. 1847 8. Header Formats (Normative) 1849 This section describes the set of compressed TCP/IP packet formats. 1850 The normative description of the packet formats is given using the 1851 formal notation for ROHC profiles defined in 1852 [I-D.ietf-rohc-formal-notation]. The formal description of the 1853 packet formats specifies all of the information needed to compress 1854 and decompress a header relative to the context. 1856 In particular, the notation provides a list of all the fields present 1857 in the uncompressed and compressed TCP/IP headers, and defines how to 1858 map from each uncompressed packet to its compressed equivalent and 1859 vice versa. 1861 8.1. Design Rationale for Compressed Base Headers 1863 The compressed header formats are defined as two separate sets: one 1864 set for the packets where the innermost IP header contains a 1865 sequential IP-ID (either network byte order or byte swapped), and one 1866 set for the packets without sequential IP-ID (either random, zero, or 1867 no IP-ID). 1869 These two sets of header formats are referred to as the "sequential" 1870 and the "random" set of header formats, respectively. 1872 In addition, there is one compressed format that is common to both 1873 sets of header formats, and that can thus be used regardless of the 1874 type of IP-ID behavior. This format can transmit rarely changing 1875 fields and also send the frequently changing fields coded in variable 1876 lengths. It can also change the value of control fields such as 1877 IP-ID behavior and ECN behavior. 1879 All compressed base headers contain a 3-bit CRC, unless they update 1880 control fields such as "ip_id_behavior" or "ecn_used" that affect the 1881 interpretation of subsequent headers. Headers that can modify these 1882 control fields carry a 7-bit CRC instead. 1884 When discussing LSB-encoded fields below, "p" equals the 1885 "offset_param" and "k" equals the "num_lsbs_param" in 1886 [I-D.ietf-rohc-formal-notation]. 1888 The encoding methods used in the compressed base headers are based on 1889 the following design criteria: 1891 o MSN 1893 Since the MSN is a number generated by the compressor, it only 1894 needs to be large enough to ensure robust operation and to 1895 accommodate a small amount of reordering [RFC4163]. Therefore, 1896 each compressed base header has an MSN field that is LSB- 1897 encoded with k=4 and p=4 to handle a reordering depth of up to 1898 4 packets. Additional guidance to improve robustness when 1899 reordering is possible can be found in [RFC4224]. 1901 o TCP Sequence Number 1903 ROHC-TCP has the capability to handle bulk data transfers 1904 efficiently, for which the sequence number is expected to 1905 increase by about 1460 octets (which can be represented by 11 1906 bits). For the compressed base headers to handle 1907 retransmissions (i.e. negative delta to the sequence number), 1908 the LSB interpretation interval has to handle negative offsets 1909 about as large as positive offset, which means that one more 1910 bit is needed. 1912 Also, for ROHC-TCP to be robust to losses, two additional bits 1913 are added to the LSB encoding of the sequence number. This 1914 means that the base headers should contain at least 14 bits of 1915 LSB-encoded sequence number when present. According to the 1916 logic above, the LSB offset value is set to be as large as the 1917 positive offset, i.e. p = 2^(k-1)-1. 1919 o TCP Acknowledgment Number 1921 The design criterion for the acknowledgment number is similar 1922 to that of the TCP Sequence Number. However, often only every 1923 other data packet is acknowledged, which means that the 1924 expected delta value is twice as large as for sequence numbers. 1925 Therefore, at least 15 bits of acknowledgment number should be 1926 used in compressed base headers. Since the acknowledgment 1927 number is expected to constantly increase, and the only 1928 exception to this is packet reordering (either on the ROHC 1929 channel [RFC3759] or prior to the compression point), the 1930 negative offset for LSB encoding is set to be 1/4 of the total 1931 interval, i.e. p = 2^(k-2)-1. 1933 o TCP Window 1935 The TCP Window field is expected to increase in increments of 1936 similar size as the TCP Sequence Number, and therefore the 1937 design criterion for the TCP window is to send at least 14 bits 1938 when used. 1940 o IP-ID 1942 For the "sequential" set of packet formats, all the compressed 1943 base headers contains LSB encoded IP-ID offset bits, where the 1944 offset is the difference between the value of the MSN and the 1945 value of the IP-ID field. The requirement is that at least 3 1946 bits of IP-ID should always be present, but it is preferable to 1947 use 4 to 7 bits. When k=3 then p=1, and if k>3 then p=3 since 1948 the offset is expected to increase most of the time. 1950 Each set of header formats contains eight different compressed base 1951 headers. The reason for having this large number of header formats 1952 is that the TCP Sequence Number, TCP Acknowledgment Number and TCP 1953 Window are frequently changing in a non-linear pattern. 1955 The design of the header formats is derived from the field behavior 1956 analysis found in [RFC4413]. 1958 All of the compressed base headers transmit LSB-encoded MSN bits, the 1959 TCP Push flag and a CRC, and in addition to this, all the base 1960 headers in the sequential packet format set contains LSB encoded 1961 IP-ID bits. 1963 The following header formats exist in both the sequential and random 1964 packet format sets: 1966 o Format 1: This header format carries changes to the TCP Sequence 1967 number and is expected to be used on the downstream of a data 1968 transfer. 1970 o Format 2: This header format carries the TCP Sequence number in 1971 scaled form, and is expected to be useful for the downstream of a 1972 data transfer where the payload size is constant for multiple 1973 packets. 1975 o Format 3: This header format carries changes in the TCP 1976 Acknowledgment number, and is expected to be useful for the 1977 acknowledgment direction of a data transfer. 1979 o Format 4: This header format is similar to format 3, but carries a 1980 scaled TCP Acknowledgment Number. 1982 o Format 5: This header format carries both the TCP sequence Number 1983 and the TCP Acknowledgment Number, and is expected to be useful 1984 for flows that send data in both directions. 1986 o Format 6: This header format is similar to format 5, but carries 1987 the TCP Sequence Number in scaled form, when the payload size is 1988 static for certain intervals in a data flow. 1990 o Format 7: This header format carries changes to both the TCP 1991 Acknowledgment Number and the TCP Window, and is expected to be 1992 useful for the acknowledgment flows of data connections. 1994 o Format 8: This header format is used to convey changes to some of 1995 the more seldom changing fields in the TCP flow, such as ECN 1996 behavior, RST/SYN/FIN flags, the TTL/Hop Limit and the TCP options 1997 list. This format carries a 7-bit CRC, since it can change the 1998 structure of the contents of the irregular chain for subsequent 1999 packets. Note that this can be seen as a reduced form of the 2000 common packet format. 2002 o Common header format: The common header format can be used for all 2003 kinds of IP-ID behavior, and should be useful when some of the 2004 more rarely changing fields in the IP or TCP header changes. 2005 Since this header format can update control fields that decide how 2006 the decompressor interprets packets, it carries a 7-bit CRC to 2007 reduce the probability of context corruption. This header can 2008 basically convey changes to any of the dynamic fields in the IP 2009 and TCP header, and it uses a large set of flags to provide 2010 information about which fields are present in the header format. 2012 8.2. Formal Definition of Header Formats 2014 //////////////////////////////////////////// 2015 // Constants 2016 //////////////////////////////////////////// 2018 IP_ID_BEHAVIOR_SEQUENTIAL = 0; 2019 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; 2020 IP_ID_BEHAVIOR_RANDOM = 2; 2021 IP_ID_BEHAVIOR_ZERO = 3; 2023 //////////////////////////////////////////// 2024 // Global control fields 2025 //////////////////////////////////////////// 2027 CONTROL { 2028 ecn_used [ 1 ]; 2029 msn [ 16 ]; 2030 } 2032 /////////////////////////////////////////////// 2033 // Encoding methods not specified in FN syntax: 2034 /////////////////////////////////////////////// 2036 list_tcp_options "defined in Section 6.3.3"; 2037 inferred_ip_v4_header_checksum "defined in Section 6.4.1"; 2038 inferred_mine_header_checksum "defined in Section 6.4.2"; 2039 inferred_ip_v4_length "defined in Section 6.4.3"; 2040 inferred_ip_v6_length "defined in Section 6.4.4"; 2041 inferred_offset "defined in Section 6.4.5"; 2042 baseheader_extension_headers "defined in Section 6.4.6"; 2043 baseheader_outer_headers "defined in Section 6.4.7"; 2045 //////////////////////////////////////////// 2046 // General encoding methods 2047 //////////////////////////////////////////// 2049 static_or_irreg(flag, width) 2050 { 2051 UNCOMPRESSED { 2052 field [ width ]; 2053 } 2054 COMPRESSED irreg_enc { 2055 field =:= irregular(width) [ width ]; 2056 ENFORCE(flag == 1); 2057 } 2059 COMPRESSED static_enc { 2060 field =:= static [ 0 ]; 2061 ENFORCE(flag == 0); 2062 } 2063 } 2065 zero_or_irreg(flag, width) 2066 { 2067 UNCOMPRESSED { 2068 field [ width ]; 2069 } 2071 COMPRESSED non_zero { 2072 field =:= irregular(width) [ width ]; 2073 ENFORCE(flag == 0); 2074 } 2076 COMPRESSED zero { 2077 field =:= uncompressed_value(width, 0) [ 0 ]; 2078 ENFORCE(flag == 1); 2079 } 2080 } 2082 variable_length_32_enc(flag) 2083 { 2084 UNCOMPRESSED { 2085 field [ 32 ]; 2086 } 2088 COMPRESSED not_present { 2089 field =:= static [ 0 ]; 2090 ENFORCE(flag == 0); 2091 } 2093 COMPRESSED lsb_8_bit { 2094 field =:= lsb(8, 63) [ 8 ]; 2095 ENFORCE(flag == 1); 2096 } 2098 COMPRESSED lsb_16_bit { 2099 field =:= lsb(16, 16383) [ 16 ]; 2100 ENFORCE(flag == 2); 2101 } 2102 COMPRESSED irreg_32_bit { 2103 field =:= irregular(32) [ 32 ]; 2104 ENFORCE(flag == 3); 2105 } 2106 } 2108 optional32(flag) 2109 { 2110 UNCOMPRESSED { 2111 item [ 0, 32 ]; 2112 } 2114 COMPRESSED present { 2115 item =:= irregular(32) [ 32 ]; 2116 ENFORCE(flag == 1); 2117 } 2119 COMPRESSED not_present { 2120 item =:= compressed_value(0, 0) [ 0 ]; 2121 ENFORCE(flag == 0); 2122 } 2123 } 2125 lsb_7_or_31 2126 { 2127 UNCOMPRESSED { 2128 item [ 32 ]; 2129 } 2131 COMPRESSED lsb_7 { 2132 discriminator =:= '0' [ 1 ]; 2133 item =:= lsb(7, 8) [ 7 ]; 2134 } 2136 COMPRESSED lsb_31 { 2137 discriminator =:= '1' [ 1 ]; 2138 item =:= lsb(31, 256) [ 31 ]; 2139 } 2140 } 2142 opt_lsb_7_or_31(flag) 2143 { 2144 UNCOMPRESSED { 2145 item [ 0, 32 ]; 2146 } 2148 COMPRESSED present { 2149 item =:= lsb_7_or_31 [ 8, 32 ]; 2150 ENFORCE(flag == 1); 2151 } 2153 COMPRESSED not_present { 2154 item =:= compressed_value(0, 0) [ 0 ]; 2155 ENFORCE(flag == 0); 2156 } 2157 } 2159 crc3(data_value, data_length) 2160 { 2161 UNCOMPRESSED { 2162 } 2164 COMPRESSED { 2165 crc_value =:= 2166 crc(3, 0x06, 0x07, data_value, data_length) [ 3 ]; 2167 } 2168 } 2170 crc7(data_value, data_length) 2171 { 2172 UNCOMPRESSED { 2173 } 2175 COMPRESSED { 2176 crc_value =:= 2177 crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ]; 2178 } 2179 } 2181 one_bit_choice 2182 { 2183 UNCOMPRESSED { 2184 field [ 1 ]; 2185 } 2187 COMPRESSED zero { 2188 field [ 1 ]; 2189 ENFORCE(field.UVALUE == 0); 2190 } 2192 COMPRESSED nonzero { 2193 field [ 1 ]; 2194 ENFORCE(field.UVALUE == 1); 2195 } 2196 } 2197 // Encoding method for updating a scaled field and its associated 2198 // control fields. Should be used both when the value is scaled 2199 // or unscaled in a compressed format. 2200 field_scaling(stride_value, scaled_value, unscaled_value) 2201 { 2202 UNCOMPRESSED { 2203 residue_field [ 32 ]; 2204 } 2206 COMPRESSED no_scaling { 2207 ENFORCE(stride_value == 0); 2208 ENFORCE(residue_field.UVALUE == unscaled_value); 2209 ENFORCE(scaled_value == 0); 2210 } 2212 COMPRESSED scaling_used { 2213 ENFORCE(stride_value != 0); 2214 ENFORCE(residue_field.UVALUE == (unscaled_value % stride_value)); 2215 ENFORCE(unscaled_value == 2216 scaled_value * stride_value + residue_field.UVALUE); 2217 } 2218 } 2220 //////////////////////////////////////////// 2221 // IPv6 Destination options header 2222 //////////////////////////////////////////// 2224 ip_dest_opt 2225 { 2226 UNCOMPRESSED { 2227 next_header [ 8 ]; 2228 length [ 8 ]; 2229 value [ length.UVALUE * 64 + 48 ]; 2230 } 2232 DEFAULT { 2233 length =:= static; 2234 next_header =:= static; 2235 value =:= static; 2236 } 2238 COMPRESSED dest_opt_static { 2239 next_header =:= irregular(8) [ 8 ]; 2240 length =:= irregular(8) [ 8 ]; 2241 } 2243 COMPRESSED dest_opt_dynamic { 2244 value =:= 2245 irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; 2246 } 2248 COMPRESSED dest_opt_0_replicate { 2249 discriminator =:= '00000000' [ 8 ]; 2250 } 2252 COMPRESSED dest_opt_1_replicate { 2253 discriminator =:= '10000000' [ 8 ]; 2254 length =:= irregular(8) [ 8 ]; 2255 value =:= 2256 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2257 } 2259 COMPRESSED dest_opt_irregular { 2260 } 2261 } 2263 //////////////////////////////////////////// 2264 // IPv6 Hop-by-Hop options header 2265 //////////////////////////////////////////// 2267 ip_hop_opt 2268 { 2269 UNCOMPRESSED { 2270 next_header [ 8 ]; 2271 length [ 8 ]; 2272 value [ length.UVALUE * 64 + 48 ]; 2273 } 2275 DEFAULT { 2276 length =:= static; 2277 next_header =:= static; 2278 value =:= static; 2279 } 2281 COMPRESSED hop_opt_static { 2282 next_header =:= irregular(8) [ 8 ]; 2283 length =:= irregular(8) [ 8 ]; 2284 } 2286 COMPRESSED hop_opt_dynamic { 2287 value =:= 2288 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2289 } 2291 COMPRESSED hop_opt_0_replicate { 2292 discriminator =:= '00000000' [ 8 ]; 2294 } 2296 COMPRESSED hop_opt_1_replicate { 2297 discriminator =:= '10000000' [ 8 ]; 2298 length =:= irregular(8) [ 8 ]; 2299 value =:= 2300 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2301 } 2303 COMPRESSED hop_opt_irregular { 2304 } 2305 } 2307 //////////////////////////////////////////// 2308 // IPv6 Routing header 2309 //////////////////////////////////////////// 2311 ip_rout_opt 2312 { 2313 UNCOMPRESSED { 2314 next_header [ 8 ]; 2315 length [ 8 ]; 2316 value [ length.UVALUE * 64 + 48 ]; 2317 } 2319 DEFAULT { 2320 length =:= static; 2321 next_header =:= static; 2322 value =:= static; 2323 } 2325 COMPRESSED rout_opt_static { 2326 next_header =:= irregular(8) [ 8 ]; 2327 length =:= irregular(8) [ 8 ]; 2328 value =:= 2329 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2330 } 2332 COMPRESSED rout_opt_dynamic { 2333 } 2335 COMPRESSED rout_opt_0_replicate { 2336 discriminator =:= '00000000' [ 8 ]; 2337 } 2339 COMPRESSED rout_opt_0_replicate { 2340 discriminator =:= '10000000' [ 8 ]; 2341 length =:= irregular(8) [ 8 ]; 2342 value =:= 2343 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2344 } 2346 COMPRESSED rout_opt_irregular { 2347 } 2348 } 2350 //////////////////////////////////////////// 2351 // GRE Header 2352 //////////////////////////////////////////// 2354 optional_checksum(flag_value) 2355 { 2356 UNCOMPRESSED { 2357 value [ 0, 16 ]; 2358 reserved1 [ 0, 16 ]; 2359 } 2361 COMPRESSED cs_present { 2362 value =:= irregular(16) [ 16 ]; 2363 reserved1 =:= uncompressed_value(16, 0) [ 0 ]; 2364 ENFORCE(flag_value == 1); 2365 } 2367 COMPRESSED not_present { 2368 value =:= compressed_value(0, 0) [ 0 ]; 2369 reserved1 =:= compressed_value(0, 0) [ 0 ]; 2370 ENFORCE(flag_value == 0); 2371 } 2372 } 2374 gre_proto 2375 { 2376 UNCOMPRESSED { 2377 protocol [ 16 ]; 2378 } 2380 COMPRESSED ether_v4 { 2381 discriminator =:= compressed_value(1, 0) [ 1 ]; 2382 protocol =:= uncompressed_value(16, 0x0800) [ 0 ]; 2383 } 2385 COMPRESSED ether_v6 { 2386 discriminator =:= compressed_value(1, 1) [ 1 ]; 2387 protocol =:= uncompressed_value(16, 0x86DD) [ 0 ]; 2388 } 2389 } 2390 gre 2391 { 2392 UNCOMPRESSED { 2393 c_flag [ 1 ]; 2394 r_flag =:= uncompressed_value(1, 0) [ 1 ]; 2395 k_flag [ 1 ]; 2396 s_flag [ 1 ]; 2397 reserved0 =:= uncompressed_value(9, 0) [ 9 ]; 2398 version =:= uncompressed_value(3, 0) [ 3 ]; 2399 protocol [ 16 ]; 2400 checksum_and_res [ 0, 32 ]; 2401 key [ 0, 32 ]; 2402 sequence_number [ 0, 32 ]; 2403 } 2405 DEFAULT { 2406 c_flag =:= static; 2407 k_flag =:= static; 2408 s_flag =:= static; 2409 protocol =:= static; 2410 key =:= static; 2411 sequence_number =:= static; 2412 } 2414 COMPRESSED gre_static { 2415 protocol =:= gre_proto [ 1 ]; 2416 c_flag =:= irregular(1) [ 1 ]; 2417 k_flag =:= irregular(1) [ 1 ]; 2418 s_flag =:= irregular(1) [ 1 ]; 2419 padding =:= compressed_value(4, 0) [ 4 ]; 2420 key =:= optional32(k_flag.UVALUE) [ 0, 32 ]; 2421 } 2423 COMPRESSED gre_dynamic { 2424 checksum_and_res =:= 2425 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2426 sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ]; 2427 } 2429 COMPRESSED gre_0_replicate { 2430 discriminator =:= '00000000' [ 8 ]; 2431 checksum_and_res =:= 2432 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2433 sequence_number =:= 2434 optional32(s_flag.UVALUE) [ 0, 8, 32 ]; 2435 } 2437 COMPRESSED gre_1_replicate { 2438 discriminator =:= '10000' [ 5 ]; 2439 c_flag =:= irregular(1) [ 1 ]; 2440 k_flag =:= irregular(1) [ 1 ]; 2441 s_flag =:= irregular(1) [ 1 ]; 2442 checksum_and_res =:= 2443 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2444 key =:= optional32(k_flag.UVALUE) [ 0, 32 ]; 2445 sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ]; 2446 } 2448 COMPRESSED gre_irregular { 2449 checksum_and_res =:= 2450 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2451 sequence_number =:= 2452 opt_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ]; 2453 } 2454 } 2456 ///////////////////////////////////////////// 2457 // MINE header 2458 ///////////////////////////////////////////// 2460 mine 2461 { 2462 UNCOMPRESSED { 2463 next_header [ 8 ]; 2464 s_bit [ 1 ]; 2465 res_bits [ 7 ]; 2466 checksum [ 16 ]; 2467 orig_dest [ 32 ]; 2468 orig_src [ 0, 32 ]; 2469 } 2471 DEFAULT { 2472 next_header =:= static; 2473 s_bit =:= static; 2474 res_bits =:= static; 2475 checksum =:= inferred_mine_header_checksum; 2476 orig_dest =:= static; 2477 orig_src =:= static; 2478 } 2480 COMPRESSED mine_static { 2481 next_header =:= irregular(8) [ 8 ]; 2482 s_bit =:= irregular(1) [ 1 ]; 2483 // Reserved bits are included to achieve byte-alignment 2484 res_bits =:= irregular(7) [ 7 ]; 2485 orig_dest =:= irregular(32) [ 32 ]; 2486 orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ]; 2487 } 2489 COMPRESSED mine_dynamic { 2490 } 2492 COMPRESSED mine_0_replicate { 2493 discriminator =:= '00000000' [ 8 ]; 2494 } 2496 COMPRESSED mine_1_replicate { 2497 discriminator =:= '10000000' [ 8 ]; 2498 s_bit =:= irregular(1) [ 1 ]; 2499 res_bits =:= irregular(7) [ 7 ]; 2500 orig_dest =:= irregular(32) [ 32 ]; 2501 orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ]; 2502 } 2504 COMPRESSED mine_irregular { 2505 } 2506 } 2508 ///////////////////////////////////////////// 2509 // Authentication Header (AH) 2510 ///////////////////////////////////////////// 2512 ah 2513 { 2514 UNCOMPRESSED { 2515 next_header [ 8 ]; 2516 length [ 8 ]; 2517 res_bits [ 16 ]; 2518 spi [ 32 ]; 2519 sequence_number [ 32 ]; 2520 auth_data [ length.UVALUE*32-32 ]; 2521 } 2523 DEFAULT { 2524 next_header =:= static; 2525 length =:= static; 2526 res_bits =:= static; 2527 spi =:= static; 2528 sequence_number =:= static; 2529 } 2531 COMPRESSED ah_static { 2532 next_header =:= irregular(8) [ 8 ]; 2533 length =:= irregular(8) [ 8 ]; 2534 spi =:= irregular(32) [ 32 ]; 2535 } 2537 COMPRESSED ah_dynamic { 2538 res_bits =:= irregular(16) [ 16 ]; 2539 sequence_number =:= irregular(32) [ 32 ]; 2540 auth_data =:= 2541 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2542 } 2544 COMPRESSED ah_0_replicate { 2545 discriminator =:= '00000000' [ 8 ]; 2546 sequence_number =:= irregular(32) [ 32 ]; 2547 auth_data =:= 2548 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2549 } 2551 COMPRESSED ah_1_replicate { 2552 discriminator =:= '10000000' [ 8 ]; 2553 length =:= irregular(8) [ 8 ]; 2554 res_bits =:= irregular(16) [ 16 ]; 2555 spi =:= irregular(32) [ 32 ]; 2556 sequence_number =:= irregular(32) [ 32 ]; 2557 auth_data =:= 2558 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2559 } 2561 COMPRESSED ah_irregular { 2562 sequence_number =:= lsb_7_or_31 [ 8, 32 ]; 2563 auth_data =:= 2564 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2565 } 2566 } 2568 ///////////////////////////////////////////// 2569 // ESP header (NULL encrypted) 2570 ///////////////////////////////////////////// 2572 // The value of the next header field from the trailer 2573 // part of the packet is passed as a parameter. 2574 esp_null(next_header_value) 2575 { 2576 UNCOMPRESSED { 2577 spi [ 32 ]; 2578 sequence_number [ 32 ]; 2579 } 2581 CONTROL { 2582 nh_field [ 8 ]; 2583 } 2585 DEFAULT { 2586 spi =:= static; 2587 sequence_number =:= static; 2588 nh_field =:= static; 2589 } 2591 COMPRESSED esp_static { 2592 nh_field =:= compressed_value(8, next_header_value) [ 8 ]; 2593 spi =:= irregular(32) [ 32 ]; 2594 } 2596 COMPRESSED esp_dynamic { 2597 sequence_number =:= irregular(32) [ 32 ]; 2598 } 2600 COMPRESSED esp_0_replicate { 2601 discriminator =:= '00000000' [ 8 ]; 2602 sequence_number =:= irregular(32) [ 32 ]; 2603 } 2605 COMPRESSED esp_1_replicate { 2606 discriminator =:= '10000000' [ 8 ]; 2607 spi =:= irregular(32) [ 32 ]; 2608 sequence_number =:= irregular(32) [ 32 ]; 2609 } 2611 COMPRESSED esp_irregular { 2612 sequence_number =:= lsb_7_or_31 [ 8, 32 ]; 2613 } 2614 } 2616 ///////////////////////////////////////////// 2617 // IPv6 Header 2618 ///////////////////////////////////////////// 2620 fl_enc 2621 { 2622 UNCOMPRESSED { 2623 flow_label [ 20 ]; 2624 } 2626 COMPRESSED fl_zero { 2627 discriminator =:= '0' [ 1 ]; 2628 flow_label =:= uncompressed_value(20, 0) [ 0 ]; 2629 reserved =:= '0000' [ 4 ]; 2631 } 2633 COMPRESSED fl_non_zero { 2634 discriminator =:= '1' [ 1 ]; 2635 flow_label =:= irregular(20) [ 20 ]; 2636 } 2637 } 2639 // The is_innermost flag is true if this is the innermost IP header 2640 // If extracting the irregular chain for an compressed packet: 2641 // - ttl_irregular_chain_flag must have the same value as it had when 2642 // processing co_baseheader. 2643 // - ip_inner_ecn is bound in this encoding method and the value that 2644 // it gets bound to should be passed to the tcp encoding method 2645 // For other formats than the irregular chain, these two are ignored 2646 ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn) 2647 { 2648 UNCOMPRESSED { 2649 version =:= uncompressed_value(4, 6) [ 4 ]; 2650 dscp [ 6 ]; 2651 ip_ecn_flags [ 2 ]; 2652 flow_label [ 20 ]; 2653 payload_length [ 16 ]; 2654 next_header [ 8 ]; 2655 ttl_hopl [ 8 ]; 2656 src_addr [ 128 ]; 2657 dst_addr [ 128 ]; 2658 } 2660 DEFAULT { 2661 dscp =:= static; 2662 ip_ecn_flags =:= static; 2663 flow_label =:= static; 2664 payload_length =:= inferred_ip_v6_length; 2665 next_header =:= static; 2666 ttl_hopl =:= static; 2667 src_addr =:= static; 2668 dst_addr =:= static; 2669 } 2671 COMPRESSED ipv6_static { 2672 version_flag =:= '1' [ 1 ]; 2673 reserved =:= '00' [ 2 ]; 2674 flow_label =:= fl_enc [ 5, 21 ]; 2675 next_header =:= irregular(8) [ 8 ]; 2676 src_addr =:= irregular(128) [ 128 ]; 2677 dst_addr =:= irregular(128) [ 128 ]; 2678 } 2679 COMPRESSED ipv6_dynamic { 2680 dscp =:= irregular(6) [ 6 ]; 2681 ip_ecn_flags =:= irregular(2) [ 2 ]; 2682 ttl_hopl =:= irregular(8) [ 8 ]; 2683 } 2685 COMPRESSED ipv6_replicate { 2686 dscp =:= irregular(6) [ 6 ]; 2687 ip_ecn_flags =:= irregular(2) [ 2 ]; 2688 reserved =:= '000' [ 3 ]; 2689 flow_label =:= fl_enc [ 5, 21 ]; 2690 } 2692 COMPRESSED ipv6_outer_without_ttl_irregular { 2693 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2694 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2695 ENFORCE(ttl_irregular_chain_flag == 0); 2696 ENFORCE(is_innermost == false); 2697 } 2699 COMPRESSED ipv6_outer_with_ttl_irregular { 2700 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2701 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2702 ttl_hopl =:= irregular(8) [ 8 ]; 2703 ENFORCE(ttl_irregular_chain_flag == 1); 2704 ENFORCE(is_innermost == false); 2705 } 2707 COMPRESSED ipv6_innermost_irregular { 2708 ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE); 2709 ENFORCE(is_innermost == true); 2710 } 2711 } 2713 ///////////////////////////////////////////// 2714 // IPv4 Header 2715 ///////////////////////////////////////////// 2717 ip_id_enc_dyn(behavior) 2718 { 2719 UNCOMPRESSED { 2720 ip_id [ 16 ]; 2721 } 2723 COMPRESSED ip_id_seq { 2724 ip_id =:= irregular(16) [ 16 ]; 2725 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 2726 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED) || 2727 (behavior == IP_ID_BEHAVIOR_RANDOM)); 2728 } 2730 COMPRESSED ip_id_zero { 2731 ip_id =:= uncompressed_value(16, 0) [ 0 ]; 2732 ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); 2733 } 2734 } 2736 ip_id_enc_irreg(behavior) 2737 { 2738 UNCOMPRESSED { 2739 ip_id [ 16 ]; 2740 } 2742 COMPRESSED ip_id_seq { 2743 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 2744 } 2746 COMPRESSED ip_id_seq_swapped { 2747 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 2748 } 2750 COMPRESSED ip_id_rand { 2751 ip_id =:= irregular(16) [ 16 ]; 2752 ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); 2753 } 2755 COMPRESSED ip_id_zero { 2756 ip_id =:= uncompressed_value(16, 0) [ 0 ]; 2757 ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); 2758 } 2759 } 2761 ip_id_behavior_choice(is_inner) 2762 { 2763 UNCOMPRESSED { 2764 behavior [ 2 ]; 2765 } 2767 DEFAULT { 2768 behavior =:= irregular(2); 2769 } 2771 COMPRESSED sequential { 2772 behavior [ 2 ]; 2773 ENFORCE(is_inner == true); 2774 ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL); 2776 } 2778 COMPRESSED sequential_swapped { 2779 behavior [ 2 ]; 2780 ENFORCE(is_inner == true); 2781 ENFORCE(behavior.UVALUE == 2782 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 2783 } 2785 COMPRESSED random { 2786 behavior [ 2 ]; 2787 ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); 2788 } 2790 COMPRESSED zero { 2791 behavior [ 2 ]; 2792 ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_ZERO); 2793 } 2794 } 2796 // The is_innermost flag is true if this is the innermost IP header 2797 // If extracting the irregular chain for an compressed packet: 2798 // - ttl_irregular_chain_flag must have the same value as it had when 2799 // processing co_baseheader. 2800 // - ip_inner_ecn is bound in this encoding method and the value that 2801 // it gets bound to should be passed to the tcp encoding method 2802 // For other formats than the irregular chain, these two are ignored 2803 ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn) 2804 { 2805 UNCOMPRESSED { 2806 version =:= uncompressed_value(4, 4) [ 4 ]; 2807 hdr_length =:= uncompressed_value(4, 5) [ 4 ]; 2808 dscp [ 6 ]; 2809 ip_ecn_flags [ 2 ]; 2810 length [ 16 ]; 2811 ip_id [ 16 ]; 2812 rf =:= uncompressed_value(1, 0) [ 1 ]; 2813 df [ 1 ]; 2814 mf =:= uncompressed_value(1, 0) [ 1 ]; 2815 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 2816 ttl_hopl [ 8 ]; 2817 protocol [ 8 ]; 2818 checksum [ 16 ]; 2819 src_addr [ 32 ]; 2820 dst_addr [ 32 ]; 2821 } 2823 CONTROL { 2824 ip_id_behavior [ 2 ]; 2825 } 2827 DEFAULT { 2828 dscp =:= static; 2829 ip_ecn_flags =:= static; 2830 length =:= inferred_ip_v4_length; 2831 df =:= static; 2832 ttl_hopl =:= static; 2833 protocol =:= static; 2834 checksum =:= inferred_ip_v4_header_checksum; 2835 src_addr =:= static; 2836 dst_addr =:= static; 2837 ip_id_behavior =:= static; 2838 } 2840 COMPRESSED ipv4_static { 2841 version_flag =:= '0' [ 1 ]; 2842 reserved =:= '0000000' [ 7 ]; 2843 protocol =:= irregular(8) [ 8 ]; 2844 src_addr =:= irregular(32) [ 32 ]; 2845 dst_addr =:= irregular(32) [ 32 ]; 2846 } 2848 COMPRESSED ipv4_dynamic { 2849 reserved =:= '00000' [ 5 ]; 2850 df =:= irregular(1) [ 1 ]; 2851 ip_id_behavior =:= ip_id_behavior_choice(is_innermost) [ 2 ]; 2852 dscp =:= irregular(6) [ 6 ]; 2853 ip_ecn_flags =:= irregular(2) [ 2 ]; 2854 ttl_hopl =:= irregular(8) [ 8 ]; 2855 ip_id =:= 2856 ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ]; 2857 } 2859 COMPRESSED ipv4_replicate { 2860 reserved =:= '0000' [ 4 ]; 2861 ip_id_behavior =:= ip_id_behavior_choice(is_innermost) [ 2 ]; 2862 ttl_flag =:= irregular(1) [ 1 ]; 2863 df =:= irregular(1) [ 1 ]; 2864 dscp =:= irregular(6) [ 6 ]; 2865 ip_ecn_flags =:= irregular(2) [ 2 ]; 2866 ip_id =:= 2867 ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ]; 2868 ttl_hopl =:= 2869 static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ]; 2870 } 2871 COMPRESSED ipv4_outer_without_ttl_irregular { 2872 ip_id =:= 2873 ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ]; 2874 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2875 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2876 ENFORCE(ttl_irregular_chain_flag == 0); 2877 ENFORCE(is_innermost == false); 2878 } 2880 COMPRESSED ipv4_outer_with_ttl_irregular { 2881 ip_id =:= 2882 ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ]; 2883 dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; 2884 ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; 2885 ttl_hopl =:= irregular(8) [ 8 ]; 2886 ENFORCE(is_innermost == false); 2887 ENFORCE(ttl_irregular_chain_flag == 1); 2888 } 2890 COMPRESSED ipv4_innermost_irregular { 2891 ip_id =:= 2892 ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ]; 2893 ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE); 2894 ENFORCE(is_innermost == true); 2895 } 2896 } 2898 ///////////////////////////////////////////// 2899 // TCP Options 2900 ///////////////////////////////////////////// 2902 // nbits is bound to the remaining length (in bits) of TCP 2903 // oPtions, including the EOL type byte. 2904 tcp_opt_eol(nbits) 2905 { 2906 UNCOMPRESSED { 2907 type =:= uncompressed_value(8, 0) [ 8 ]; 2908 padding =:= 2909 uncompressed_value(nbits-8, 0) [ nbits-8 ]; 2910 } 2912 CONTROL { 2913 pad_len [ 8 ]; 2914 } 2916 COMPRESSED eol_list_item { 2917 pad_len =:= compressed_value(8, nbits-8) [ 8 ]; 2918 } 2919 COMPRESSED eol_irregular { 2920 pad_len =:= static; 2921 ENFORCE(nbits-8 == pad_len.UVALUE); 2922 } 2923 } 2925 tcp_opt_nop 2926 { 2927 UNCOMPRESSED { 2928 type =:= uncompressed_value(8, 1) [ 8 ]; 2929 } 2931 COMPRESSED nop_list_item { 2932 } 2934 COMPRESSED nop_irregular { 2935 } 2936 } 2938 tcp_opt_mss 2939 { 2940 UNCOMPRESSED { 2941 type =:= uncompressed_value(8, 2) [ 8 ]; 2942 length =:= uncompressed_value(8, 4) [ 8 ]; 2943 mss [ 16 ]; 2944 } 2946 COMPRESSED mss_list_item { 2947 mss =:= irregular(16) [ 16 ]; 2948 } 2950 COMPRESSED mss_irregular { 2951 mss =:= static; 2952 } 2953 } 2955 tcp_opt_wscale 2956 { 2957 UNCOMPRESSED { 2958 type =:= uncompressed_value(8, 3) [ 8 ]; 2959 length =:= uncompressed_value(8, 3) [ 8 ]; 2960 wscale [ 8 ]; 2961 } 2963 COMPRESSED wscale_list_item { 2964 wscale =:= irregular(8) [ 8 ]; 2965 } 2966 COMPRESSED wscale_irregular { 2967 wscale =:= static; 2968 } 2969 } 2971 ts_lsb 2972 { 2973 UNCOMPRESSED { 2974 tsval [ 32 ]; 2975 } 2977 COMPRESSED tsval_7 { 2978 discriminator =:= '0' [ 1 ]; 2979 tsval =:= lsb(7, -1) [ 7 ]; 2980 } 2982 COMPRESSED tsval_14 { 2983 discriminator =:= '10' [ 2 ]; 2984 tsval =:= lsb(14, -1) [ 14 ]; 2985 } 2987 COMPRESSED tsval_21 { 2988 discriminator =:= '110' [ 3 ]; 2989 tsval =:= lsb(21, 0x00040000) [ 21 ]; 2990 } 2992 COMPRESSED tsval_29 { 2993 discriminator =:= '111' [ 3 ]; 2994 tsval =:= lsb(29, 0x04000000) [ 29 ]; 2995 } 2996 } 2998 tcp_opt_ts 2999 { 3000 UNCOMPRESSED { 3001 type =:= uncompressed_value(8, 8) [ 8 ]; 3002 length =:= uncompressed_value(8, 10) [ 8 ]; 3003 tsval [ 32 ]; 3004 tsecho [ 32 ]; 3005 } 3007 COMPRESSED tsopt_list_item { 3008 tsval =:= irregular(32) [ 32 ]; 3009 tsecho =:= irregular(32) [ 32 ]; 3010 } 3012 COMPRESSED tsopt_irregular { 3013 tsval =:= ts_lsb [ 8, 16, 24, 32 ]; 3014 tsecho =:= ts_lsb [ 8, 16, 24, 32 ]; 3015 } 3016 } 3018 sack_var_length_enc(base) 3019 { 3020 UNCOMPRESSED { 3021 sack_field [ 32 ]; 3022 } 3024 CONTROL { 3025 sack_offset [ 32 ]; 3026 ENFORCE(sack_offset.UVALUE == (sack_field.UVALUE - base)); 3027 } 3029 COMPRESSED lsb_15 { 3030 discriminator =:= '0' [ 1 ]; 3031 sack_offset =:= lsb(15, -1) [ 15 ]; 3032 } 3034 COMPRESSED lsb_22 { 3035 discriminator =:= '10' [ 2 ]; 3036 sack_offset =:= lsb(22, -1) [ 22 ]; 3037 } 3039 COMPRESSED lsb_30 { 3040 discriminator =:= '11' [ 2 ]; 3041 sack_offset =:= lsb(30, -1) [ 30 ]; 3042 } 3043 } 3045 sack_block(prev_block_end) 3046 { 3047 UNCOMPRESSED { 3048 block_start [ 32 ]; 3049 block_end [ 32 ]; 3050 } 3052 COMPRESSED { 3053 block_start =:= 3054 sack_var_length_enc(prev_block_end) [ 16, 24, 32 ]; 3055 block_end =:= 3056 sack_var_length_enc(block_start) [ 16, 24, 32 ]; 3057 } 3058 } 3060 // The value of the parameter is set to the ack_number value 3061 // of the TCP header 3062 tcp_opt_sack(ack_value) 3063 { 3065 UNCOMPRESSED { 3066 type =:= uncompressed_value(8, 5) [ 8 ]; 3067 length [ 8 ]; 3068 block_1 [ 64 ]; 3069 block_2 [ 0, 64 ]; 3070 block_3 [ 0, 64 ]; 3071 block_4 [ 0, 64 ]; 3072 } 3074 DEFAULT { 3075 length =:= static; 3076 block_2 =:= uncompressed_value(0, 0); 3077 block_3 =:= uncompressed_value(0, 0); 3078 block_4 =:= uncompressed_value(0, 0); 3079 } 3081 COMPRESSED sack1_list_item { 3082 discriminator =:= '00000001'; 3083 block_1 =:= sack_block(ack_value); 3084 ENFORCE(length.UVALUE == 10); 3085 } 3087 COMPRESSED sack2_list_item { 3088 discriminator =:= '00000010'; 3089 block_1 =:= sack_block(ack_value); 3090 block_2 =:= sack_block(block_1_end.UVALUE); 3091 ENFORCE(length.UVALUE == 18); 3092 } 3094 COMPRESSED sack3_list_item { 3095 discriminator =:= '00000011'; 3096 block_1 =:= sack_block(ack_value); 3097 block_2 =:= sack_block(block_1_end.UVALUE); 3098 block_3 =:= sack_block(block_2_end.UVALUE); 3099 ENFORCE(length.UVALUE == 26); 3100 } 3102 COMPRESSED sack4_list_item { 3103 discriminator =:= '00000100'; 3104 block_1 =:= sack_block(ack_value); 3105 block_2 =:= sack_block(block_1_end.UVALUE); 3106 block_3 =:= sack_block(block_2_end.UVALUE); 3107 block_4 =:= sack_block(block_3_end.UVALUE); 3108 ENFORCE(length.UVALUE == 34); 3110 } 3112 COMPRESSED sack_unchanged_irregular { 3113 discriminator =:= '00000000'; 3114 block_1 =:= static; 3115 block_2 =:= static; 3116 block_3 =:= static; 3117 block_4 =:= static; 3118 } 3120 COMPRESSED sack1_irregular { 3121 discriminator =:= '00000001'; 3122 block_1 =:= sack_block(ack_value); 3123 ENFORCE(length.UVALUE == 10); 3124 } 3126 COMPRESSED sack2_irregular { 3127 discriminator =:= '00000010'; 3128 block_1 =:= sack_block(ack_value); 3129 block_2 =:= sack_block(block_1_end.UVALUE); 3130 ENFORCE(length.UVALUE == 18); 3131 } 3133 COMPRESSED sack3_irregular { 3134 discriminator =:= '00000011'; 3135 block_1 =:= sack_block(ack_value); 3136 block_2 =:= sack_block(block_1_end.UVALUE); 3137 block_3 =:= sack_block(block_2_end.UVALUE); 3138 ENFORCE(length.UVALUE == 26); 3139 } 3141 COMPRESSED sack4_irregular { 3142 discriminator =:= '00000100'; 3143 block_1 =:= sack_block(ack_value); 3144 block_2 =:= sack_block(block_1_end.UVALUE); 3145 block_3 =:= sack_block(block_2_end.UVALUE); 3146 block_4 =:= sack_block(block_3_end.UVALUE); 3147 ENFORCE(length.UVALUE == 34); 3148 } 3149 } 3151 tcp_opt_sack_permitted 3152 { 3153 UNCOMPRESSED { 3154 type =:= uncompressed_value(8, 4) [ 8 ]; 3155 length =:= uncompressed_value(8, 2) [ 8 ]; 3156 } 3157 COMPRESSED sack_permitted_list_item { 3158 } 3160 COMPRESSED sack_permitted_irregular { 3161 } 3162 } 3164 tcp_opt_generic 3165 { 3166 UNCOMPRESSED { 3167 type [ 8 ]; 3168 length_msb =:= uncompressed_value(1, 0) [ 1 ]; 3169 length_lsb [ 7 ]; 3170 contents [ length_len.UVALUE*8-16 ]; 3171 } 3173 CONTROL { 3174 option_static [ 1 ]; 3175 } 3177 DEFAULT { 3178 type =:= static; 3179 length_lsb =:= static; 3180 contents =:= static; 3181 } 3183 COMPRESSED generic_list_item { 3184 type =:= irregular(8) [ 8 ]; 3185 option_static =:= one_bit_choice [ 1 ]; 3186 length_lsb =:= irregular(7) [ 7 ]; 3187 contents =:= 3188 irregular(length_lsb.UVALUE*8-16) [ length_len.UVALUE*8-16 ]; 3189 } 3191 // Used when context of option has option_static set to one 3192 COMPRESSED generic_static_irregular { 3193 ENFORCE(option_static.UVALUE == 1); 3194 } 3196 // An item that can change, but currently is unchanged 3197 COMPRESSED generic_stable_irregular { 3198 discriminator =:= '11111111' [ 8 ]; 3199 ENFORCE(option_static.UVALUE == 0); 3200 } 3202 // An item that is assumed to change constantly. 3203 // Length is not allowed to change here, since a length change is 3204 // most likely to cause new NOPs or an EOL length change. 3206 COMPRESSED generic_full_irregular { 3207 discriminator =:= '00000000' [ 8 ]; 3208 contents =:= 3209 irregular(length_lsb.UVALUE*8-16) [ length_lsb.UVALUE*8-16 ]; 3210 ENFORCE(option_static.UVALUE == 0); 3211 } 3212 } 3214 tcp_list_presence_enc(presence) 3215 { 3216 UNCOMPRESSED { 3217 tcp_options; 3218 } 3220 COMPRESSED list_not_present { 3221 tcp_options =:= static [ 0 ]; 3222 ENFORCE(presence == 0); 3223 } 3225 COMPRESSED list_present { 3226 tcp_options =:= list_tcp_options [ VARIABLE ]; 3227 ENFORCE(presence == 1); 3228 } 3229 } 3231 ///////////////////////////////////////////// 3232 // TCP Header 3233 ///////////////////////////////////////////// 3235 port_replicate(flags) 3236 { 3237 UNCOMPRESSED { 3238 port [ 16 ]; 3239 } 3241 COMPRESSED port_static_enc { 3242 port =:= static [ 0 ]; 3243 ENFORCE(flags == 0b00); 3244 } 3246 COMPRESSED port_lsb8 { 3247 port =:= lsb(8, 64) [ 8 ]; 3248 ENFORCE(flags == 0b01); 3249 } 3251 COMPRESSED port_irr_enc { 3252 port =:= irregular(16) [ 16 ]; 3253 ENFORCE(flags == 0b10); 3255 } 3256 } 3258 tcp_irreg_ip_ecn(ip_inner_ecn) 3259 { 3260 UNCOMPRESSED { 3261 ip_ecn_flags [ 2 ]; 3262 } 3264 COMPRESSED ecn_present { 3265 // This field does not exist in the uncompressed header 3266 // and therefore cannot use uncompressed_value. 3267 ip_ecn_flags =:= 3268 compressed_value(2, ip_inner_ecn) [ 2 ]; 3269 ENFORCE(ecn_used.UVALUE == 1); 3270 } 3272 COMPRESSED ecn_not_present { 3273 ip_ecn_flags =:= static [ 0 ]; 3274 ENFORCE(ecn_used.UVALUE == 0); 3275 } 3276 } 3278 rsf_index_enc 3279 { 3280 UNCOMPRESSED { 3281 rsf_flag [ 3 ]; 3282 } 3284 COMPRESSED none { 3285 rsf_idx =:= '00' [ 2 ]; 3286 rsf_flag =:= uncompressed_value(3, 0x00); 3287 } 3289 COMPRESSED rst_only { 3290 rsf_idx =:= '01' [ 2 ]; 3291 rsf_flag =:= uncompressed_value(3, 0x04); 3292 } 3294 COMPRESSED syn_only { 3295 rsf_idx =:= '10' [ 2 ]; 3296 rsf_flag =:= uncompressed_value(3, 0x02); 3297 } 3299 COMPRESSED fin_only { 3300 rsf_idx =:= '11' [ 2 ]; 3301 rsf_flag =:= uncompressed_value(3, 0x01); 3302 } 3304 } 3306 optional_2bit_padding(used_flag) 3307 { 3308 UNCOMPRESSED { 3309 } 3311 COMPRESSED used { 3312 padding =:= compressed_value(2, 0x0) [ 2 ]; 3313 ENFORCE(used_flag == 1); 3314 } 3316 COMPRESSED unused { 3317 padding =:= compressed_value(0, 0x0); 3318 ENFORCE(used_flag == 0); 3319 } 3320 } 3322 // ack_stride_value is the user-selected stride for scaling the 3323 // TCP ack_number 3324 // ip_inner_ecn is the value bound when processing the innermost 3325 // IP header (ipv4 or ipv6 encoding method) 3326 tcp(payload_size, ack_stride_value, ip_inner_ecn) 3327 { 3328 UNCOMPRESSED { 3329 src_port [ 16 ]; 3330 dst_port [ 16 ]; 3331 seq_number [ 32 ]; 3332 ack_number [ 32 ]; 3333 data_offset [ 4 ]; 3334 tcp_res_flags [ 4 ]; 3335 tcp_ecn_flags [ 2 ]; 3336 urg_flag [ 1 ]; 3337 ack_flag [ 1 ]; 3338 psh_flag [ 1 ]; 3339 rsf_flags [ 3 ]; 3340 window [ 16 ]; 3341 checksum [ 16 ]; 3342 urg_ptr [ 16 ]; 3343 options [ (data_offset.UVALUE-5)*32 ]; 3344 } 3346 CONTROL { 3347 seq_number_scaled [ 32 ]; 3348 seq_number_residue =:= 3349 field_scaling(payload_size, seq_number_scaled.UVALUE, 3350 seq_number.UVALUE) [ 32 ]; 3351 ack_stride [ 16 ]; 3352 ack_number_scaled [ 32 ]; 3353 ack_number_residue =:= 3354 field_scaling(ack_stride.UVALUE, ack_number_scaled.UVALUE, 3355 ack_number.UVALUE) [ 32 ]; 3356 ENFORCE(ack_stride.UVALUE == ack_stride_value); 3357 } 3359 INITIAL { 3360 ack_stride =:= uncompressed_value(16, 0); 3361 } 3363 DEFAULT { 3364 src_port =:= static; 3365 dst_port =:= static; 3366 seq_number =:= static; 3367 ack_number =:= static; 3368 data_offset =:= inferred_offset; 3369 tcp_res_flags =:= static; 3370 tcp_ecn_flags =:= static; 3371 urg_flag =:= static; 3372 ack_flag =:= uncompressed_value(1, 1); 3373 rsf_flags =:= uncompressed_value(3, 0); 3374 window =:= static; 3375 urg_ptr =:= static; 3376 } 3378 COMPRESSED tcp_static { 3379 src_port =:= irregular(16) [ 16 ]; 3380 dst_port =:= irregular(16) [ 16 ]; 3381 } 3383 COMPRESSED tcp_dynamic { 3384 ecn_used =:= one_bit_choice [ 1 ]; 3385 ack_stride_flag =:= irregular(1) [ 1 ]; 3386 ack_zero =:= irregular(1) [ 1 ]; 3387 urp_zero =:= irregular(1) [ 1 ]; 3388 tcp_res_flags =:= irregular(4) [ 4 ]; 3389 tcp_ecn_flags =:= irregular(2) [ 2 ]; 3390 urg_flag =:= irregular(1) [ 1 ]; 3391 ack_flag =:= irregular(1) [ 1 ]; 3392 psh_flag =:= irregular(1) [ 1 ]; 3393 rsf_flags =:= irregular(3) [ 3 ]; 3394 msn =:= irregular(16) [ 16 ]; 3395 seq_number =:= irregular(32) [ 32 ]; 3396 ack_number =:= 3397 zero_or_irreg(ack_zero.CVALUE, 32) [ 0, 32 ]; 3398 window =:= irregular(16) [ 16 ]; 3399 checksum =:= irregular(16) [ 16 ]; 3400 urg_ptr =:= 3401 zero_or_irreg(urp_zero.CVALUE, 16) [ 0, 16 ]; 3402 ack_stride =:= 3403 static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; 3404 options =:= list_tcp_options [ VARIABLE ]; 3405 } 3407 COMPRESSED tcp_replicate { 3408 reserved =:= '0' [ 1 ]; 3409 window_presence =:= irregular(1) [ 1 ]; 3410 list_present =:= irregular(1) [ 1 ]; 3411 src_port_presence =:= irregular(2) [ 2 ]; 3412 dst_port_presence =:= irregular(2) [ 2 ]; 3413 ack_stride_flag =:= irregular(1) [ 1 ]; 3414 ack_presence =:= irregular(1) [ 1 ]; 3415 urp_presence =:= irregular(1) [ 1 ]; 3416 urg_flag =:= irregular(1) [ 1 ]; 3417 ack_flag =:= irregular(1) [ 1 ]; 3418 psh_flag =:= irregular(1) [ 1 ]; 3419 rsf_flags =:= rsf_index_enc [ 2 ]; 3420 ecn_used =:= one_bit_choice [ 1 ]; 3421 msn =:= irregular(16) [ 16 ]; 3422 seq_number =:= irregular(32) [ 32 ]; 3423 src_port =:= 3424 port_replicate(src_port_presence) [ 0, 8, 16 ]; 3425 dst_port =:= 3426 port_replicate(dst_port_presence) [ 0, 8, 16 ]; 3427 window =:= 3428 static_or_irreg(window_presence, 16) [ 0, 16 ]; 3429 urg_point =:= 3430 static_or_irreg(urp_presence, 16) [ 0, 16 ]; 3431 ack_number =:= 3432 static_or_irreg(ack_presence, 32) [ 0, 32 ]; 3433 ecn_padding =:= 3434 optional_2bit_padding(ecn_used.CVALUE) [ 0, 2 ]; 3435 tcp_res_flags =:= 3436 static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; 3437 tcp_ecn_flags =:= 3438 static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ]; 3439 checksum =:= irregular(16) [ 16 ]; 3440 ack_stride =:= 3441 static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; 3442 options =:= 3443 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3444 } 3446 COMPRESSED tcp_irregular { 3447 ip_ecn_flags =:= tcp_irreg_ip_ecn(ip_inner_ecn) [ 0, 2 ]; 3448 tcp_res_flags =:= 3449 tstatic_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; 3450 tcp_ecn_flags =:= 3451 static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ]; 3452 checksum =:= irregular(16) [ 16 ]; 3453 } 3454 } 3456 /////////////////////////////////////////////////// 3457 // Encoding methods used in compressed base headers 3458 /////////////////////////////////////////////////// 3460 dscp_enc(flag) 3461 { 3462 UNCOMPRESSED { 3463 dscp [ 6 ]; 3464 } 3466 COMPRESSED static_enc { 3467 dscp =:= static [ 0 ]; 3468 ENFORCE(flag == 0); 3469 } 3471 COMPRESSED irreg { 3472 dscp =:= irregular(6) [ 6 ]; 3473 padding =:= compressed_value(2, 0) [ 2 ]; 3474 ENFORCE(flag == 1); 3475 } 3476 } 3478 ip_id_lsb(behavior, k, p) 3479 { 3480 UNCOMPRESSED { 3481 ip_id [ 16 ]; 3482 } 3484 CONTROL { 3485 ip_id_offset [ 16 ]; 3486 ip_id_nbo [ 16 ]; 3487 } 3489 COMPRESSED nbo { 3490 ip_id_offset =:= lsb(k, p) [ k ]; 3491 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 3492 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 3493 } 3495 COMPRESSED non_nbo { 3496 ip_id_offset =:= lsb(k, p) [ k ]; 3497 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 3498 ENFORCE(ip_id_nbo.UVALUE == 3499 (ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256); 3500 ENFORCE(ip_id_nbo.ULENGTH == 16); 3501 ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE); 3502 } 3503 } 3505 optional_ip_id_lsb(behavior, indicator) 3506 { 3507 UNCOMPRESSED { 3508 ip_id [ 16 ]; 3509 } 3511 COMPRESSED short { 3512 ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ]; 3513 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 3514 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3515 ENFORCE(indicator == 0); 3516 } 3518 COMPRESSED long { 3519 ip_id =:= irregular(16) [ 16 ]; 3520 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 3521 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3522 ENFORCE(indicator == 1); 3523 } 3525 COMPRESSED not_present { 3526 ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || 3527 (behavior == IP_ID_BEHAVIOR_ZERO)); 3528 } 3529 } 3531 dont_fragment(version) 3532 { 3533 UNCOMPRESSED { 3534 df [ 1 ]; 3535 } 3537 COMPRESSED v4 { 3538 df =:= irregular(1) [ 1 ]; 3539 ENFORCE(version == 4); 3540 } 3542 COMPRESSED v6 { 3543 df =:= compressed_value(1, 0) [ 1 ]; 3544 ENFORCE(version == 6); 3545 } 3546 } 3548 ////////////////////////////////// 3549 // Actual start of compressed packet formats 3550 // Important note: 3551 // The base header is the compressed representation 3552 // of the innermost IP header AND the TCP header. 3553 ////////////////////////////////// 3555 // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit 3556 // of an outer header has changed. The same value must be passed as 3557 // an argument to the ipv4/ipv6 encoding methods when extracting 3558 // the irregular chain items. 3559 co_baseheader(payload_size, ack_stride_value, 3560 ttl_irregular_chain_flag) 3561 { 3562 UNCOMPRESSED v4 { 3563 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3564 version =:= uncompressed_value(4, 4) [ 4 ]; 3565 header_length =:= uncompressed_value(4, 5) [ 4 ]; 3566 dscp [ 6 ]; 3567 ip_ecn_flags [ 2 ]; 3568 length [ 16 ]; 3569 ip_id [ 16 ]; 3570 rf =:= uncompressed_value(1, 0) [ 1 ]; 3571 df [ 1 ]; 3572 mf =:= uncompressed_value(1, 0) [ 1 ]; 3573 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 3574 ttl_hopl [ 8 ]; 3575 next_header [ 8 ]; 3576 checksum [ 16 ]; 3577 src_addr [ 32 ]; 3578 dest_addr [ 32 ]; 3579 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3580 src_port [ 16 ]; 3581 dest_port [ 16 ]; 3582 seq_number [ 32 ]; 3583 ack_number [ 32 ]; 3584 data_offset [ 4 ]; 3585 tcp_res_flags [ 4 ]; 3586 tcp_ecn_flags [ 2 ]; 3587 urg_flag [ 1 ]; 3588 ack_flag [ 1 ]; 3589 psh_flag [ 1 ]; 3590 rsf_flags [ 3 ]; 3591 window [ 16 ]; 3592 tcp_checksum [ 16 ]; 3593 urg_ptr [ 16 ]; 3594 options [ (data_offset.UVALUE-5)*32 ]; 3595 } 3597 UNCOMPRESSED v6 { 3598 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3599 version =:= uncompressed_value(4, 6) [ 4 ]; 3600 dscp [ 6 ]; 3601 ip_ecn_flags [ 2 ]; 3602 flow_label [ 20 ]; 3603 payload_length [ 16 ]; 3604 next_header [ 8 ]; 3605 ttl_hopl [ 8 ]; 3606 src_addr [ 128 ]; 3607 dest_addr [ 128 ]; 3608 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3609 src_port [ 16 ]; 3610 dest_port [ 16 ]; 3611 seq_number [ 32 ]; 3612 ack_number [ 32 ]; 3613 data_offset [ 4 ]; 3614 tcp_res_flags [ 4 ]; 3615 tcp_ecn_flags [ 2 ]; 3616 urg_flag [ 1 ]; 3617 ack_flag [ 1 ]; 3618 psh_flag [ 1 ]; 3619 rsf_flags [ 3 ]; 3620 window [ 16 ]; 3621 tcp_checksum [ 16 ]; 3622 urg_ptr [ 16 ]; 3623 options [ (data_offset.UVALUE-5)*32 ]; 3624 ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); 3625 } 3627 CONTROL { 3628 ip_id_behavior [ 2 ]; 3629 seq_number_scaled [ 32 ]; 3630 seq_number_residue =:= 3631 field_scaling(payload_size, seq_number_scaled.UVALUE, 3632 seq_number.UVALUE) [ 32 ]; 3633 ack_stride [ 16 ]; 3634 ack_number_scaled [ 32 ]; 3635 ack_number_residue =:= 3636 field_scaling(ack_stride.UVALUE, ack_number_scaled.UVALUE, 3637 ack_number.UVALUE) [ 32 ]; 3638 ENFORCE(ack_stride_value == ack_stride.UVALUE); 3639 } 3640 INITIAL { 3641 ack_stride =:= uncompressed_value(16, 0); 3642 } 3644 DEFAULT { 3645 tcp_ecn_flags =:= static; 3646 data_offset =:= inferred_offset; 3647 tcp_res_flags =:= static; 3648 rsf_flags =:= uncompressed_value(3, 0); 3649 dest_port =:= static; 3650 dscp =:= static; 3651 src_port =:= static; 3652 urg_flag =:= uncompressed_value(1, 0); 3653 window =:= static; 3654 dest_addr =:= static; 3655 version =:= static; 3656 ttl_hopl =:= static; 3657 src_addr =:= static; 3658 df =:= static; 3659 ack_number =:= static; 3660 urg_ptr =:= static; 3661 seq_number =:= static; 3662 ack_flag =:= uncompressed_value(1, 1); 3663 // The default for "options" is case 2) and 3) from 3664 // the list in section 6.3.1 (i.e. nothing present in the 3665 // baseheader itself). 3666 payload_length =:= inferred_ip_v6_length; 3667 checksum =:= inferred_ip_v4_header_checksum; 3668 length =:= inferred_ip_v4_length; 3669 flow_label =:= static; 3670 next_header =:= static; 3671 ip_ecn_flags =:= static; 3672 // The tcp_checksum has no default, 3673 // it is considered a part of tcp_irregular 3674 ip_id_behavior =:= static; 3675 ecn_used =:= static; 3677 // Default is to have no TTL in irregular chain 3678 // Can only be nonzero if co_common is used 3679 ENFORCE(ttl_irregular_chain_flag == 0); 3680 } 3682 //////////////////////////////////////////// 3683 // Common compressed packet format 3684 //////////////////////////////////////////// 3686 COMPRESSED co_common { 3687 discriminator =:= '1111101' [ 7 ]; 3688 ttl_hopl_outer_flag =:= 3689 compressed_value(1, ttl_irregular_chain_flag) [ 1 ]; 3690 ack_flag =:= irregular(1) [ 1 ]; 3691 psh_flag =:= irregular(1) [ 1 ]; 3692 rsf_flags =:= rsf_index_enc [ 2 ]; 3693 msn =:= lsb(4, 4) [ 4 ]; 3694 seq_indicator =:= irregular(2) [ 2 ]; 3695 ack_indicator =:= irregular(2) [ 2 ]; 3696 ack_stride_indicator =:= irregular(1) [ 1 ]; 3697 window_indicator =:= irregular(1) [ 1 ]; 3698 ip_id_indicator =:= irregular(1) [ 1 ]; 3699 urg_ptr_present =:= irregular(1) [ 1 ]; 3700 reserved =:= compressed_value(1, 0) [ 1 ]; 3701 ecn_used =:= one_bit_choice [ 1 ]; 3702 dscp_present =:= irregular(1) [ 1 ]; 3703 ttl_hopl_present =:= irregular(1) [ 1 ]; 3704 list_present =:= irregular(1) [ 1 ]; 3705 ip_id_behavior =:= ip_id_behavior_choice(true) [ 2 ]; 3706 urg_flag =:= irregular(1) [ 1 ]; 3707 df =:= dont_fragment(version.UVALUE) [ 1 ]; 3708 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3709 seq_number =:= 3710 variable_length_32_enc(seq_indicator.CVALUE) [ 0, 8, 16, 32 ]; 3711 ack_number =:= 3712 variable_length_32_enc(ack_indicator.CVALUE) [ 0, 8, 16, 32 ]; 3713 ack_stride =:= 3714 static_or_irreg(ack_stride_indicator.CVALUE, 16) [ 0, 16 ]; 3715 window =:= 3716 static_or_irreg(window_indicator.CVALUE, 16) [ 0, 16 ]; 3717 ip_id =:= 3718 optional_ip_id_lsb(ip_id_behavior.UVALUE, 3719 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 3720 urg_ptr =:= 3721 static_or_irreg(urg_ptr_present.CVALUE, 16) [ 0, 16 ]; 3722 dscp =:= 3723 dscp_enc(dscp_present.CVALUE) [ 0, 8 ]; 3724 ttl_hopl =:= 3725 static_or_irreg(ttl_hopl_present.CVALUE, 8) [ 0, 8 ]; 3726 options =:= 3727 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3728 } 3730 // Send LSBs of sequence number 3731 COMPRESSED rnd_1 { 3732 discriminator =:= '101110' [ 6 ]; 3733 seq_number =:= lsb(18, 65535) [ 18 ]; 3734 msn =:= lsb(4, 4) [ 4 ]; 3735 psh_flag =:= irregular(1) [ 1 ]; 3736 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3737 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || 3738 (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3739 } 3741 // Send scaled sequence number LSBs 3742 COMPRESSED rnd_2 { 3743 discriminator =:= '1100' [ 4 ]; 3744 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3745 msn =:= lsb(4, 4) [ 4 ]; 3746 psh_flag =:= irregular(1) [ 1 ]; 3747 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3748 ENFORCE(payload_size != 0); 3749 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || 3750 (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3751 } 3753 // Send acknowledgment number LSBs 3754 COMPRESSED rnd_3 { 3755 discriminator =:= '0' [ 1 ]; 3756 ack_number =:= lsb(15, 8191) [ 15 ]; 3757 msn =:= lsb(4, 4) [ 4 ]; 3758 psh_flag =:= irregular(1) [ 1 ]; 3759 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3760 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || 3761 (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3762 } 3764 // Send acknowledgment number scaled 3765 COMPRESSED rnd_4 { 3766 discriminator =:= '1101' [ 4 ]; 3767 ack_number_scaled =:= lsb(4, 3) [ 4 ]; 3768 msn =:= lsb(4, 4) [ 4 ]; 3769 psh_flag =:= irregular(1) [ 1 ]; 3770 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3771 ENFORCE(ack_stride.UVALUE != 0); 3772 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || 3773 (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3774 } 3776 // Send ACK and sequence number 3777 COMPRESSED rnd_5 { 3778 discriminator =:= '100' [ 3 ]; 3779 psh_flag =:= irregular(1) [ 1 ]; 3780 msn =:= lsb(4, 4) [ 4 ]; 3781 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3782 seq_number =:= lsb(14, 8191) [ 14 ]; 3783 ack_number =:= lsb(15, 8191) [ 15 ]; 3784 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || 3785 (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3786 } 3788 // Send both ACK and scaled sequence number LSBs 3789 COMPRESSED rnd_6 { 3790 discriminator =:= '1010' [ 4 ]; 3791 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3792 psh_flag =:= irregular(1) [ 1 ]; 3793 ack_number =:= lsb(16, 16383) [ 16 ]; 3794 msn =:= lsb(4, 4) [ 4 ]; 3795 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3796 ENFORCE(payload_size != 0); 3797 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || 3798 (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3799 } 3801 // Send ACK and window 3802 COMPRESSED rnd_7 { 3803 discriminator =:= '101111' [ 6 ]; 3804 ack_number =:= lsb(18, 65535) [ 18 ]; 3805 window =:= irregular(16) [ 16 ]; 3806 msn =:= lsb(4, 4) [ 4 ]; 3807 psh_flag =:= irregular(1) [ 1 ]; 3808 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3809 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || 3810 (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3811 } 3813 // An extended packet type for seldom-changing fields 3814 // Can send LSBs of TTL, RSF flags, change ECN behavior and 3815 // options list 3816 COMPRESSED rnd_8 { 3817 discriminator =:= '10110' [ 5 ]; 3818 rsf_flags =:= rsf_index_enc [ 2 ]; 3819 list_present =:= irregular(1) [ 1 ]; 3820 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3821 msn =:= lsb(4, 4) [ 4 ]; 3822 psh_flag =:= irregular(1) [ 1 ]; 3823 ttl_hopl =:= lsb(3, 3) [ 3 ]; 3824 ecn_used =:= one_bit_choice [ 1 ]; 3825 seq_number =:= lsb(16, 65535) [ 16 ]; 3826 ack_number =:= lsb(16, 16383) [ 16 ]; 3827 options =:= 3828 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3829 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || 3830 (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3831 } 3832 // Send LSBs of sequence number 3833 COMPRESSED seq_1 { 3834 discriminator =:= '1010' [ 4 ]; 3835 ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ]; 3836 seq_number =:= lsb(16, 32767) [ 16 ]; 3837 msn =:= lsb(4, 4) [ 4 ]; 3838 psh_flag =:= irregular(1) [ 1 ]; 3839 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3840 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || 3841 (ip_id_behavior.UVALUE == 3842 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3843 } 3845 // Send scaled sequence number LSBs 3846 COMPRESSED seq_2 { 3847 discriminator =:= '11010' [ 5 ]; 3848 ip_id =:= 3849 ip_id_lsb(ip_id_behavior.UVALUE, 7, 3) [ 7 ]; 3850 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3851 msn =:= lsb(4, 4) [ 4 ]; 3852 psh_flag =:= irregular(1) [ 1 ]; 3853 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3854 ENFORCE(payload_size != 0); 3855 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || 3856 (ip_id_behavior.UVALUE == 3857 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3858 } 3860 // Send acknowledgment number LSBs 3861 COMPRESSED seq_3 { 3862 discriminator =:= '1001' [ 4 ]; 3863 ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ]; 3864 ack_number =:= lsb(16, 16383) [ 16 ]; 3865 msn =:= lsb(4, 4) [ 4 ]; 3866 psh_flag =:= irregular(1) [ 1 ]; 3867 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3868 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || 3869 (ip_id_behavior.UVALUE == 3870 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3871 } 3873 // Send scaled acknowledgment number scaled 3874 COMPRESSED seq_4 { 3875 discriminator =:= '0' [ 1 ]; 3876 ack_number_scaled =:= lsb(4, 3) [ 4 ]; 3877 // Due to having very few ip_id bits, no negative offset 3878 ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 3, 1) [ 3 ]; 3879 msn =:= lsb(4, 4) [ 4 ]; 3880 psh_flag =:= irregular(1) [ 1 ]; 3881 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3882 ENFORCE(ack_stride.UVALUE != 0); 3883 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || 3884 (ip_id_behavior.UVALUE == 3885 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3886 } 3888 // Send ACK and sequence number 3889 COMPRESSED seq_5 { 3890 discriminator =:= '1000' [ 4 ]; 3891 ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ]; 3892 ack_number =:= lsb(16, 16383) [ 16 ]; 3893 seq_number =:= lsb(16, 32767) [ 16 ]; 3894 msn =:= lsb(4, 4) [ 4 ]; 3895 psh_flag =:= irregular(1) [ 1 ]; 3896 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3897 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || 3898 (ip_id_behavior.UVALUE == 3899 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3900 } 3902 // Send both ACK and scaled sequence number LSBs 3903 COMPRESSED seq_6 { 3904 discriminator =:= '11011' [ 5 ]; 3905 seq_number_scaled =:= lsb(4, 7) [ 4 ]; 3906 ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 7, 3) [ 7 ]; 3907 ack_number =:= lsb(16, 16383) [ 16 ]; 3908 msn =:= lsb(4, 4) [ 4 ]; 3909 psh_flag =:= irregular(1) [ 1 ]; 3910 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3911 ENFORCE(payload_size != 0); 3912 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || 3913 (ip_id_behavior.UVALUE == 3914 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3915 } 3917 // Send ACK and window 3918 COMPRESSED seq_7 { 3919 discriminator =:= '1100' [ 4 ]; 3920 window =:= lsb(15, 16383) [ 15 ]; 3921 ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5, 3) [ 5 ]; 3922 ack_number =:= lsb(16, 32767) [ 16 ]; 3923 msn =:= lsb(4, 4) [ 4 ]; 3924 psh_flag =:= irregular(1) [ 1 ]; 3925 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3926 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || 3927 (ip_id_behavior.UVALUE == 3928 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3929 } 3931 // An extended packet type for seldom-changing fields 3932 // Can send LSBs of TTL, RSF flags, change ECN behavior and 3933 // options list 3934 COMPRESSED seq_8 { 3935 discriminator =:= '1011' [ 4 ]; 3936 ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ]; 3937 list_present =:= irregular(1) [ 1 ]; 3938 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3939 msn =:= lsb(4, 4) [ 4 ]; 3940 psh_flag =:= irregular(1) [ 1 ]; 3941 ttl_hopl =:= lsb(3, 3) [ 3 ]; 3942 ecn_used =:= one_bit_choice [ 1 ]; 3943 ack_number =:= lsb(15, 8191) [ 15 ]; 3944 rsf_flags =:= rsf_index_enc [ 2 ]; 3945 seq_number =:= lsb(14, 8191) [ 14 ]; 3946 options =:= 3947 tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; 3948 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || 3949 (ip_id_behavior.UVALUE == 3950 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3951 } 3952 } 3954 8.3. Feedback Formats and Options 3956 8.3.1. Feedback Formats 3958 This section describes the feedback formats for the ROHC-TCP profile, 3959 following the general ROHC feedback format described in section 5.2.3 3960 of [I-D.ietf-rohc-rfc3095bis-framework]. 3962 All feedback formats carry a field labeled MSN. The MSN field 3963 contains LSBs of the MSN control field described in Section 6.1.1. 3964 The sequence number to use is the MSN corresponding to the last 3965 header that was successfully CRC-8 validated or CRC verified. 3967 FEEDBACK-1 3969 0 1 2 3 4 5 6 7 3970 +---+---+---+---+---+---+---+---+ 3971 | MSN | 3972 +---+---+---+---+---+---+---+---+ 3973 MSN: The lsb-encoded master sequence number. 3975 A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, 3976 FEEDBACK-2 must be used. 3978 FEEDBACK-2 3980 0 1 2 3 4 5 6 7 3981 +---+---+---+---+---+---+---+---+ 3982 |Acktype| MSN | 3983 +---+---+---+---+---+---+---+---+ 3984 | MSN | 3985 +---+---+---+---+---+---+---+---+ 3986 | CRC | 3987 +---+---+---+---+---+---+---+---+ 3988 / Feedback options / 3989 +---+---+---+---+---+---+---+---+ 3991 Acktype: 3993 0 = ACK 3994 1 = NACK 3995 2 = STATIC-NACK 3996 3 is reserved (MUST NOT be used for parsability) 3998 MSN: The lsb-encoded master sequence number. 4000 CRC: 8-bit CRC computed over the entire feedback element (as 4001 defined in section 5.2.3.1 of 4002 [I-D.ietf-rohc-rfc3095bis-framework]). For the purpose of 4003 computing the CRC, the CRC field is zero. The CRC is calculated 4004 using the polynomial defined in 4005 [I-D.ietf-rohc-rfc3095bis-framework]. 4007 Feedback options: A variable number of feedback options, see 4008 Section 8.3.2. Options may appear in any order. 4009 A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitely an 4010 acknowlegement for a successfully decompressed packet, which packet 4011 corresponds to the MSN of the feedback element, unless the MSN-NOT- 4012 VALID option (Section 8.3.2.2) appears in the feedback element. 4014 The FEEDBACK-2 format always carries a CRC and is thus more robust 4015 than the FEEDBACK-1 format. When receiving FEEDBACK-2, the 4016 compressor MUST verify the information by computing the CRC and by 4017 comparing the result with the CRC carried in the feedback format. If 4018 the two are not identical, the feedback element MUST be discarded. 4020 8.3.2. Feedback Options 4022 A ROHC-TCP Feedback option has variable length and the following 4023 general format: 4025 0 1 2 3 4 5 6 7 4026 +---+---+---+---+---+---+---+---+ 4027 | Opt Type | Opt Len | 4028 +---+---+---+---+---+---+---+---+ 4029 / option data / Opt Length (octets) 4030 +---+---+---+---+---+---+---+---+ 4032 Each ROHC-TCP feedback option can appear at most once within a 4033 FEEDBACK-2. 4035 8.3.2.1. The REJECT option 4037 The REJECT option informs the compressor that the decompressor does 4038 not have sufficient resources to handle the flow. 4040 +---+---+---+---+---+---+---+---+ 4041 | Opt Type = 2 | Opt Len = 0 | 4042 +---+---+---+---+---+---+---+---+ 4044 When receiving a REJECT option, the compressor MUST stop compressing 4045 the packet flow, and SHOULD refrain from attempting to increase the 4046 number of compressed packet flows for some time. The REJECT option 4047 MUST NOT appear more than once in the FEEDBACK-2 format, otherwise 4048 the compressor MUST discard the entire feedback element. 4050 8.3.2.2. The MSN-NOT-VALID option 4052 The MSN-NOT-VALID option indicates that the MSN of the feedback is 4053 not valid. 4055 +---+---+---+---+---+---+---+---+ 4056 | Opt Type = 3 | Opt Len = 0 | 4057 +---+---+---+---+---+---+---+---+ 4059 A compressor MUST ignore the MSN of the feedback element when this 4060 option is present. Consequently, a NACK or a STATIC-NACK feedback 4061 type sent with the MSN-NOT-VALID option is equivalent to a STATIC- 4062 NACK with respect to the semantics of the feedback message. 4064 The MSN-NOT-VALID option MUST NOT appear more than once in the 4065 FEEDBACK-2 format and MUST NOT appear in the same feedback element as 4066 the MSN option, otherwise the compressor MUST discard the entire 4067 feedback element. 4069 8.3.2.3. The MSN option 4071 The MSN option provides 2 additional bits of MSN. 4073 +---+---+---+---+---+---+---+---+ 4074 | Opt Type = 4 | Opt Len = 1 | 4075 +---+---+---+---+---+---+---+---+ 4076 | MSN | Reserved | 4077 +---+---+---+---+---+---+---+---+ 4079 These two bits are the least significant bits of the MSN, and are 4080 thus concatenated with the 14 bits already present in the FEEDBACK-2 4081 format. 4083 The MSN option MUST NOT appear more than once in the FEEDBACK-2 4084 format and MUST NOT appear in the same feedback element as the MSN- 4085 NOT-VALID option, otherwise the compressor MUST discard the entire 4086 feedback element. 4088 8.3.2.4. The CONTEXT_MEMORY Feedback Option 4090 The CONTEXT_MEMORY option means that the decompressor does not have 4091 sufficient memory resources to handle the context of the packet flow, 4092 as the flow is currently compressed. 4094 0 1 2 3 4 5 6 7 4095 +---+---+---+---+---+---+---+---+ 4096 | Opt Type = 9 | Opt Len = 0 | 4097 +---+---+---+---+---+---+---+---+ 4099 When receiving a CONTEXT_MEMORY option, the compressor SHOULD take 4100 actions to compress the packet flow in a way that requires less 4101 decompressor memory resources, or stop compressing the packet flow. 4103 The CONTEXT_MEMORY option MUST NOT appear more than once in the 4104 FEEDBACK-2 format, otherwise the compressor MUST discard the entire 4105 feedback element. 4107 8.3.2.5. Unknown option types 4109 If an option type unknown to the compressor is encountered, the 4110 compressor MUST continue parsing the rest of the FEEDBACK element, 4111 which is possible since the length of the option is explicit, but 4112 MUST otherwise ignore the unknown option. 4114 9. Security Consideration 4116 A malfunctioning or malicious header compressor could cause the 4117 header decompressor to reconstitute packets that do not match the 4118 original packets but still have valid IP and TCP headers, and 4119 possibly also valid TCP checksums. Such corruption may be detected 4120 with end-to-end authentication and integrity mechanisms that will not 4121 be affected by the compression. Moreover, this header compression 4122 scheme uses an internal checksum for verification of reconstructed 4123 headers. This reduces the probability of producing decompressed 4124 headers not matching the original ones without this being noticed. 4126 Denial-of-service attacks are possible if an intruder can introduce 4127 (for example) bogus IR, CO or FEEDBACK packets onto the link and 4128 thereby cause compression efficiency to be reduced. However, an 4129 intruder having the ability to inject arbitrary packets at the link 4130 layer in this manner raises additional security issues that dwarf 4131 those related to the use of header compression. 4133 10. IANA Considerations 4135 The ROHC profile identifier 0x0006 has been reserved by the IANA for 4136 the profile defined in this document. 4138 <# Editor's Note: To be removed before publication #> 4140 A ROHC profile identifier must be reserved by the IANA for the 4141 profile defined in this document. Profiles 0x0000-0x0005 have 4142 previously been reserved, which means this profile could be 0x0006. 4143 As for previous ROHC profiles, profile numbers 0xnnXX must also be 4144 reserved for future updates of this profile. A suggested 4145 registration in the "RObust Header Compression (ROHC) Profile 4146 Identifiers" name space would then be: 4148 Profile Usage Document 4149 identifier 4151 0x0006 ROHC TCP [RFCXXXX (this)] 4152 0xnn06 Reserved 4154 11. Acknowledgements 4156 The authors would like to thank Qian Zhang, Hong Bin Liao, Richard 4157 Price and Fredrik Lindstroem for their work with early versions of 4158 this specification. Thanks also to Robert Finking and Carsten 4159 Bormann for valuable input. 4161 Additional thanks: this document was reviewed during working group 4162 last-call by committed reviewers Joe Touch and Ted Faber, as well as 4163 by Sally Floyd who provided a review at the request of the Transport 4164 Area Directors. 4166 12. References 4168 12.1. Normative References 4170 [I-D.ietf-rohc-formal-notation] 4171 Pelletier, G. and R. Finking, "Formal Notation for Robust 4172 Header Compression (ROHC-FN)", 4173 draft-ietf-rohc-formal-notation-13 (work in progress), 4174 December 2006. 4176 [I-D.ietf-rohc-rfc3095bis-framework] 4177 Jonsson, L., Pelletier, G., and K. Sandlund, "The RObust 4178 Header Compression (ROHC) Framework", 4179 draft-ietf-rohc-rfc3095bis-framework-02 (work in 4180 progress), October 2006. 4182 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4183 September 1981. 4185 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 4186 RFC 793, September 1981. 4188 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 4189 October 1996. 4191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4192 Requirement Levels", BCP 14, RFC 2119, March 1997. 4194 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4195 (IPv6) Specification", RFC 2460, December 1998. 4197 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 4198 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 4199 March 2000. 4201 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 4202 RFC 2890, September 2000. 4204 [RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context 4205 Replication for ROHC Profiles", RFC 4164, August 2005. 4207 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 4208 December 2005. 4210 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 4211 RFC 4303, December 2005. 4213 12.2. Informative References 4215 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 4216 serial links", RFC 1144, February 1990. 4218 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 4219 for High Performance", RFC 1323, May 1992. 4221 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 4222 Retransmit, and Fast Recovery Algorithms", RFC 2001, 4223 January 1997. 4225 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 4226 Selective Acknowledgment Options", RFC 2018, October 1996. 4228 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 4229 Compression", RFC 2507, February 1999. 4231 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 4232 Extension to the Selective Acknowledgement (SACK) Option 4233 for TCP", RFC 2883, July 2000. 4235 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 4236 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 4237 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 4238 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 4239 Compression (ROHC): Framework and four profiles: RTP, UDP, 4240 ESP, and uncompressed", RFC 3095, July 2001. 4242 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 4243 of Explicit Congestion Notification (ECN) to IP", 4244 RFC 3168, September 2001. 4246 [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): 4247 Terminology and Channel Mapping Examples", RFC 3759, 4248 April 2004. 4250 [RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC): 4251 Requirements on TCP/IP Header Compression", RFC 4163, 4252 August 2005. 4254 [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust 4255 Header Compression (ROHC): ROHC over Channels That Can 4256 Reorder Packets", RFC 4224, January 2006. 4258 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 4259 March 2006. 4261 Authors' Addresses 4263 Ghyslain Pelletier 4264 Ericsson 4265 Box 920 4266 Lulea SE-971 28 4267 Sweden 4269 Phone: +46 (0) 8 404 29 43 4270 Email: ghyslain.pelletier@ericsson.com 4272 Lars-Erik Jonsson 4273 Ericsson 4274 Box 920 4275 Lulea SE-971 28 4276 Sweden 4278 Phone: +46 (0) 8 404 29 61 4279 Email: lars-erik.jonsson@ericsson.com 4281 Kristofer Sandlund 4282 Ericsson 4283 Box 920 4284 Lulea SE-971 28 4285 Sweden 4287 Phone: +46 (0) 8 404 41 58 4288 Email: kristofer.sandlund@ericsson.com 4290 Mark A West 4291 Siemens/Roke Manor 4292 Roke Manor Research Ltd. 4293 Romsey, Hampshire SO51 0ZN 4294 UK 4296 Phone: +44 1794 833311 4297 Email: mark.a.west@roke.co.uk 4298 URI: http://www.roke.co.uk 4300 Full Copyright Statement 4302 Copyright (C) The IETF Trust (2007). 4304 This document is subject to the rights, licenses and restrictions 4305 contained in BCP 78, and except as set forth therein, the authors 4306 retain all their rights. 4308 This document and the information contained herein are provided on an 4309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4311 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4312 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4313 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4316 Intellectual Property 4318 The IETF takes no position regarding the validity or scope of any 4319 Intellectual Property Rights or other rights that might be claimed to 4320 pertain to the implementation or use of the technology described in 4321 this document or the extent to which any license under such rights 4322 might or might not be available; nor does it represent that it has 4323 made any independent effort to identify any such rights. Information 4324 on the procedures with respect to rights in RFC documents can be 4325 found in BCP 78 and BCP 79. 4327 Copies of IPR disclosures made to the IETF Secretariat and any 4328 assurances of licenses to be made available, or the result of an 4329 attempt made to obtain a general license or permission for the use of 4330 such proprietary rights by implementers or users of this 4331 specification can be obtained from the IETF on-line IPR repository at 4332 http://www.ietf.org/ipr. 4334 The IETF invites any interested party to bring to its attention any 4335 copyrights, patents or patent applications, or other proprietary 4336 rights that may cover technology that may be required to implement 4337 this standard. Please address the information to the IETF at 4338 ietf-ipr@ietf.org. 4340 Acknowledgment 4342 Funding for the RFC Editor function is provided by the IETF 4343 Administrative Support Activity (IASA).