Robust Header Compression G. Pelletier Internet-Draft L. Jonsson Expires: July 8, 2006 K. Sandlund Ericsson M. West Siemens/Roke Manor January 4, 2006 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) draft-ietf-rohc-tcp-11.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Existing TCP/IP header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. In addition, existing schemes have not addressed how to compress TCP options such as SACK Pelletier, et al. Expires July 8, 2006 [Page 1] Internet-Draft ROHC-TCP January 2006 (Selective Acknowledgements) and Timestamps. This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, is a robust header compression scheme for TCP/IP that provides improved compression efficiency and enhanced capabilities for compression of various header fields including TCP options. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Existing TCP/IP Header Compression Schemes . . . . . . . 6 3.2. Classification of TCP/IP Header Fields . . . . . . . . . 7 4. Overview of the TCP/IP Profile (Informative) . . . . . . . . 9 4.1. General Concepts . . . . . . . . . . . . . . . . . . . . 9 4.2. Compressor and Decompressor Interactions . . . . . . . . 9 4.2.1. Compressor Operation . . . . . . . . . . . . . . . . 9 4.2.2. Decompressor Feedback . . . . . . . . . . . . . . . . 9 4.3. Packet Formats and Encoding Methods . . . . . . . . . . . 10 4.3.1. Irregular Chain . . . . . . . . . . . . . . . . . . . 10 4.3.2. TCP Options . . . . . . . . . . . . . . . . . . . . . 11 4.3.3. Compressing Extension Headers . . . . . . . . . . . . 11 4.4. Expected Compression Ratios with ROHC-TCP . . . . . . . . 11 5. Compressor and Decompressor Logic (Normative) . . . . . . . . 12 5.1. Context Initialization . . . . . . . . . . . . . . . . . 12 5.2. Compressor Operation . . . . . . . . . . . . . . . . . . 13 5.2.1. Compression Logic . . . . . . . . . . . . . . . . . . 13 5.2.2. Feedback Logic . . . . . . . . . . . . . . . . . . . 14 5.2.3. Context Replication . . . . . . . . . . . . . . . . . 15 5.3. Decompressor Operation . . . . . . . . . . . . . . . . . 15 5.3.1. Decompressor States and Logic . . . . . . . . . . . . 15 5.3.2. Reconstruction and Verification . . . . . . . . . . . 17 5.3.3. Feedback Logic . . . . . . . . . . . . . . . . . . . 18 5.3.4. Context Replication . . . . . . . . . . . . . . . . . 19 6. Encodings in ROHC-TCP (Normative) . . . . . . . . . . . . . . 19 6.1. Control Fields in ROHC-TCP . . . . . . . . . . . . . . . 19 6.1.1. Master Sequence Number (MSN) . . . . . . . . . . . . 19 6.1.2. IP-ID Behavior . . . . . . . . . . . . . . . . . . . 20 6.1.3. Explicit Congestion Notification (ECN) . . . . . . . 21 6.2. Compressed Header Chains . . . . . . . . . . . . . . . . 21 6.3. Compressing TCP Options with List Compression . . . . . . 22 6.3.1. List Compression . . . . . . . . . . . . . . . . . . 22 6.3.2. Table-based Item Compression . . . . . . . . . . . . 23 6.3.3. Encoding of Compressed Lists . . . . . . . . . . . . 24 6.3.4. Item Table Mappings . . . . . . . . . . . . . . . . . 25 Pelletier, et al. Expires July 8, 2006 [Page 2] Internet-Draft ROHC-TCP January 2006 6.3.5. Compressed Lists in Dynamic Chain . . . . . . . . . . 27 6.3.6. Irregular Chain Items for TCP Options . . . . . . . . 27 6.3.7. Replication of TCP Options . . . . . . . . . . . . . 27 6.4. Profile-specific Encoding Methods . . . . . . . . . . . . 27 6.4.1. inferred_ip_v4_header_checksum() . . . . . . . . . . 28 6.4.2. inferred_mine_header_checksum() . . . . . . . . . . . 28 6.4.3. inferred_ip_v4_length() . . . . . . . . . . . . . . . 29 6.4.4. inferred_ip_v6_length() . . . . . . . . . . . . . . . 29 6.4.5. inferred_offset() . . . . . . . . . . . . . . . . . . 30 6.4.6. Scaled TCP Sequence Number Encoding . . . . . . . . . 30 6.4.7. Scaled Acknowledgement Number Encoding . . . . . . . 31 6.5. CRC Calculations . . . . . . . . . . . . . . . . . . . . 32 7. Packet Types (Normative) . . . . . . . . . . . . . . . . . . 32 7.1. Initialization and Refresh Packets (IR) . . . . . . . . . 32 7.2. Context Replication Packets (IR-CR) . . . . . . . . . . . 34 7.3. Compressed Packets (CO) . . . . . . . . . . . . . . . . . 36 8. Packet Formats (Normative) . . . . . . . . . . . . . . . . . 36 8.1. Design rationale for compressed base headers . . . . . . 37 8.2. Formal Definition in ROHC-FN . . . . . . . . . . . . . . 40 8.3. Feedback Formats and Options . . . . . . . . . . . . . . 100 8.3.1. Feedback Formats . . . . . . . . . . . . . . . . . . 100 8.3.2. Feedback Options . . . . . . . . . . . . . . . . . . 101 9. Security Consideration . . . . . . . . . . . . . . . . . . . 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 105 12.2. Informative References . . . . . . . . . . . . . . . . . 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107 Intellectual Property and Copyright Statements . . . . . . . . . 108 Pelletier, et al. Expires July 8, 2006 [Page 3] Internet-Draft ROHC-TCP January 2006 1. Introduction There are several reasons to perform header compression on low- or medium-speed links for TCP/IP traffic, and these have already been discussed in RFC 2507 [RFC2507]. Additional considerations that make robustness an important objective for a TCP [RFC793] compression scheme are introduced in [RFC4163]. Finally, existing TCP/IP header compression schemes (RFC 1144 [RFC1144], RFC 2507 [RFC2507]) are limited in their handling of the TCP options field and cannot compress the headers of handshaking packets (SYNs and FINs). It is thus desirable for a header compression scheme to be able to handle loss on the link between the compression and decompression point as well as loss before the compression point. The header compression scheme also needs to consider how to efficiently compress short-lived TCP transfers and TCP options, such as SACK (RFC 2018 [RFC2018], RFC 2883 [RFC2883]) and Timestamps (RFC 1323 [RFC1323]). The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets, or for different compression strategies. This document defines a TCP/IP compression profile for the ROHC framework [RFC3095], compliant with the requirements on ROHC TCP/IP header compression [RFC4163]. Specifically, it describes a header compression scheme for TCP/IP header compression (ROHC-TCP) that is robust against packet loss and that offers enhanced capabilities, in particular for the compression of header fields including TCP options. The profile identifier for TCP/IP compression is 0x0006. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document reuses some of the terminology found in RFC 3095 [RFC3095]. In addition, this document uses or defines the following terms: Base context The base context is a context that has been validated by both the compressor and the decompressor. A base context can be used as the reference when building a new context using replication. Base CID Pelletier, et al. Expires July 8, 2006 [Page 4] Internet-Draft ROHC-TCP January 2006 The Base Context Identifier is the CID used to identify the Base Context, where information needed for context replication can be extracted from. Context Replication (CR) Context replication is the mechanism that establishes and initializes a new context based on another existing valid context (a base context). This mechanism is introduced to reduce the overhead of the context establishment procedure, and is especially useful for compression of multiple short-lived TCP connections that may be occurring simultaneously or near-simultaneously. CRC-8 validation The CRC-8 validation refers to the validation of the integrity against bit error(s) of the received IR, the IR-DYN or the IR-CR header, using the 8-bit CRC that is included in the header. CRC verification The CRC verification refers to the verification of the result of a decompression attempt, using the 3-bit CRC or 7-bit CRC included in the header of a compressed packet format (CO). ROHC Context Replication (ROHC-CR) "ROHC-CR" in this document normatively refers to the context replication mechanism for ROHC profiles defined in [RFC4164]. ROHC Formal Notation (ROHC-FN) "ROHC-FN" in this document normatively refers to the formal notation for ROHC profiles defined in [ROHC-FN], including the library of encoding methods it specifies. ROHC-TCP packet types ROHC-TCP uses two different packet types: the Initialization and Refresh (IR) packet type, and the Compressed packet type (CO). Short-lived TCP transfer Short-lived TCP transfers refer to TCP connections transmitting only small amounts of packets for each single connection. Pelletier, et al. Expires July 8, 2006 [Page 5] Internet-Draft ROHC-TCP January 2006 3. Background This chapter provides some background information on TCP/IP header compression. The fundamentals of general header compression can be found in [RFC3095]. In the following sections, two existing TCP/IP header compression schemes are first described along with a discussion of their limitations, followed by the classification of TCP/IP header fields. Finally, some of the characteristics of short- lived TCP transfers are summarized. The behavior analysis of TCP/IP header fields among multiple short- lived connections may be found in [TCP-BEH]. 3.1. Existing TCP/IP Header Compression Schemes Compressed TCP (CTCP) and IP Header Compression (IPHC) are two different schemes that may be used to compress TCP/IP headers. Both schemes transmit only the differences from the previous header in order to reduce the large overhead of the TCP/IP header. The CTCP (RFC 1144 [RFC1144]) compressor detects transport-level retransmissions and sends a header that updates the context completely when they occur. While CTCP works well over reliable links, it is vulnerable when used over less reliable links as even a single packet loss results in loss of synchronization between the compressor and the decompressor. This in turn leads to the TCP receiver discarding all remaining packets in the current window because of a checksum error. This effectively prevents the TCP Fast Retransmit algorithm (RFC 2001) from being triggered. In such case, the compressor must wait until the TCP timeout to resynchronize. To reduce the errors due to the inconsistent contexts between compressor and decompressor when compressing TCP, IPHC (RFC 2507 [RFC2507]) improves somewhat on CTCP by augmenting the repair mechanism of CTCP with a local repair mechanism called TWICE and with a link layer nacking mechanism to request a header that updates the context. The TWICE algorithm assumes that only the Sequence Number field of TCP segments are changing with the deltas between consecutive packets being constant in most cases. This assumption is however not always true, especially when TCP Timestamps and SACK options are used. The full header request mechanism requires a feedback channel that may be unavailable in some circumstances. This channel is used to explicitly request that the next packet be sent with an uncompressed header to allow resynchronization without waiting for a TCP timeout. In addition, this mechanism does not perform well on links with long Pelletier, et al. Expires July 8, 2006 [Page 6] Internet-Draft ROHC-TCP January 2006 round-trip time. Both CTCP and IPHC are also limited in their handling of the TCP options field. For IPHC, any change in the options field (caused by timestamps or SACK, for example) renders the entire field uncompressible, while for CTCP such a change in the options field effectively disables TCP/IP header compression altogether. Finally, existing TCP/IP compression schemes do not compress the headers of handshaking packets (SYNs and FINs). Compressing these packets may greatly improve the overall header compression ratio for the cases where many short-lived TCP connections share the same channel. 3.2. Classification of TCP/IP Header Fields Header compression is possible due to the fact that there is much redundancy between header field values within packets, especially between consecutive packets. To utilize these properties for TCP/IP header compression, it is important to understand the change patterns of the various header fields. All fields of the TCP/IP packet header have been classified in detail in [TCP-BEH]. The main conclusion is that most of the header fields can easily be compressed away since they seldom or never change. The following fields do however require more sophisticated mechanisms: * IPv4 Identification (16 bits) - IP-ID * TCP Sequence Number (32 bits) - SN * TCP Acknowledgment Number (32 bits) - ACKN * TCP Reserved (4 bits) * TCP ECN flags (2 bits) - ECN * TCP Window (16 bits) - WINDOW * TCP Options + Maximum Segment Size (32 bits) - MSS + Window Scale (24 bits) - WSopt + SACK Permitted (16 bits) + TCP SACK (80, 144, 208 or 272 bits) - SACK + TCP Timestamp (80 bits) - TS The assignment of IP-ID values can be done in various ways, which are Sequential, Sequential jump, Random or constant to a value of zero. Some IPv4 stacks do use a sequential assignment when generating IP-ID values but do not transmit the contents of this field in network byte order; instead it is sent with the two octets reversed. In this case, the compressor can compress the IP-ID field after swapping the bytes. Consequently, the decompressor also swaps the bytes of the IP-ID after decompression to regenerate the original IP-ID. In RFC Pelletier, et al. Expires July 8, 2006 [Page 7] Internet-Draft ROHC-TCP January 2006 3095 [RFC3095], the IP-ID is generally inferred from the RTP Sequence Number. However, with respect to TCP compression, the analysis in [TCP-BEH] reveals that there is no obvious candidate to this purpose among the TCP fields. The change pattern of several TCP fields (Sequence Number, Acknowledgment Number, Window, etc.) is very hard to predict and differs entirely from the behavior of RTP fields discussed in [RFC3095]. Of particular importance to a TCP/IP header compression scheme is the understanding of the sequence and acknowledgment number [TCP-BEH]. Specifically, the sequence number can be anywhere within a range defined by the TCP window at any point on the path (i.e. wherever a compressor might be deployed). Missing packets or retransmissions can cause the TCP sequence number to fluctuate within the limits of this window. The TCP window also bounds the jumps in acknowledgment number. Another important behavior of the TCP/IP header is the dependency between the sequence number and the acknowledgment number. TCP connections can be either near-symmetrical or show a strong asymmetrical bias with respect to the data traffic. In the latter case, the TCP connections mainly have one-way traffic (web browsing and FTP downloading, for example). This means that on the forward path (from server to client), only the sequence number is changing while the acknowledgment number remains constant for most packets; on the backward path (from client to server), only the acknowledgment number is changing and the sequence number remains constant for most packets. A compression scheme for TCP should thus have packet formats suitable for either cases, i.e. packet formats that can carry either only sequence number bits, only acknowledgement bits, or both. In addition, TCP flows can be short-lived transfers. Short-lived TCP transfers will degrade the performance of header compression schemes that establish a new context by initially sending full headers. Multiple simultaneous or near simultaneous TCP connections may exhibit much similarity in header field values and context values among each other, which would make it possible to reuse information between flows when initializing a new context. A mechanism to this end, context replication [RFC4164], makes the context establishment step faster and more efficient, by replicating part of an existing context to a new flow. All header fields and related context values have been classified in detail in [TCP-BEH]; the conclusion is that most part of the IP sub-context, some TCP fields, and some context values can easily be replicated since they seldom change or change with only a small jump. Pelletier, et al. Expires July 8, 2006 [Page 8] Internet-Draft ROHC-TCP January 2006 Finally, headers specific to Mobile IP (for IPv4 or IPv6) do not receive any special treatment in this document, for reasons similar as those described in [RFC3095]. 4. Overview of the TCP/IP Profile (Informative) 4.1. General Concepts Many of the concepts behind the ROHC-TCP profile are similar to those described in RFC 3095 [RFC3095]. Like for other ROHC profiles, ROHC- TCP makes use of the ROHC protocol as described in [RFC3095], in sections 5.1 to 5.2.6. This includes data structures, reserved packet types, general packet formats, segmentation and initial decompressor processing. In addition, ROHC-TCP supports context replication as defined in ROHC-CR [RFC4164]. Context replication can be particularly useful for short-lived TCP flows [TCP-BEH]. 4.2. Compressor and Decompressor Interactions 4.2.1. Compressor Operation Header compression with ROHC can be conceptually characterized as the interaction of a compressor with a decompressor state machine. The compressor's task is to minimally send the information needed to successfully decompress a packet, based on a certain confidence regarding the state of the decompressor context. For ROHC-TCP compression, the compressor normally starts compression with the initial assumption that the decompressor has no useful information to process the new flow, and sends Initialization and Refresh (IR) packets. Alternatively, the compressor may also support Context Replication (CR) and use IR-CR packets [RFC4164] which attempts to reuse context information related to another flow. The compressor can then adjust the compression level based on its confidence that the decompressor has the necessary information to successfully process the compressed packets (CO) that it selects. In other words, the task of the compressor is to ensure that the decompressor operates in the state that allows decompression of the most efficient CO packet(s), and to allow the decompressor to move to that state as soon as possible otherwise. 4.2.2. Decompressor Feedback The ROHC-TCP profile can be used in environments with or without Pelletier, et al. Expires July 8, 2006 [Page 9] Internet-Draft ROHC-TCP January 2006 feedback capabilities from decompressor to compressor. ROHC-TCP however assumes that if a ROHC feedback channel is available and if this channel is used at least once by the decompressor for a specific ROHC-TCP context, this channel will be used during the entire compression operation for that context. If the connection is broken and the feedback channel disappears, compression should be restarted. The reception of either positive feedback (ACKs) or negative feedback (NACKs) establishes the feedback channel from the decompressor for the context for which the feedback was received. Once there is an established feedback channel for a specific context, the compressor should make use of this feedback to estimate the current state of the decompressor. This helps increasing the compression efficiency by providing the information needed for the compressor to achieve the necessary confidence level. To parallel RFC 3095 [RFC3095], this is similar to allowing only one mode transition per compressor: from the initial unidirectional mode to the bi-directional mode of operation, with the transition being triggered by the reception of the first packet containing feedback from the decompressor. This effectively means that ROHC-TCP does not explicitly define any operational modes. The ROHC-TCP feedback mechanism is limited in its applicability by the number of MSN (LSB coded) bits used in the FEEDBACK-2 format. It is not suitable for a decompressor to use feedback altogether where the MSN bits in the feedback could wraparound under one round-trip time (RTT). Instead, unidirectional operation -- where the compressor periodically sends larger context updating packets -- is more appropriate. 4.3. Packet Formats and Encoding Methods The packet formats used for ROHC-TCP are defined using the formal notation, ROHC-FN. The formal notation is used to provide an unambiguous representation of the packet formats and a clear definition of the encoding methods. The encoding methods used in the packet formats for ROHC-TCP are defined in [ROHC-FN]. 4.3.1. Irregular Chain The ROHC-TCP profile defines an irregular chain for each header type, in addition to the static and dynamic chains as used in RFC 3095 [RFC3095]. The irregular chain handles fields for which no predictable change pattern could be identified, i.e. fields from the TCP, IP and extension headers that have an irregular behavior and therefore have Pelletier, et al. Expires July 8, 2006 [Page 10] Internet-Draft ROHC-TCP January 2006 to be included in each compressed packet. This chain is attached to compressed packet in order to make it possible to carry arbitrary combinations of headers. 4.3.2. TCP Options The TCP options in ROHC-TCP are compressed using a downscaled version of the list compression in [RFC3095], allowing option content to be established so that TCP options can be added or removed from the packet without having to send the entire option uncompressed. 4.3.3. Compressing Extension Headers In RFC 3095 [RFC3095], list compression is used to compress extension headers. ROHC-TCP compresses the same type of extension headers as in [RFC3095]. However, these headers are treated exactly as other headers and thus have a static chain, a dynamic chain, an irregular chain and a chain for context replication Section 6.2. The consequence is that headers appearing in or disappearing from the flow being compressed will lead to changes to the static chain. However, the change pattern of extension headers is not deemed to impair compression efficiency with respect to this design strategy. 4.4. Expected Compression Ratios with ROHC-TCP The following table illustrates typical compression ratios that can be expected when using ROHC-TCP and IPHC [RFC2507]. The figures in the table assumes that the compression context has already been properly initialized. For the TS option, the timestamp is assumed to change with small values. All TCP options include a suitable number of NOP options for padding and/or alignment. Finally, in the example for IPv4, a sequential IP-ID behavior is assumed. Pelletier, et al. Expires July 8, 2006 [Page 11] Internet-Draft ROHC-TCP January 2006 Total Header Size (octets) ROHC-TCP IPHC Unc. DATA ACK DATA ACK IPv4+TCP+TSopt 52 8 8 18 18 IPv4+TCP+TSopt 52 7 6 16 16 (1) IPv6+TCP+TSopt 72 8 7 18 18 IPv6+TCP+no opt 60 6 5 6 6 IPv6+TCP+SACK 80 - 15 - 80 (2) IPv6+TCP+SACK 80 - 9 - 26 (3) (1) The payload size of the data stream is constant (2) The SACK option appears in the header, but was not present in the previous packet. Two SACK blocks are assumed. (3) The SACK option appears in the header, and was also present in the previous packet (with different SACK blocks). Two SACK blocks are assumed. The table below illustrates the typical initial compression ratios for ROHC-TCP and IPHC. The data stream in the example is assumed to be IPv4+TCP, with a sequential behavior for the IP-ID. The following options are assumed present in the SYN packet: TS, MSS and WSCALE, with an appropriate number of NOP options. Finally, the figures in the table assume that a ROHC ACK has reached the compressor before the second packet is being compressed, which can be expected when using bidirectional ROHC-TCP operation; this is because in the most common case the TCP ACKs are expected to take the same return path, and because TCP does not send more packets until the TCP SYN packet has been acknowledged. Total Header Size (octets) Unc. ROHC-TCP IPHC 1st packet (SYN) 60 49 60 2nd packet 52 12 52 5. Compressor and Decompressor Logic (Normative) The header compression logic as described in this chapter is a simplified version of the one found in [RFC3095]. 5.1. Context Initialization The static context of ROHC TCP flows can be initialized in either of two ways: Pelletier, et al. Expires July 8, 2006 [Page 12] Internet-Draft ROHC-TCP January 2006 1. By using an IR packet as in Section 7.1, where the profile is six (6) and the static chain ends with the static part of a TCP header. 2. By replicating an existing context using the mechanism defined by ROHC-CR. This is done with the IR-CR packet defined in Section 7.2, where the profile number is six (6). 5.2. Compressor Operation 5.2.1. Compression Logic The task of the compressor is to determine what data must be sent when compressing a TCP/IP packet, so that the decompressor can successfully reconstruct the original packet based on its current state. The selection of the type of compressed header to send thus depends on a number of factors, including: o The change behavior of header fields in the stream, e.g. conveying the necessary information within the restrictions of the set of available packet formats; o The compressor's level of confidence regarding decompressor state, e.g. by using an optimistic approach through repetition of context updates or from the reception of decompressor feedback (ACKs and/or NACKs); o Additional robustness required for the flow, e.g. periodic repetition of static and dynamic information using IR and IR-DYN packets when decompressor feedback is not expected. The impact of these factors on the compressor's packet type selection is described more in detail in the following subsections. In this section, a "higher compression state" means that less data will be sent in compressed packets, i.e. smaller compressed headers are used, while a lower compression state means that a larger amount of data will be sent using larger compressed headers. 5.2.1.1. Optimistic Approach When ROHC-TCP is used over lossy links, all information needs to be repeated by the compressor until it is fairly confident that the decompressor has received the information contained in the packet. Therefore, if field X in the uncompressed packet changes value, the compressor MUST use a packet type that contains an encoding of field X until it has gained confidence that the decompressor has received at least one packet containing the new value for X. The compressor Pelletier, et al. Expires July 8, 2006 [Page 13] Internet-Draft ROHC-TCP January 2006 SHOULD choose a compressed format with the smallest header that can convey the changes needed to fulfil the optimistic approach condition used. 5.2.1.2. Periodic Context Refreshes When the optimistic approach is used, there will always be a possibility of decompression failures since the decompressor may not have received sufficient information for correct decompression. Therefore, until the decompressor has established a feedback channel, the compressor SHOULD periodically move to a lower compression state and send IR and/or IR-DYN packets. These refreshes can be based on timeouts, on the number of compressed packets sent for the flow or any other strategy the implementer chooses. Once the feedback channel is established, the decompressor MAY stop sending periodic refreshes. 5.2.2. Feedback Logic The compressor makes use of the feedback from the decompressor to move to a lower compression state (NACKs), and optionally to move to a higher compression state (ACKs). 5.2.2.1. Optional Acknowledgements (ACKs) The compressor MAY optionally use acknowledgment feedback (ACKs) to move to a higher compression state. Upon reception of an ACK for a context-updating packet, the compressor obtains confidence that the decompressor has received the acknowledged packet and that it has observed changes in the packet flow up to the acknowledged packet. This functionality is optional, so a compressor MUST NOT expect to get such ACKs, even if a feedback channel is available and has been established for that flow. 5.2.2.2. Negative Acknowledgements (NACKs) Negative acknowledgments (NACKs or STATIC-NACKs) are also called error recovery requests and indicate that the decompressor context has been invalidated. On reception of a NACK feedback, the compressor SHOULD: Pelletier, et al. Expires July 8, 2006 [Page 14] Internet-Draft ROHC-TCP January 2006 o assume that only the static part of the decompressor is valid, and o re-send all dynamic information (via an IR or IR-DYN packet) next time it compresses a packet for the indicated flow unless it has confidence that information sent after the packet that is being acknowledged already provides a suitable response to the error recovery request. On reception of a STATIC-NACK feedback, the compressor SHOULD: o assume that the decompressor has no valid context, and o re-send all static and all dynamic information (via an IR packet) next time it compresses a packet for the indicated flow. unless it has confidence that information sent after the packet that is being acknowledged already provides a suitable response to the error recovery request. 5.2.3. Context Replication A compressor MAY support context replication by implementing the additional compression and feedback logic defined in ROHC-CR [RFC4164]. 5.3. Decompressor Operation 5.3.1. Decompressor States and Logic The three states of the decompressor are No Context (NC), Static Context (SC) and Full Context (FC). The decompressor starts in its lowest compression state, the NC state. Successful decompression will always move the decompressor to the FC state. The decompressor state machine normally never leaves the FC state once it has entered this state; only repeated decompression failures will force the decompressor to transit downwards to a lower state. Below is the state machine for the decompressor. Details of the transitions between states and decompression logic are given in the sub-sections following the figure. Pelletier, et al. Expires July 8, 2006 [Page 15] Internet-Draft ROHC-TCP January 2006 Success +-->------>------>------>------>------>--+ | | No Static | No Dynamic Success | Success +-->--+ | +-->--+ +--->----->---+ +-->--+ | | | | | | | | | | v | | v | v | v +-----------------+ +---------------------+ +-------------------+ | No Context (NC) | | Static Context (SC) | | Full Context (FC) | +-----------------+ +---------------------+ +-------------------+ ^ | ^ | | Static Context Damage | | Context Damage | +-----<------<------<-----+ +-----<------<------<-----+ 5.3.1.1. No Context (NC) State Initially, while working in the No Context (NC) state, the decompressor has not yet successfully decompressed a packet. Allowing decompression: In the NC state, only packets carrying sufficient information on the static fields (e.g. IR packets) can be decompressed; otherwise, the packet MUST be discarded. Feedback logic: In the NC state, the decompressor SHOULD send a STATIC-NACK if a packet of a type other than one for which decompression is allowed is received, or if an IR packet has failed the CRC-8 validation. Once a packet has been validated and decompressed correctly, the decompressor MUST transit to the FC state. 5.3.1.2. Static Context (SC) State When the decompressor is in the Static Context (SC) state, only the static part of the decompressor context is valid. From the SC state, the decompressor moves back to the NC state if static context damage is detected. How the decompressor detects static context damage should be based on the residual error rate, where a low error rate should make the decompressor assume damage more often than on a link with a higher error rate. Allowing decompression: Pelletier, et al. Expires July 8, 2006 [Page 16] Internet-Draft ROHC-TCP January 2006 In the SC state, only packets carrying sufficient information on the dynamic fields covered by an 8-bit CRC can be decompressed (e.g. IR and IR-DYN); otherwise the packet is of type CO and it MUST be discarded. Feedback logic: In the SC state, the decompressor SHOULD send a STATIC-NACK when an IR or an IR-DYN packet fails the CRC-8 validation. If a CO packet type is received, the decompressor SHOULD treat it as a CRC mismatch when deciding if a NACK is to be sent. Once a packet has been validated and decompressed correctly, the decompressor MUST transit to the FC state. 5.3.1.3. Full Context (FC) State In the Full Context (FC) state, both the static and the dynamic part of the decompressor context is valid. The decompressor moves back to the SC state if context damage is detected. How the decompressor detects context damage should be based on the residual error rate, where a low error rate should make the decompressor assume damage more often than on a link with a higher error rate. The decompressor may send feedback, as described below, when assuming context damage. Allowing decompression: In the FC state, decompression can be attempted regardless of the type of packet received. Feedback logic: In the FC state, the decompressor SHOULD send a NACK when decompression of any packet type fails and if context damage is assumed. 5.3.2. Reconstruction and Verification When decompression of an IR or an IR-DYN packet is allowed, the decompressor MUST validate the integrity of the received header using CRC-8 validation: the decompressor computes the 8-bit CRC according to the type of the received header, and then compares the result with the 8-bit CRC carried in the header. If the two are identical, the decompressor reconstructs the original header. Otherwise the packet MUST be discarded without further processing. Upon receiving an IR-CR packet, the decompressor MUST perform the actions as specified in [RFC4164]. Pelletier, et al. Expires July 8, 2006 [Page 17] Internet-Draft ROHC-TCP January 2006 When decompression of other types of packet is allowed (CO packets), the decompressor MUST then check the outcome of the decompression attempt using CRC verification: the decompressor computes the 3-bit CRC or the 7-bit CRC over the reconstructed header, and then compares the result with the corresponding CRC carried in the received header. If the two are identical, the decompression attempt is successful. If they are not identical, decompressor implementations MAY attempt corrective or repair measures on the packet, and the result of any attempt MUST be validated using the CRC verification; otherwise, the packet MUST be discarded without further processing. When the CRC-8 validation or the CRC verification of the received header is successful, the decompressor SHOULD update its context with the information received in the current header; the decompressor then passes the reconstructed packet to the system's network layer. Otherwise, the decompressor context MUST NOT be updated. If the received packet is older than the current reference packet (based on the Master Sequence Number (MSN) in the compressed packet), the decompressor MAY refrain from updating the context using the information received in the current packet, even if the correctness of its header was successfully verified. If a feedback channel is available, the decompressor MAY use positive feedback (ACKs) to acknowledge successful decompression of packets. 5.3.3. Feedback Logic The decompressor MAY send positive feedback (ACKs) to initially establish the feedback channel for a particular flow. Either positive feedback (ACKs) or negative feedback (NACKs) establishes this channel. The decompressor MUST then use the feedback channel to send error recovery requests and (optionally) acknowledgments of significant context updates. Once the feedback channel is established, the decompressor is REQUIRED to continue sending error recovery requests (i.e. NACKs or STATIC-NACKs) for as long as the context is associated with the same profile, in this case with profile 0x0006, as per the logic defined for each state in Section 5.3.1. EDITOR's NOTE: ADD TEXT ON GENERATION IF ACCEPTED: "OR FOR AS LONG AS THE GENERATION DOES NOT CHANGE FOR THIS CID/PROFILE"? The decompressor MAY optionally send ACKs upon successful decompression of any packet type. In particular, when an IR, an IR- DYN or any CO packet carrying a significant context update is correctly decompressed, the decompressor MAY optionally send an ACK. Pelletier, et al. Expires July 8, 2006 [Page 18] Internet-Draft ROHC-TCP January 2006 The decompressor SHOULD limit the rate at which it sends feedback (for both ACKs and NACKs), and SHOULD avoid sending unnecessary duplicates of the same type of feedback message that may be associated to the same event. 5.3.4. Context Replication ROHC-TCP supports context replication, therefore the decompressor MUST implement the additional decompressor and feedback logic defined in ROHC-CR [RFC4164]. 6. Encodings in ROHC-TCP (Normative) This section describes a ROHC profile for TCP/IP compression. The profile identifier for ROHC-TCP is 0x0006. 6.1. Control Fields in ROHC-TCP In ROHC-TCP, a number of control fields are used by the decompressor in its interpretation of the packet formats for packets received from the compressor. A control field is a field that is transmitted from the compressor to the decompressor, but is not part of the uncompressed header. Values for control fields can be set up in the context of both the compressor and the decompressor. Once established at the decompressor, the values of these fields should be kept until updated by another packet. 6.1.1. Master Sequence Number (MSN) There is no field in the TCP header that can act as the master sequence number for TCP compression, as explained in [TCP-BEH], section 5.6. To overcome this problem, ROHC-TCP introduces a control field called the Master Sequence Number (MSN) field. The MSN field is created at the compressor, rather than using one of the fields already present in the uncompressed header. The compressor increments the value of the MSN by one for each packet that it sends. The MSN field has the following two functions: 1. Differentiating between packets when sending feedback data. 2. Inferring the value of incrementing fields such as the IP-ID. The MSN field is present in every packet sent by the compressor. The Pelletier, et al. Expires July 8, 2006 [Page 19] Internet-Draft ROHC-TCP January 2006 MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent in full in IR/IR-DYN packets. The decompressor always sends the MSN as part of the feedback information. The compressor can later use the MSN to infer which packet the decompressor is acknowledging. When the MSN is initialized, it is initialized to a random value. The compressor should only initialize a new MSN for the initial IR or IR-CR packet sent for a CID that corresponds to a context that is not already associated with this profile. In other words, if the compressor reuses the same CID to compress many TCP flows one after the other, the MSN is not reinitialized but rather continues to increment monotonically. For context replication, the compressor does not use the MSN of the base context when sending the IR-CR packet, unless the replication process overwrites the base context (i.e. BCID == CID). Instead, the compressor uses the value of the MSN if it already exists in the context being associated with the new flow (CID); otherwise, the MSN is initialized to a new value. 6.1.2. IP-ID Behavior The IP-ID field of the IPv4 header can have different change patterns. RFC 3095 [RFC3095] describes three behaviors: sequential (NBO), sequential byte-swapped, and random (RND). In addition, this profile uses a fourth behavior, the constant zero IP-ID behavior as defined in RFC 3843 [RFC3843] (SID). The compressor monitors changes in the value of the IP-ID field for a number of packets, to identify which one of the above listed behavior is the closest match to the observed change pattern. The compressor can then select packet formats based on the identified field behavior. If more than one level of IP headers is present, ROHC-TCP can assign a sequential behavior (NBO or byte-swapped) only to the IP-ID of innermost IP header. This is because only this IP-ID can possibly have a sufficiently close correlation with the MSN (see also Section 6.1.1) to compress it as a sequentially changing field. Therefore, a compressor MUST assign either the constant zero IP-ID or the random IP-ID behavior to tunneling headers. The control field for the IP-ID behavior determines which set of packet formats will be used. Note that these control fields are also used to determine the contents of the irregular chain item for each IP header. Pelletier, et al. Expires July 8, 2006 [Page 20] Internet-Draft ROHC-TCP January 2006 6.1.3. Explicit Congestion Notification (ECN) When ECN [RFC3168] is used once on a stream, it can be expected that the ECN bits will change quite often. ROHC-TCP maintains a control field in the context to indicate if ECN is used or not. This control field is transmitted in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC. When this control field indicates that ECN is being used, items of IP and TCP headers in the irregular chain will include bits used for ECN. To preserve octet-alignment, all of the TCP reserved bits are transmitted and, for outer IP headers, the entire TOS/TC field is included in the irregular chain. The design rationale behind this is the possible use of the "full- functionality option" of section 9.1 of RFC 3168 [RFC3168]. 6.2. Compressed Header Chains Some packet types use one or more chains containing sub-header information. The function of a chain is to group items based on similar characteristics, i.e. grouping fields that either are static, dynamic or irregular in behavior. Chaining is done by appending each item to the chain in their order of appearance in the original header, starting from the fields in the outermost header. Static chain: The static chain consists of one item for each header of the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. In the formal description of the packet formats, this static chain item for each header type is labelled format__static. Dynamic chain: The dynamic chain consists of one item for each header of the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. It should be noted that the dynamic chain item for the TCP header also contains a compressed list of TCP options (see Section 6.3). In the formal description of the packet formats, the dynamic chain item for each header type is labelled format__dynamic. Replicate chain: Pelletier, et al. Expires July 8, 2006 [Page 21] Internet-Draft ROHC-TCP January 2006 The replicate chain consists of one item for each header in the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. It should be noted that the replicate chain item for the TCP header also contains a compressed list of TCP options (see Section 6.3). In the formal description of the packet formats, this replicate chain item for each header type is labelled format__replicate. Header fields that are not present in the replicate chain are replicated from the base context. Irregular chain: The structure of the irregular chain is analogous to the structure of the static chain. For each compressed packet, the irregular chain is appended at the specified location in the general format of the compressed packets as defined in Section 7.3. This chain also includes the irregular chain items for TCP options as defined in Section 6.3.6. Note that the format of the irregular chain for the innermost IP header differs from the format of outer IP headers, since this header is a part of the compressed base header. The name of the chain item for the innermost header is postfixed with "_innermost_irregular", while the irregular chain item for outer IP headers is postfixed by "_outer_irregular". The format of the irregular chain item for the outer IP headers also determined using a flag for TTL/Hoplimit; this flag is defined in the format of some of the compressed base headers. 6.3. Compressing TCP Options with List Compression This section describes in details how list compression is applied to the TCP options. In the definition of the packet formats for ROHC- TCP, the most frequent type of TCP options are described. Each of these options has an uncompressed format, a format__list_item format and a format__irregular format, where is the name of the actual field item in the option list. 6.3.1. List Compression The TCP options in the uncompressed packet can be represented as an ordered list, whose order and presence are usually constant between packets. The generic structure of such a list is as follows: +--------+--------+--...--+--------+ list: | item 1 | item 2 | | item n | Pelletier, et al. Expires July 8, 2006 [Page 22] Internet-Draft ROHC-TCP January 2006 +--------+--------+--...--+--------+ The basic principles of list-based compression are the following: 1) When a context is being initialized, a complete representation of the compressed list of options is transmitted. All options that have any content are present in the compressed list of items sent to the decompressor. Then, once the context has been initialized: 2) When the structure AND the content of the list are not changing, no information about the list is sent in compressed headers. 3) When the structure of the list is constant, and when only the content of one or more options that are defined within the irregular format is changing, no information about the list needs to be sent in compressed headers; the irregular content is sent as part of the irregular chain (as described in Section 6.3.6 in the general compressed packet format (Section 7.3). 4) When the structure of the list changes, a compressed list is sent in the compressed header, including a representation of its structure and order. 6.3.2. Table-based Item Compression The Table-based item compression compresses individual items sent in compressed lists. The compressor assigns a unique identifier, "Index", to each item "Item" of a list. Compressor Logic The compressor conceptually maintains an Item Table containing all items, indexed using "Index". The (Index, Item) pair is sent together in compressed lists until the compressor gains enough confidence that the decompressor has observed the mapping between items and their respective index. Confidence is obtained from the reception of an acknowledgment from the decompressor, or by sending (Index, Item) pairs using the optimistic approach. Once confidence is obtained, the index alone is sent in compressed lists to indicate the presence of the item corresponding to this index. The compressor may reassign an existing index to a new item, by re-establishing the mapping using the procedure described above. Decompressor Logic Pelletier, et al. Expires July 8, 2006 [Page 23] Internet-Draft ROHC-TCP January 2006 The decompressor conceptually maintains an Item Table that contains all (Index, Item) pairs received. The Item Table is updated whenever an (Index, Item) pair is received and decompression is successfully verified using the CRC. The decompressor retrieves the item from the table whenever an Index without an accompanying Item is received. If an index without an accompanying item is received for which the value of the "Known" flag is zero, the header MUST be discarded and a NACK SHOULD be sent. 6.3.3. Encoding of Compressed Lists Each item present in a compressed list is represented by: o an index into the table of items, and o a bit indicating if a compressed representation of the item is present in the list. o an item (if the presence bit is set) If the presence bit is not set, the item must already be known by the decompressor. A compressed list of TCP options uses the following encoding: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Reserved |PS | m | +---+---+---+---+---+---+---+---+ | XI_1, ..., XI_m | m octets, or m * 4 bits / --- --- --- ---/ | : Padding : if PS = 0 and m is odd +---+---+---+---+---+---+---+---+ | | / item_1, ..., item_n / variable | | +---+---+---+---+---+---+---+---+ Reserved: Must be set to zero. PS: Indicates size of XI fields: PS = 0 indicates 4-bit XI fields; PS = 1 indicates 8-bit XI fields. m: Number of XI item(s) in the compressed list. Pelletier, et al. Expires July 8, 2006 [Page 24] Internet-Draft ROHC-TCP January 2006 XI_1, ..., XI_m: m XI items. Each XI represents one TCP option in the uncompressed packet, in the same order as they appear in the uncompressed packet. The format of an XI item is as follows: +---+---+---+---+ PS = 0: | X | Index | +---+---+---+---+ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ PS = 1: | X | Reserved | Index | +---+---+---+---+---+---+---+---+ X: Indicates whether the item present in the list: X = 1 indicates that the item corresponding to the Index is sent in the item_1, ..., item_n list; X = 0 indicates that the item corresponding to the Index is not sent. Reserved: Set to zero when sending, ignored when received. Index: An index into the item table. See Section 6.3.4 When 4-bit XI items are used and, the XI items are placed in octets in the following manner: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | XI_k | XI_k + 1 | +---+---+---+---+---+---+---+---+ Padding: A 4-bit padding field is present when PS = 0 and the number of XIs is odd. The Padding field is set to zero when sending and ignored when receiving. Item 1, ..., item n: Each item corresponds to an XI with X = 1 in XI 1, ..., XI m. Each entry in the item list is formatted as expressed by format__list_item in Section 8 . 6.3.4. Item Table Mappings The item table for TCP options list compression is limited to 16 different items, since it is unlikely that any packet stream will contain a larger number of unique options. Pelletier, et al. Expires July 8, 2006 [Page 25] Internet-Draft ROHC-TCP January 2006 The mapping between TCP option type and table indexes are listed in the table below: +-----------------+---------------+ | Option name | Table index | +-----------------+---------------+ | NOP | 0 | | EOL | 1 | | MSS | 2 | | WINDOW SCALE | 3 | | TIMESTAMP | 4 | | SACK-PERMITTED | 5 | | SACK | 6 | | Generic options | 7-15 | +-----------------+---------------+ Some TCP options are used more frequently than others. To simplify their compression, a part of the item table is reserved for these option types, as shown on the table above. The decompressor MUST use these mappings between item and indexes to decompress TCP options compressed using list compression. It is expected that the option types for which an index is reserved in the item table will only appear once in a list. However, if an option type is detected twice in the same options list and if both options have a different content, the compressor should compress the second occurrence of the option type by mapping it to a generic compressed option. Otherwise, if the options have the exact same content, the compressor can still use the same table index for both. The NOP option The NOP option can appear more than once in the list. However, since its value is always the same, no context information needs to be transmitted. Multiple NOP options can thus be mapped to the same index. Since the NOP option does not have any content when compressed as a list_item, it will never be present in the item list. For consistency, the compressor should still establish an entry in the list by setting the presence bit, as done for the other type of options. Note that list compression always preserves the original order of each item in the decompressed list, no matter if the item is present or not in the compressed list_item or if multiple items of the same type can be mapped to the same index, as for the NOP option. The EOL option Pelletier, et al. Expires July 8, 2006 [Page 26] Internet-Draft ROHC-TCP January 2006 The size of the compressed format for the EOL option can be larger than one octet, and it is defined so that it includes the option padding. This is because the EOL should terminate the parsing of the options, but it can also be followed by padding octets that all have the value zero. The Generic option The generic option can be used to compress any type of TCP option that do not have a reserved index in the item table. 6.3.5. Compressed Lists in Dynamic Chain A compressed list for TCP options that is part of the dynamic chain (e.g. in IR or IR-DYN packets) MUST have all its list items present, i.e. all x-bits in the XI list must be set. 6.3.6. Irregular Chain Items for TCP Options The list_item represents the option inside the compressed item list, and the irregular format is used for the option fields that are expected to change with each packet. When an item of the specified type is present in the current context, these irregular fields are present in each compressed packet, as part of the irregular chain. Since many of the TCP option types are expected to stay static for the duration of a flow, many of the irregular_formats are empty. The irregular chain for TCP options is structured analogously to the structure of the current TCP options in the uncompressed packet. If a compressed list is present in the compressed packet, then the irregular chain for TCP options MUST NOT contain irregular items for the list items that are transmitted inside the compressed list (i.e. items in the list that have the x-bit set in its xi). The items that are not present in the compressed list, but are present in the current list, MUST have their respective irregular items present in the irregular chain. 6.3.7. Replication of TCP Options The entire table of TCP options items is always replicated when using the IR-CR packet. In the IR-CR packet, the current list of options for the new flow is also transmitted as a compressed list in the IR-CR packet. 6.4. Profile-specific Encoding Methods This section defines encoding methods that are specific to this profile. These methods are used in the formal definition of the Pelletier, et al. Expires July 8, 2006 [Page 27] Internet-Draft ROHC-TCP January 2006 packet formats in Section 8. 6.4.1. inferred_ip_v4_header_checksum() This encoding method compresses the header checksum field of the IPv4 header. This checksum is defined in RFC 791 [RFC791] as follows: Header Checksum: 16 bits A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed. The checksum algorithm is: The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. As described above, the header checksum protects individual hops from processing a corrupted header. When almost all IP header information is compressed away, and when decompression is verified by a CRC computed over the original header for every compressed packet, there is no point in having this additional checksum; instead it can be regenerated at the decompressor side. The "inferred_ip_v4_header_checksum()" encoding method thus compresses the IPv4 header checksum down to a size of zero bit, i.e. no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field using the computation above. The compressor MAY use the header checksum to validate the correctness of the header before compressing it, to avoid compressing a corrupted header. 6.4.2. inferred_mine_header_checksum() This encoding method compresses the minimal encapsulation header checksum. This checksum is defined in RFC 2004 [RFC2004] as follows: Header Checksum Pelletier, et al. Expires July 8, 2006 [Page 28] Internet-Draft ROHC-TCP January 2006 The 16-bit one's complement of the one's complement sum of all 16-bit words in the minimal forwarding header. For purposes of computing the checksum, the value of the checksum field is 0. The IP header and IP payload (after the minimal forwarding header) are not included in this checksum computation. The "inferred_mine_header_checksum()" encoding method compresses the minimal encapsulation header checksum down to a size of zero bit, i.e. no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field using the above computation. The motivations for inferring this checksum are similar to the ones explained above in Section 6.4.1. The compressor MAY use the minimal encapsulation header checksum to validate the correctness of the header before compressing it, to avoid compressing a corrupted header. 6.4.3. inferred_ip_v4_length() This encoding method compresses the total length field of the IPv4 header. The total length field of the IPv4 header is defined in RFC 791 [RFC791] as follows: Total Length: 16 bits Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. The "inferred_ip_v4_length()" encoding method compresses the IPv4 header checksum down to a size of zero bit, i.e. no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression. 6.4.4. inferred_ip_v6_length() This encoding method compresses the payload length field in the IPv6 header. This length field is defined in RFC 2460 [RFC2460] as follows: Pelletier, et al. Expires July 8, 2006 [Page 29] Internet-Draft ROHC-TCP January 2006 Payload Length: 16-bit unsigned integer Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets. (Note that any extension headers present are considered part of the payload, i.e., included in the length count.) The "inferred_ip_v6_length()" encoding method compresses the payload length field of the IPv6 header down to a size of zero bit, i.e. no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression. 6.4.5. inferred_offset() This encoding method compresses the data offset field of the TCP header. The inferred_offset encoding method is used on the data offset field of the TCP header. This field is defined in RFC 793 as: Data Offset: 4 bits The number of 32 bit words in the TCP Header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits long. The "inferred_offset()" encoding method compresses the data offset field of the TCP header down to a size of zero bit, i.e. no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field by first decompressing the TCP options list, and by then setting: data offset = (options length / 4) + 5 Note: The equations above uses integer arithmetic. 6.4.6. Scaled TCP Sequence Number Encoding On some TCP streams, such as data transfers, the payload size will be constant over periods of time. For such streams, the TCP sequence number is bound to increase by multiples of the payload size between packets. ROHC-TCP provides a method to use scaled compression of the TCP sequence number to improve compression efficiency in such case. When scaling the TCP sequence number, the residue is the sequence Pelletier, et al. Expires July 8, 2006 [Page 30] Internet-Draft ROHC-TCP January 2006 number offset from a multiple of the payload size. The precondition for the compressor to start using this type of encoding is that the compressor must be confident that the decompressor has received a number of packets sufficient to establish the value of the residue of the scaling function. This confidence can be established by sending a number of packets that are compressed using an unscaled representation of the sequence numbers, when the payload size is constant. The compressor can then start using the scaled sequence number encoding, where the sequence number is first downscaled by the value of the payload size and then LSB encoded. Packets incoming to the compressor for which the value of the residue is different than the one that has previously been established MUST be sent in a compressed packet that carries the sequence number compressed using its unscaled representation, until a stable residue value can once again be established at the decompressor. Note that when the sequence number wraps around, the value of the residue of the scaling function is likely to change, even when the payload size remains constant. When this occurs, the compressor MUST reestablish the new residue value using the unscaled representation of the sequence number as described above. Note also that the scaling function applied to the TCP sequence number does not use an explicit scaling factor, such as the TS_STRIDE used in RFC 3095 [RFC3095]. Instead, the payload size is used as the scaling factor; as this value can be inferred from the length of the packet, there is no need to transmit this field explicitly. The expressions for compressing and decompressing the scaled sequence number are specified in the definitions of the packet format Section 8.2. 6.4.7. Scaled Acknowledgement Number Encoding Similar to the pattern exhibited by sequence numbers, the expected increase in the TCP Acknowledgment number will often be a multiple of the packet size. For the Sequence Number, the compression scheme can use the payload size of the packets as a scaling factor (see section 6.1.6 above). For the Acknowledgment Number, the scaling factor depends on the size of packets flowing in the opposite direction; this information might not be available to the compressor/decompressor pair. For this reason, ROHC-TCP uses an explicit scaling factor to compress the TCP Acknowledgment Number. Pelletier, et al. Expires July 8, 2006 [Page 31] Internet-Draft ROHC-TCP January 2006 For the compressor to use the scaled acknowledgment number encoding, it MUST first explicitly transmit the value of the scaling factor (ack_stride) to the decompressor, using one of the packet types that can carry this information. Once the value of the scaling factor is established, before using this scaled encoding the compressor must have enough confidence that the decompressor has successfully calculated the residue of the scaling function for the acknowledgment number. This is done the same way as for the scaled sequence number encoding (see Section 6.4.6 above). Once the compressor has gained enough confidence that both the value of the scaling factor and the value of the residue have been established in the decompressor, the compressor can start compressing packets using the scaled representation of the Acknowledgment Number. The compressor MUST NOT use the scaled acknowledgment number encoding with the value of the scaling factor (ack_stride) set to zero. The compressor MAY use the scaled acknowledgment number encoding; what value it will use as the scaling factor is up to the compressor implementation. In the case where there is a co-located decompressor processing packets of the same TCP flow in the opposite direction, the scaling factor for the acknowledgment numbers can be set to the same value as the scaling factor of the sequence numbers used for that flow. 6.5. CRC Calculations The 3-bit and 7-bit CRCs both cover the entire uncompressed header chain. Note that there is no separation between CRC-STATIC or CRC- DYNAMIC fields in ROHC-TCP, as opposed to profiles defined in [RFC3095]. 7. Packet Types (Normative) ROHC-TCP uses two different packet types: the Initialization and Refresh (IR) packet type, and the Compressed packet type (CO). Each packet type defines a number of packet formats: three packet formats are defined for the IR type, and two sets of ten base header formats are defined for the CO type with one additional format that is common to both sets. 7.1. Initialization and Refresh Packets (IR) ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets as defined in [RFC3095] (section 5.2.3. and 5.2.4. respectively). The 8-bit CRC is computed according to section 5.9.1 of [RFC3095]. Pelletier, et al. Expires July 8, 2006 [Page 32] Internet-Draft ROHC-TCP January 2006 Packet type: IR This packet type communicates the static part and the dynamic part of the context. For the ROHC-TCP IR packet, the value of the x bit must be set to one. It has the following format: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 1 | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / Static chain / variable length | | - - - - - - - - - - - - - - - - | | / Dynamic chain / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - CRC: 8-bit CRC, computed according to section 5.9.1 of [RFC3095]. Static chain: See Section 6.2. Dynamic chain: See Section 6.2. Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. Packet type: IR-DYN Pelletier, et al. Expires July 8, 2006 [Page 33] Internet-Draft ROHC-TCP January 2006 This packet type communicates the dynamic part of the context. The ROHC-TCP IR-DYN packet has the following format: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 0 0 | IR-DYN type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / Dynamic chain / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - CRC: 8-bit CRC, computed according to section 5.9.1 of [RFC3095]. Dynamic chain: See Section 6.2. Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. 7.2. Context Replication Packets (IR-CR) Context replication requires a dedicated IR packet format that uniquely identifies the IR-CR packet for the ROHC-TCP profile. This section defines the profile-specific part of the IR-CR packet [RFC4164]. Packet type: IR-CR This packet type communicates a reference to a base context along with the static and dynamic parts of the replicated context that differs from the base context. The ROHC-TCP IR-CR packet follows the general format of the ROHC CR Pelletier, et al. Expires July 8, 2006 [Page 34] Internet-Draft ROHC-TCP January 2006 packet, as defined in ROHC-CR [RFC4164], section 3.4.2. With consideration to the extensibility of the IR packet type defined in RFC 3095 [RFC3095], the ROHC-TCP profile supports context replication through the profile specific part of the IR packet. This is achieved using the bit (x) left in the IR packet header for "Profile specific information". For ROHC-TCP, this bit is defined as a flag indicating whether this packet is an IR packet or an IR-CR packet. For the ROHC-TCP IR-CR packet, the value of the x bit must be set to zero. The ROHC-TCP IR-CR has the following format: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 0 | IR-CR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | B | CRC7 | 1 octet +---+---+---+---+---+---+---+---+ : Reserved | Base CID : 1 octet, for small CID, if B=1 +---+---+---+---+---+---+---+---+ : : / Base CID / 1-2 octets, for large CIDs, : : if B=1 +---+---+---+---+---+---+---+---+ | | / Replicate chain / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - B: B = 1 indicates that the Base CID field is present. Pelletier, et al. Expires July 8, 2006 [Page 35] Internet-Draft ROHC-TCP January 2006 CRC7: The CRC over the original, uncompressed, header. This 7-bit CRC is computed according to section 3.4.1.1 of [RFC4164]. Replicate chain: See Section 6.2. Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. 7.3. Compressed Packets (CO) The ROHC-TCP CO packets communicate irregularities in the packet header. All CO packets carry a CRC and can update the context. The general format for a compressed TCP header is as follows: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and CID 1-15 +---+---+---+---+---+---+---+---+ | first octet of base header | (with type indication) +---+---+---+---+---+---+---+---+ : : / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs : : +---+---+---+---+---+---+---+---+ / remainder of base header / variable number of octets +---+---+---+---+---+---+---+---+ : : / Irregular Chain / variable : : --- --- --- --- --- --- --- --- : : / TCP Options Irregular Part / variable : : --- --- --- --- --- --- --- --- The base header in the figure above is the compressed representation of the innermost IP header and the TCP header in the uncompressed packet. The full set of base headers are described in Section 8. Irregular chain: See Section 6.2. TCP options irregular part: See Section 6.3.6. 8. Packet Formats (Normative) This section describes the set of compressed TCP/IP packet formats. Pelletier, et al. Expires July 8, 2006 [Page 36] Internet-Draft ROHC-TCP January 2006 The normative description of the packet formats is given using a formal notation, the ROHC-FN [ROHC-FN]. The formal description of the packet formats specifies all of the information needed to compress and decompress a header relative to the context. In particular, the notation provides a list of all the fields present in the uncompressed and compressed TCP/IP headers, and defines how to map from each uncompressed packet to its compressed equivalent and vice versa. See the ROHC-FN [ROHC-FN] for an explanation of the formal notation itself, and for a description of the encoding methods used to compress each of the fields in the TCP/IP header. Note that the formal definition of the packet formats for ROHC-TCP includes comments that follow a specific syntax. These comments, called annotations, make use of square brackets as delimiters; numbers in between the "[" and the "]" are used to provide additional information about the expected number of bits for the field(s) that appears as a right-hand operand. These are not normative in any way. 8.1. Design rationale for compressed base headers The compressed packet formats are defined as two separate sets: one set for the packets where the innermost IP header contains a sequential IP-ID (either network byte order or byte swapped), and one set for the packets without sequential IP-ID (either random, zero, or no IP-ID). These two sets of packet formats are referred to as the "sequential" and the "random" set of packet format. In addition, there is a common compressed packet that can be used regardless of the type of IP-ID behavior. This common packet can transmit rarely changing fields and also send the frequently changing field coded in variable lengths. The common packet format can also change the value of control fields such as IP-ID and ECN behavior. All compressed base headers contain a 3-bit CRC, unless they update control fields such as "ip_id_behavior" or "ecn_used" that affect the interpretation of subsequent packets. Packets that can modify these control fields will carry a 7-bit CRC instead. The encoding methods used in the compressed base headers are based on the following design criteria: o MSN Pelletier, et al. Expires July 8, 2006 [Page 37] Internet-Draft ROHC-TCP January 2006 Since the MSN is a number generated by the compressor, it only needs to be large enough to ensure robust operation and to accommodate a small amount of reordering [RFC4163]. Therefore, each compressed base header contains 4 bits of MSN and the LSB offset value is set to p=4 to handle a reordering depth of up to 4 packets. Additional guidance to improve performance when a larger amount of reordering is possible can be found in [RFC4224] o Sequence number ROHC-TCP has the capability to handle bulk data transfers efficiently, for which the sequence number is expected to increase by about 1460 bytes (which can be represented by 11 bits). For the compressed base headers to handle retransmissions (i.e. negative delta to the sequence number), the LSB interpretation interval must handle negative offsets about as large as positive offset, which means that one more bit is needed. Also, for ROHC-TCP to be robust to losses, two additional bits are added to the LSB encoding of the sequence number. This means that the base headers should contain at least 14 bits of LSB-encoded sequence number when present. According to the logic above, the LSB offset value p is set to be as large as the positive offset, i.e. p = 2^(k-1)-1, where k is the number of LSB-encoded bits that are transmitted in the base header. o Acknowledgment number The design criterion for the acknowledgment number is similar to that of the sequence number. However, often only every other data packet is acknowledged, which means that the expected delta value is twice as large as for sequence numbers. Therefore, at least 15 bits of acknowledgment number should be used in compressed base headers. Since the acknowledgment number is expected to constantly increase, and the only exception to this is packet reordering (either on the ROHC channel [RFC3759] or prior to the compression point), the negative offset for LSB encoding is set to be 25% of the total interval, i.e. p = 2^(k-2)-1. The offset value p has been set the same way as for the sequence number, i.e. p = 2^(k-1)-1. o Window Pelletier, et al. Expires July 8, 2006 [Page 38] Internet-Draft ROHC-TCP January 2006 The TCP window field is expected to increase in increments of similar size as the sequence number, and therefore the design criterion for the TCP window has been to send at least 14 bits when used. o IP-ID For the "sequential" set of packet formats, all the compressed base headers contains LSB encoded IP-ID offset bits. The requirement is that at least 3 bits of IP-ID should always be present, but it is preferable to use 4 to 7 bits. When k=3, p=1 and if k>3, then p=3 since the offset is expected to increase most of the time. Each set of packet formats contains nine different compressed base headers. The reason for having this large number of packets is that the TCP sequence number, TCP acknowledgment number, TCP window and MSN are frequently changing in a non-linear pattern. The design of the packet formats is derived from the field behavior analysis found in [TCP-BEH]. All of the compressed base headers transmit LSB-encoded MSN bits, the push flag and a CRC, and in addition to this, all the base headers in the sequential packet format set contains LSB encoded IP-ID bits. The following packet formats exist in both the sequential and random packet format sets: o Format 1: This packet format transmits changes to the TCP sequence number and its principal use should be on the downstream of a data transfer. o Format 2: This packet format transmits the TCP sequence number in scaled form, and will normally be used on the downstream of a data transfer where the payload size is constant for multiple packets. o Format 3: This packet format transmits changes in the TCP acknowledgment number, and will be used in the acknowledgment direction of data transfer. o Format 4: This packet format is similar to format 3, but sends a scaled TCP acknowledgment number. o Format 5: This packet format transmits both the TCP sequence number and the acknowledgment number, and should be particularly useful for streams that send data in both directions. Pelletier, et al. Expires July 8, 2006 [Page 39] Internet-Draft ROHC-TCP January 2006 o Format 6: This packet format is similar to format 5, but sends the TCP sequence number in scaled form, when the payload size is static for certain intervals in a data stream. o Format 7: This packet format transmits changes to both the TCP acknowledgment number and the TCP window, and is expected to be useful for the acknowledgment streams of data connections. o Format 8: This packet format is similar to format 7, but sends the TCP sequence number in scaled form to allow higher compression rates on streams with a constant payload size, o Format 9: This packet format is used to transmit changes to some of the more seldom changing fields in the streams, such as ECN behavior, RST/SYN/FIN flags, the TTL/Hop Limit and the TCP options list. This format carries a 7-bit CRC, since it can change the contents of the irregular chain in later packets. Note that this can be seen as a reduced form of the common packet format. o Common packet format: The common packet format can be used for all kinds of IP-ID behavior, and should be used when some of the more rarely changing fields in the IP or TCP header changes. Since this packet format can be used to change what set of packet formats is to be used for future packets, it carries a 7-bit CRC to reduce the probability of context corruption. This packet can basically change all the dynamic fields in the IP and TCP header, and it uses a large set of flags to provide information about which fields are present in the packet format. 8.2. Formal Definition in ROHC-FN % List of encoding methods that are expected to be predefined % by the FN: % irregular (length) === "predefined by FN"; static === "predefined by FN"; compressed_value (length, value) === "predefined by FN"; lsb (lsbs, offset) === "predefined by FN"; crc (b, p, i, d, l) === "predefined by FN"; uncompressed_value (length, value) === "predefined by FN"; % Encoding methods not specified in FN syntax: % inferred_ip_v4_header_checksum === "defined in Section 6.4.1"; inferred_mine_header_checksum === "defined in Section 6.4.2"; inferred_ip_v4_length === "defined in Section 6.4.3"; inferred_ip_v6_length === "defined in Section 6.4.4"; Pelletier, et al. Expires July 8, 2006 [Page 40] Internet-Draft ROHC-TCP January 2006 inferred_offset === "defined in Section 6.4.5"; list_tcp_options === "defined in Section 6.3.3"; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Constants %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% IP_ID_BEHAVIOR_SEQUENTIAL = 0; IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; IP_ID_BEHAVIOR_RANDOM = 2; IP_ID_BEHAVIOR_ZERO = 3; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Global control fields %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % The control fields here reside in the context and are persistent % between packets. Some of these (such as the sequence number % scaling/residue are never transmitted explicitly, but are inferred % from other values. % control_fields = ecn_used, %[ 1 ] msn, %[ 16 ] ip_inner_ecn, %[ 2 ] seq_number_scaled, %[ 32 ] seq_number_residue, %[ 32 ] ack_stride, %[ 16 ] ack_number_scaled, %[ 16 ] ack_number_residue; %[ 16 ] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % General structures %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% static_or_irreg32(flag) === { uc_format = field; %[ 32 ] co_format_irreg_enc = field, %[ 32 ] { let (flag == 1); field ::= irregular(32); }; co_format_static_enc = field, %[ 0 ] { let (flag == 0); field ::= static; }; Pelletier, et al. Expires July 8, 2006 [Page 41] Internet-Draft ROHC-TCP January 2006 }; static_or_irreg16(flag) === { uc_format = field; %[ 16 ] co_format_irreg_enc = field, %[ 16 ] { let (flag == 1); field ::= irregular(16); }; co_format_static_enc = field, %[ 0 ] { let (flag == 0); field ::= static; }; }; static_or_irreg8(flag) === { uc_format = field; %[ 8 ] co_format_irreg_enc = field, %[ 8 ] { let (flag == 1); field ::= irregular(8); }; co_format_static_enc = field, %[ 0 ] { let (flag == 0); field ::= static; }; }; variable_length_32_enc(flag) === { uc_format = field; %[ 32 ] co_format_not_present = field, %[ 0 ] { let(flag == 0); field ::= static; }; co_format_8_bit = field, %[ 8 ] { let(flag == 1); field ::= lsb(8, 63); Pelletier, et al. Expires July 8, 2006 [Page 42] Internet-Draft ROHC-TCP January 2006 }; co_format_16_bit = field, %[ 16 ] { let(flag == 2); field ::= lsb(16, 16383); }; co_format_32_bit = field, %[ 32 ] { let(flag == 3); field ::= irregular(32); }; }; variable_length_16_enc(flag) === { uc_format = field; %[ 16 ] co_format_not_present = field, %[ 0 ] { let(flag == 0); field ::= static; }; co_format_8_bit = field, %[ 8 ] { let(flag == 1); field ::= lsb(8, 63); }; co_format_16_bit = field, %[ 16 ] { let(flag == 2); field ::= irregular(16); }; }; optional32 (flag) === { uc_format = item; % 0 or 32 bits co_format_present = item, %[ 32 ] { let (flag == 1); item ::= irregular (32); }; co_format_not_present = item, %[ 0 ] { let (flag == 0); item ::= compressed_value (0, 0); Pelletier, et al. Expires July 8, 2006 [Page 43] Internet-Draft ROHC-TCP January 2006 }; }; lsb_7_or_31 === { uc_format = item; % 7 or 31 bits co_format_lsb_7 = discriminator, %[ 1 ] item, %[ 7 ] { discriminator ::= '0'; item ::= lsb (7, 8); }; co_format_lsb_31 = discriminator, %[ 1 ] item, %[ 31 ] { discriminator ::= '1'; item ::= lsb (31, 256); }; }; opt_lsb_7_or_31 (flag) === { uc_format = item; % 32 bits co_format_present = item, % 8 or 32 bits { let (flag == 1); item ::= lsb_7_or_31; }; co_format_not_present = item, %[ 0 ] { let (flag == 0); item ::= compressed_value (0, 0); }; }; crc3 (data_value, data_length) === { uc_format = ; co_format = crc_value, %[ 3 ] { crc_value ::= crc(3, 0x06, 0x07, data_value, data_length); }; }; Pelletier, et al. Expires July 8, 2006 [Page 44] Internet-Draft ROHC-TCP January 2006 crc7 (data_value, data_length) === { uc_format = ; co_format = crc_value, %[ 7 ] { crc_value ::= crc(7, 0x79, 0x7f, data_value, data_length); }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % IPv6 Destination options header %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ip_dest_opt === { uc_format = next_header, %[ 8 ] length, %[ 8 ] value; % n bits default_methods = { next_header ::= static; length ::= static; value ::= static; }; co_format_dest_opt_static = next_header, %[ 8 ] length, %[ 8 ] { next_header ::= irregular(8); length ::= irregular(8); }; co_format_dest_opt_dynamic = value, % n bits { value ::= irregular(length:uncomp_value * 64 + 48); }; co_format_dest_opt_replicate_0 = discriminator, %[ 8 ] { discriminator ::= '00000000'; }; co_format_dest_opt_replicate_1 = discriminator, %[ 8 ] length, %[ 8 ] value, % n bits { Pelletier, et al. Expires July 8, 2006 [Page 45] Internet-Draft ROHC-TCP January 2006 discriminator ::= '10000000'; length ::= irregular(8); value ::= irregular( length:uncomp_value * 64 + 48); }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % IPv6 Hop-by-Hop options header %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ip_hop_opt === { uc_format = next_header, %[ 8 ] length, %[ 8 ] value; % n bits default_methods = { next_header ::= static; length ::= static; value ::= static; }; co_format_hop_opt_static = next_header, %[ 8 ] length, %[ 8 ] { next_header ::= irregular(8); length ::= irregular(8); }; co_format_hop_opt_dynamic = value, % n bits { value ::= irregular(length:uncomp_value * 64 + 48); }; co_format_hop_opt_replicate_0 = discriminator, %[ 8 ] { discriminator ::= '00000000'; }; co_format_hop_opt_replicate_1 = discriminator, %[ 8 ] length, %[ 8 ] value, % n bits { discriminator ::= '10000000'; length ::= irregular(8); value ::= irregular( Pelletier, et al. Expires July 8, 2006 [Page 46] Internet-Draft ROHC-TCP January 2006 length:uncomp_value * 64 + 48); }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % IPv6 Routing header %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ip_rout_opt === { uc_format = next_header, %[ 8 ] length, %[ 8 ] value; % n bits default_methods = { next_header ::= static; length ::= static; value ::= static; }; co_format_rout_opt_static = next_header, %[ 8 ] length, %[ 8 ] value, % n bits { next_header ::= irregular(8); length ::= irregular(8); value ::= irregular(length:uncomp_value * 64 + 48); }; co_format_rout_opt_dynamic = { }; co_format_rout_opt_replicate_0 = discriminator, %[ 8 ] { discriminator ::= '00000000'; }; co_format_rout_opt_replicate_1 = discriminator, %[ 8 ] length, %[ 8 ] value, % n bits { discriminator ::= '10000000'; length ::= irregular(8); value ::= irregular(length:uncomp_value * 64 + 48); }; }; Pelletier, et al. Expires July 8, 2006 [Page 47] Internet-Draft ROHC-TCP January 2006 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % GRE Header %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% optional_checksum (flag_value) === { uc_format = value, % 0 or 16 bits reserved1; % 0 or 16 bits co_format_cs_present = value, %[ 16 ] reserved1, %[ 0 ] { let (flag_value == 1); value ::= irregular (16); reserved1 ::= uncompressed_value (16, 0); }; co_format_not_present = value, %[ 0 ] reserved1, %[ 0 ] { let (flag_value == 0); value ::= compressed_value (0, 0); reserved1 ::= compressed_value (0, 0); }; }; gre_proto === { uc_format = protocol; %[ 16 ] default_methods = { }; co_format_ether_v4 = discriminator, %[ 1 ] { discriminator ::= compressed_value (1, 0); protocol ::= uncompressed_value (16, 0x0800); }; co_format_ether_v6 = discriminator, %[ 1 ] { discriminator ::= compressed_value (1, 1); protocol ::= uncompressed_value (16, 0x86DD); }; }; gre === Pelletier, et al. Expires July 8, 2006 [Page 48] Internet-Draft ROHC-TCP January 2006 { uc_format = c_flag, %[ 1 ] r_flag, %[ 1 ] k_flag, %[ 1 ] s_flag, %[ 1 ] reserved0, %[ 9 ] version, %[ 3 ] protocol, %[ 16 ] checksum_and_res, % 0 or 32 bits key, % 0 or 32 bits sequence_number; % 0 or 32 bits default_methods = { c_flag ::= static; r_flag ::= static; k_flag ::= static; s_flag ::= static; reserved0 ::= uncompressed_value (9, 0); version ::= static; protocol ::= static; key ::= static; checksum_and_res ::= optional_checksum (c_flag:uncomp_value); }; co_format_gre_static = protocol, %[ 1 ] c_flag, %[ 1 ] r_flag, %[ 1 ] k_flag, %[ 1 ] s_flag, %[ 1 ] version, %[ 3 ] key, % 0 or 32 bits { protocol ::= gre_proto; c_flag ::= irregular (1); r_flag ::= irregular (1); k_flag ::= irregular (1); s_flag ::= irregular (1); version ::= irregular (3); key ::= optional32 (k_flag:uncomp_value); sequence_number ::= static; }; co_format_gre_dynamic = checksum_and_res, % 0 or 16 bits sequence_number, % 0 or 32 bits Pelletier, et al. Expires July 8, 2006 [Page 49] Internet-Draft ROHC-TCP January 2006 { sequence_number ::= optional32 (s_flag:uncomp_value); }; co_format_gre_replicate_0 = discriminator, %[ 8 ] checksum_and_res, % 0 or 16 bits sequence_number, % 0, 8 or 32 bits { discriminator ::= '00000000'; sequence_number ::= opt_lsb_7_or_31 (s_flag:uncomp_value); }; co_format_gre_replicate_1 = discriminator, %[ 8 ] c_flag, %[ 1 ] r_flag, %[ 1 ] k_flag, %[ 1 ] s_flag, %[ 1 ] reserved, %[ 1 ] version, %[ 3 ] checksum_and_res, % 0 or 16 bits key, % 0 or 32 bits sequence_number, % 0 or 32 bits { discriminator ::= '10000000'; c_flag ::= irregular (1); r_flag ::= irregular (1); k_flag ::= irregular (1); s_flag ::= irregular (1); reserved ::= '0'; version ::= irregular (3); key ::= optional32 (k_flag:uncomp_value); sequence_number ::= optional32 (s_flag:uncomp_value); }; co_format_gre_irregular = checksum_and_res, % 0 or 16 bits sequence_number, % 0, 8 or 32 bits { sequence_number ::= opt_lsb_7_or_31 (s_flag:uncomp_value); }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % MINE header %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Pelletier, et al. Expires July 8, 2006 [Page 50] Internet-Draft ROHC-TCP January 2006 mine === { uc_format = next_header, %[ 8 ] s_bit, %[ 1 ] res_bits, %[ 7 ] checksum, %[ 16 ] orig_dest, %[ 32 ] orig_src; % 0 or 32 bits default_methods = { next_header ::= static; s_bit ::= static; res_bits ::= static; checksum ::= inferred_mine_header_checksum; orig_dest ::= static; orig_src ::= static; }; co_format_mine_static = next_header, %[ 8 ] s_bit, %[ 1 ] res_bits, %[ 7 ] orig_dest, %[ 32 ] orig_src, % 0 or 32 bits { next_header ::= irregular (8); s_bit ::= irregular (1); res_bits ::= irregular (7); % include reserved - no benefit in removing them orig_dest ::= irregular (32); orig_src ::= optional32 (s_bit:uncomp_value); }; co_format_mine_dynamic = { }; co_format_mine_replicate_0 = discriminator, %[ 8 ] checksum, %[ 0 ] { discriminator ::= '00000000'; }; co_format_mine_replicate_1 = discriminator, %[ 8 ] s_bit, %[ 1 ] res_bits, %[ 7 ] orig_dest, %[ 32 ] orig_src, % 0 or 32 bits Pelletier, et al. Expires July 8, 2006 [Page 51] Internet-Draft ROHC-TCP January 2006 { discriminator ::= '10000000'; s_bit ::= irregular (1); res_bits ::= irregular (7); orig_dest ::= irregular (32); orig_src ::= optional32 (s_bit:uncomp_value); }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Authentication Header (AH) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ah === { uc_format = next_header, %[ 8 ] length, %[ 8 ] res_bits, %[ 16 ] spi, %[ 32 ] sequence_number, %[ 32 ] auth_data; % n bits default_methods = { next_header ::= static; length ::= static; res_bits ::= static; spi ::= static; sequence_number ::= static; auth_data ::= irregular (length:uncomp_value * 32 - 32); }; co_format_ah_static = next_header, %[ 8 ] length, %[ 8 ] spi, %[ 32 ] { next_header ::= irregular(8); length ::= irregular (8); spi ::= irregular (32); }; co_format_ah_dynamic = res_bits, %[ 16 ] sequence_number, %[ 32 ] auth_data, % n bits { res_bits ::= irregular (16); sequence_number ::= irregular (32); Pelletier, et al. Expires July 8, 2006 [Page 52] Internet-Draft ROHC-TCP January 2006 }; co_format_ah_replicate_0 = discriminator, %[ 8 ] sequence_number, % 8 or 32 bits auth_data, % n bits { discriminator ::= '00000000'; sequence_number ::= lsb_7_or_31; }; co_format_ah_replicate_1 = discriminator, %[ 8 ] length, %[ 8 ] res_bits, %[ 16 ] spi, %[ 32 ] sequence_number, %[ 32 ] auth_data, % n bits { discriminator ::= '10000000'; length ::= irregular (8); res_bits ::= irregular (16); spi ::= irregular (32); sequence_number ::= irregular (32); }; co_format_ah_irregular = sequence_number, % 8 or 32 bits auth_data, % n bits { sequence_number ::= lsb_7_or_31; }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % ESP header (NULL encrypted) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% esp_null === { uc_format = spi, %[ 32 ] sequence_number, %[ 32 ] next_header; %[ 8 ] default_methods = { spi ::= static; % % Next header will always be present in the trailer part, Pelletier, et al. Expires July 8, 2006 [Page 53] Internet-Draft ROHC-TCP January 2006 % but sometimes it will ALSO be present in the header % (static chain only). % nh_field ::= static; % Control field next_header ::= static; sequence_number ::= static; }; co_format_esp_static = nh_field, %[ 8 ] spi, %[ 32 ] { % identify next header assume next 96 bits skipped % to get to end of packet (i.e. this is anchored from % the end of the packet, not the start) % nh_field ::= compressed_value(8, next_header:uncomp_value); next_header ::= irregular (8); % At packet end! spi ::= irregular (32); }; co_format_esp_dynamic = sequence_number, %[ 32 ] { sequence_number ::= irregular (32); }; co_format_esp_replicate_0 = discriminator, %[ 8 ] sequence_number, % 8 or 32 bits { discriminator ::= '00000000'; sequence_number ::= lsb_7_or_31; }; co_format_esp_replicate_1 = discriminator, %[ 8 ] spi, %[ 32 ] sequence_number, %[ 32 ] { discriminator ::= '10000000'; spi ::= irregular (32); sequence_number ::= irregular (32); }; co_format_esp_irregular = sequence_number, % 8 or 32 bits { sequence_number ::= lsb_7_or_31; }; }; Pelletier, et al. Expires July 8, 2006 [Page 54] Internet-Draft ROHC-TCP January 2006 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Structures common for IPv4 and IPv6 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% irreg_tos_tc === { uc_format = tos_tc; %[ 6 ] co_format_tos_tc_present = tos_tc, %[ 6 ] { let(ecn_used:uncomp_value == 1); tos_tc ::= irregular (6); }; co_format_tos_tc_not_present = tos_tc, %[ 0 ] { let(ecn_used:uncomp_value == 0); tos_tc ::= static; }; }; ip_irreg_ecn === { uc_format = ip_ecn_flags; %[ 2 ] co_format_tc_present = ip_ecn_flags, %[ 2 ] { let(ecn_used:uncomp_value == 1); ip_ecn_flags ::= irregular (2); }; co_format_tc_not_present = ip_ecn_flags, %[ 0 ] { let(ecn_used:uncomp_value == 0); ip_ecn_flags ::= static; }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % IPv6 Header %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% fl_enc === { uc_format = flow_label; co_format_fl_zero = discriminator, %[ 1 ] flow_label, %[ 0 ] Pelletier, et al. Expires July 8, 2006 [Page 55] Internet-Draft ROHC-TCP January 2006 reserved, %[ 4 ] { discriminator ::= '0'; flow_label ::= uncompressed_value (20, 0); reserved ::= '0000'; }; co_format_fl_non_zero = discriminator, %[ 1 ] flow_label, %[ 20 ] { discriminator ::= '1'; flow_label ::= irregular (20); }; }; % The argument flag should only be used if this flag was set when % processing a compressed base header, if not, the flag should be % zero. ipv6 (ttl_irregular_chain_flag) === { uc_format = version, %[ 4 ] tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] flow_label, %[ 20 ] payload_length, %[ 16 ] next_header, %[ 8 ] ttl_hopl, %[ 8 ] src_addr, %[ 128 ] dst_addr; %[ 128 ] default_methods = { version ::= uncompressed_value (4, 6); tos_tc ::= static; ip_ecn_flags ::= static; flow_label ::= static; payload_length ::= inferred_ip_v6_length; next_header ::= static; ttl_hopl ::= static; src_addr ::= static; dst_addr ::= static; }; co_format_ipv6_static = version_flag, %[ 1 ] reserved, %[ 2 ] flow_label, % 5 or 21 bits next_header, %[ 8 ] Pelletier, et al. Expires July 8, 2006 [Page 56] Internet-Draft ROHC-TCP January 2006 src_addr, %[ 128 ] dst_addr, %[ 128 ] { version_flag ::= '1'; reserved ::= '00'; flow_label ::= fl_enc; next_header ::= irregular (8); src_addr ::= irregular(128); dst_addr ::= irregular(128); }; co_format_ipv6_dynamic = tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] ttl_hopl, %[ 8 ] { tos_tc ::= irregular (6); ip_ecn_flags ::= irregular (2); ttl_hopl ::= irregular (8); }; co_format_ipv6_replicate = tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] { tos_tc ::= irregular (6); ip_ecn_flags ::= irregular (2); }; co_format_ipv6_outer_irregular_without_ttl = tos_tc, % 0 or 6 bits ip_ecn_flags, % 0 or 2 bits { % for 'outer' headers only, irregular chain is required % tos_tc ::= irreg_tos_tc; ip_ecn_flags ::= ip_irreg_ecn; let(ttl_irregular_chain_flag == 0); }; co_format_ipv6_outer_irregular_with_ttl = tos_tc, % 0 or 6 bits ip_ecn_flags, % 0 or 2 bits ttl_hopl, %[ 8 ] { % for 'outer' headers only, irregular chain is required % tos_tc ::= irreg_tos_tc; ip_ecn_flags ::= ip_irreg_ecn; let(ttl_irregular_chain_flag == 1); Pelletier, et al. Expires July 8, 2006 [Page 57] Internet-Draft ROHC-TCP January 2006 ttl_hopl ::= irregular(8); }; % Note that the ECN bits are stored in the global control field % so that they can be output in TCP irregular chain. co_format_ipv6_innermost_irregular = { let(ip_inner_ecn:uncomp_value == ip_ecn_flags:uncomp_value); }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % IPv4 Header %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ip_id_enc_dyn (behavior) === { uc_format = ip_id; %[ 16 ] co_format_ip_id_seq = ip_id, %[ 16 ] { let ((behavior == 0) || (behavior == 1) || (behavior == 2)); % % In dynamic chain, but random, seq, and seq-swapped are 16 % bits % ip_id ::= irregular(16); }; co_format_ip_id_zero = ip_id, %[ 0 ] { let (behavior == 3); % % Zero IPID % ip_id ::= uncompressed_value (16, 0); }; }; ip_id_enc_irreg (behavior) === { uc_format = ip_id; %[ 16 ] co_format_ip_id_seq = ip_id, %[ 0 ] { Pelletier, et al. Expires July 8, 2006 [Page 58] Internet-Draft ROHC-TCP January 2006 let (behavior == 0); % sequential ip_id ::= static; % Nothing to send in irregular chain }; co_format_ip_id_seq_swapped = ip_id, %[ 0 ] { let (behavior == 1); % sequential-swapped ip_id ::= static; % Nothing to send in irregular chain }; co_format_ip_id_rand = ip_id, %[ 16 ] { let (behavior == 2); % random ip_id ::= irregular (16); }; co_format_ip_id_zero = ip_id, %[ 0 ] { let (behavior == 3); % zero ip_id ::= uncompressed_value (16, 0); }; }; ip_id_behavior_enc === { uc_format = ip_id_behavior; %[ 2 ] default_methods = { ip_id_behavior ::= irregular(2); }; co_format_sequential = ip_id_behavior, %[ 2 ] { let (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL); }; co_format_sequential_swapped = ip_id_behavior, %[ 2 ] { let (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); }; co_format_random = ip_id_behavior, %[ 2 ] { let (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM); Pelletier, et al. Expires July 8, 2006 [Page 59] Internet-Draft ROHC-TCP January 2006 }; co_format_zero = ip_id_behavior, %[ 2 ] { let (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO); }; }; % The argument flag should only be used if this flag was set when % processing a compressed base header, if not, the flag should be % zero. % ipv4 (ttl_irregular_chain_flag) === { uc_format = version, %[ 4 ] hdr_length, %[ 4 ] tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] length, %[ 16 ] ip_id, %[ 16 ] rf, %[ 1 ] df, %[ 1 ] mf, %[ 1 ] frag_offset, %[ 13 ] ttl_hopl, %[ 8 ] protocol, %[ 8 ] checksum, %[ 16 ] src_addr, %[ 32 ] dst_addr; %[ 32 ] control_fields = ip_id_behavior; %[ 2 ] default_methods = { version ::= static; hdr_length ::= uncompressed_value (4, 5); protocol ::= static; tos_tc ::= static; ip_ecn_flags ::= static; ttl_hopl ::= static; df ::= static; mf ::= uncompressed_value (1, 0); rf ::= static; frag_offset ::= uncompressed_value (13, 0); ip_id ::= uncompressed_value (16, 0); ip_id_behavior ::= static; src_addr ::= static; dst_addr ::= static; Pelletier, et al. Expires July 8, 2006 [Page 60] Internet-Draft ROHC-TCP January 2006 checksum ::= inferred_ip_v4_header_checksum; length ::= inferred_ip_v4_length; }; co_format_ipv4_static = version_flag, %[ 1 ] reserved, %[ 7 ] protocol, %[ 8 ] src_addr, %[ 32 ] dst_addr, %[ 32 ] { version_flag ::= '0'; reserved ::= '0000000'; protocol ::= irregular (8); src_addr ::= irregular(32); dst_addr ::= irregular(32); }; co_format_ipv4_dynamic = reserved, %[ 5 ] df, %[ 1 ] ip_id_behavior, %[ 2 ] tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] ttl_hopl, %[ 8 ] ip_id, % 0/16 bits { reserved ::= '00000'; % % compressor chooses behavior of IP-ID % ip_id_behavior ::= ip_id_behavior_enc; df ::= irregular (1); tos_tc ::= irregular (6); ip_ecn_flags ::= irregular (2); ttl_hopl ::= irregular (8); ip_id ::= ip_id_enc_dyn ( ip_id_behavior:uncomp_value); }; co_format_ipv4_replicate_0 = discriminator, %[ 8 ] ip_id, % 0 or 16 bits tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] { discriminator ::= '00000000'; ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg ( ip_id_behavior:uncomp_value); Pelletier, et al. Expires July 8, 2006 [Page 61] Internet-Draft ROHC-TCP January 2006 tos_tc ::= irregular (6); ip_ecn_flags ::= irregular (2); }; co_format_ipv4_replicate_1 = discriminator, %[ 5 ] df, %[ 1 ] ip_id_behavior, %[ 2 ] tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] ttl_hopl, %[ 8 ] ip_id, % 0/16 bits { discriminator ::= '10000'; df ::= irregular (1); tos_tc ::= irregular (6); ip_ecn_flags ::= irregular (2); ttl_hopl ::= irregular (8); % % compressor chooses behavior of IP-ID % 00 = sequential % 01 = sequential byteswapped % 10 = random % 11 = zero % ip_id_behavior ::= ip_id_behavior_enc; ip_id ::= ip_id_enc_dyn (ip_id_behavior:uncomp_value); }; co_format_ipv4_outer_irregular_without_ttl = ip_id, % 0 or 16 bits tos_tc, % 0 or 6 bits ip_ecn_flags, % 0 or 2 bits { ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg ( ip_id_behavior:uncomp_value); tos_tc ::= irreg_tos_tc; ip_ecn_flags ::= ip_irreg_ecn; let(ttl_irregular_chain_flag == 0); }; co_format_ipv4_outer_irregular_with_ttl = ip_id, % 0 or 16 bits tos_tc, % 0 or 6 bits ip_ecn_flags, % 0 or 2 bits ttl_hopl, %[ 8 ] Pelletier, et al. Expires July 8, 2006 [Page 62] Internet-Draft ROHC-TCP January 2006 { ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg ( ip_id_behavior:uncomp_value); tos_tc ::= irreg_tos_tc; ip_ecn_flags ::= ip_irreg_ecn; let(ttl_irregular_chain_flag == 1); ttl_hopl ::= irregular(8); }; % Note that the ECN bits are stored in the global control field % so that they can be output in TCP irregular chain. co_format_ipv4_innermost_irregular = ip_id, % 0 or 16 bits { ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg ( ip_id_behavior:uncomp_value); let(ip_inner_ecn:uncomp_value == ip_ecn_flags:uncomp_value); }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % TCP Options %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % EOL marks the end of the option list and, based on % the description in RFC 793 and the BSB TCP code, % nothing after this should be processed... % So, ignore everything after the EOL option % (according to 793 it must be 0) % % The length of the padding needs to be transmitted with the % compressed list since the length of the list can be unknown to % the decompressor. % tcp_opt_eol(nbits) === { uc_format = type, %[ 8 ] padding; % (nbits - 8) bits default_methods = { type ::= uncompressed_value (8, 0); pad_len ::= static; padding ::= uncompressed_value (nbits - 8, 0); Pelletier, et al. Expires July 8, 2006 [Page 63] Internet-Draft ROHC-TCP January 2006 }; co_format_eol_list_item = pad_len, % 8 bits padding, %[ 0 ] { pad_len ::= compressed_value(8, nbits - 8); }; co_format_eol_irregular = { let(nbits - 8 == pad_len:uncomp_value); }; }; tcp_opt_nop === { uc_format = type; %[ 8 ] default_methods = { type ::= uncompressed_value (8, 1); }; co_format_nop_list_item = { }; co_format_nop_irregular = { }; }; tcp_opt_mss === { uc_format = type, %[ 8 ] length, %[ 8 ] mss; %[ 16 ] default_methods = { type ::= uncompressed_value (8, 2); length ::= uncompressed_value (8, 4); mss ::= static; }; co_format_mss_list_item = mss, %[ 16 ] { mss ::= irregular (16); }; Pelletier, et al. Expires July 8, 2006 [Page 64] Internet-Draft ROHC-TCP January 2006 co_format_mss_irregular = { }; }; tcp_opt_wscale === { uc_format = type, %[ 8 ] length, %[ 8 ] wscale; %[ 8 ] default_methods = { type ::= uncompressed_value (8, 3); length ::= uncompressed_value (8, 3); wscale ::= static; }; co_format_wscale_list_item = wscale, %[ 8 ] { wscale ::= irregular (8); }; co_format_wscale_irregular = { }; }; ts_lsb === { uc_format = tsval; % % Few bits (7 and 14) bits can only increase, while the larger % formats allow decreasing timestamp to handle reordering before % the compression point. % co_format_tsval_7 = discriminator, %[ 1 ] tsval, %[ 7 ] { discriminator ::= '0'; tsval ::= lsb (7, -1); }; co_format_tsval_14 = discriminator, %[ 2 ] tsval, %[ 14 ] { discriminator ::= '10'; tsval ::= lsb (14, -1); Pelletier, et al. Expires July 8, 2006 [Page 65] Internet-Draft ROHC-TCP January 2006 }; co_format_tsval_21 = discriminator, %[ 3 ] tsval, %[ 21 ] { discriminator ::= '110'; tsval ::= lsb (21, 0x00040000); }; co_format_tsval_29 = discriminator, %[ 3 ] tsval, %[ 29 ] { discriminator ::= '111'; tsval ::= lsb (29, 0x04000000); }; }; tcp_opt_tsopt === { uc_format = type, %[ 8 ] length, %[ 8 ] tsval, %[ 32 ] tsecho; %[ 32 ] default_methods = { type ::= uncompressed_value (8, 8); length ::= uncompressed_value (8, 10); }; co_format_tsopt_list_item = tsval, %[ 32 ] tsecho, %[ 32 ] { tsval ::= irregular (32); tsecho ::= irregular (32); }; co_format_tsopt_irregular = tsval, % 8, 16, 24 or 32 bits tsecho, % 8, 16, 24 or 32 bits { tsval ::= ts_lsb; tsecho ::= ts_lsb; }; }; sack_var_length_enc (base) === { uc_format = sack_field; %[ 32 ] Pelletier, et al. Expires July 8, 2006 [Page 66] Internet-Draft ROHC-TCP January 2006 control_fields = sack_offset, %[ 32 ] { let (sack_offset:uncomp_value == sack_field:uncomp_value - base); let (sack_offset:uncomp_length == 32); let (sack_field:uncomp_length == 32); }; co_format_lsb_15 = discriminator, %[ 1 ] sack_offset, %[ 15 ] { discriminator ::= '0'; sack_offset ::= lsb (15, -1); }; co_format_lsb_22 = discriminator, %[ 2 ] sack_offset, %[ 22 ] { discriminator ::= '10'; sack_offset ::= lsb (22, -1); }; co_format_lsb_30 = discriminator, %[ 2 ] sack_offset, %[ 30 ] { discriminator ::= '11'; sack_offset ::= lsb (30, -1); }; }; tcp_opt_sack_block (prev_block_end) === { uc_format = block_start, %[ 32 ] block_end; %[ 32 ] co_format_0 = block_start, % 16, 24 or 32 bits block_end, % 16, 24 or 32 bits { block_start ::= sack_var_length_enc (prev_block_end); block_end ::= sack_var_length_enc (block_start); }; }; tcp_opt_sack(ack_value) === { % % The ACK value from the TCP header is needed as input parameter. % Pelletier, et al. Expires July 8, 2006 [Page 67] Internet-Draft ROHC-TCP January 2006 uc_format = type, %[ 8 ] length, %[ 8 ] block_1, %[ 64 ] block_2, % 0 or 64 bits block_3, % 0 or 64 bits block_4; % 0 or 64 bits default_methods = { length ::= static; type ::= uncompressed_value (8, 5); block_2 ::= uncompressed_value (0, 0); block_3 ::= uncompressed_value (0, 0); block_4 ::= uncompressed_value (0, 0); }; co_format_sack1_list_item = discriminator, block_1, { let(length:uncomp_value == 10); discriminator ::= '00000001'; block_1 ::= tcp_opt_sack_block (ack_value); }; co_format_sack2_list_item = discriminator, block_1, block_2, { let(length:uncomp_value == 18); discriminator ::= '00000010'; block_1 ::= tcp_opt_sack_block (ack_value); block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value); }; co_format_sack3_list_item = discriminator, block_1, block_2, block_3, { let(length:uncomp_value == 26); discriminator ::= '00000011'; block_1 ::= tcp_opt_sack_block (ack_value); block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value); block_3 ::= tcp_opt_sack_block (block_2_end:uncomp_value); }; co_format_sack4_list_item = discriminator, block_1, Pelletier, et al. Expires July 8, 2006 [Page 68] Internet-Draft ROHC-TCP January 2006 block_2, block_3, block_4, { let(length:uncomp_value == 34); discriminator ::= '00000100'; block_1 ::= tcp_opt_sack_block (ack_value); block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value); block_3 ::= tcp_opt_sack_block (block_2_end:uncomp_value); block_4 ::= tcp_opt_sack_block (block_3_end:uncomp_value); }; co_format_sack_unchanged_irregular = discriminator, block_1, block_2, block_3, block_4, { discriminator ::= '00000000'; block_1 ::= static; block_2 ::= static; block_3 ::= static; block_4 ::= static; }; co_format_sack1_irregular = discriminator, block_1, { let(length:uncomp_value == 10); discriminator ::= '00000001'; block_1 ::= tcp_opt_sack_block (ack_value); }; co_format_sack2_irregular = discriminator, block_1, block_2, { let(length:uncomp_value == 18); discriminator ::= '00000010'; block_1 ::= tcp_opt_sack_block (ack_value); block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value); }; co_format_sack3_irregular = discriminator, block_1, block_2, block_3, { Pelletier, et al. Expires July 8, 2006 [Page 69] Internet-Draft ROHC-TCP January 2006 let(length:uncomp_value == 26); discriminator ::= '00000011'; block_1 ::= tcp_opt_sack_block (ack_value); block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value); block_3 ::= tcp_opt_sack_block (block_2_end:uncomp_value); }; co_format_sack4_irregular = discriminator, block_1, block_2, block_3, block_4, { let(length:uncomp_value == 34); discriminator ::= '00000100'; block_1 ::= tcp_opt_sack_block (ack_value); block_2 ::= tcp_opt_sack_block (block_1_end:uncomp_value); block_3 ::= tcp_opt_sack_block (block_2_end:uncomp_value); block_4 ::= tcp_opt_sack_block (block_3_end:uncomp_value); }; }; tcp_opt_sack_permitted === { uc_format = type, %[ 8 ] length; %[ 8 ] default_methods = { type ::= uncompressed_value (8, 4); length ::= uncompressed_value (8, 2); }; co_format_sack_permitted_list_item = { }; co_format_sack_permitted_irregular = { }; }; tcp_opt_generic === { uc_format = type, %[ 8 ] length_msb, %[ 1 ] length_lsb, %[ 7 ] Pelletier, et al. Expires July 8, 2006 [Page 70] Internet-Draft ROHC-TCP January 2006 contents; % n bits control_fields = option_static, %[ 1 ] { let (option_static:uncomp_length == 1); }; default_methods = { type ::= static; % % lengths are always smaller than 128 % (i.e. the msb is always 0) % length_msb ::= uncompressed_value (1, 0); length_lsb ::= static; contents ::= static; }; co_format_generic_list_item = type, %[ 8 ] option_static, %[ 1 ] length_lsb, %[ 7 ] contents, % n bits { type ::= irregular (8); option_static ::= irregular (1); length_lsb ::= irregular (7); contents ::= irregular (length_len:uncomp_value * 8 - 16); }; % Used when context of option has option_static set to one % co_format_generic_irregular_static = { let(option_static:uncomp_value == 1); }; % An item that can change, but currently is unchanged % co_format_generic_irregular_stable = discriminator, %[ 8 ] { let(option_static:uncomp_value == 0); discriminator ::= '11111111'; }; % An item that can change, and has changed compared to context. % Length is not allowed to change here, since a length change is % most likely to cause new NOPs or an EOL length change. Pelletier, et al. Expires July 8, 2006 [Page 71] Internet-Draft ROHC-TCP January 2006 % co_format_generic_irregular_full = discriminator, %[ 8 ] contents, % n bits { let(option_static:uncomp_value == 0); discriminator ::= '00000000'; contents ::= irregular ( length_lsb:uncomp_value * 8 - 16); }; }; tcp_list_presence_enc(list_length, presence, ack_value) === { uc_format = tcp_options; co_format_list_not_present = tcp_options, %[ 0 ] { let (presence == 0); tcp_options ::= static; }; co_format_list_present = tcp_options, % 8 + n*8 bits { let (presence == 1); tcp_options ::= list_tcp_options; }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % TCP Header %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% port_replicate(flags) === { uc_format = port; %[ 16 ] co_format_port_static_enc = port, %[ 0 ] { let(flags == 0b00); port ::= static; }; co_format_port_lsb8 = port, %[ 8 ] { let(flags == 0b01); port ::= lsb (8, 64); }; Pelletier, et al. Expires July 8, 2006 [Page 72] Internet-Draft ROHC-TCP January 2006 co_format_port_irr_enc = port, %[ 16 ] { let(flags == 0b10); port ::= irregular (16); }; }; zero_or_irr16_enc(flag) === { uc_format = field; %[ 16 ] co_format_non_zero = field, %[ 16 ] { let(flag == 0); field ::= irregular (16); }; co_format_zero = field, %[ 0 ] { let(flag == 1); field ::= uncompressed_value (16, 0); }; }; ack_enc_dyn(flag) === { uc_format = ack_number; %[ 32 ] co_format_ack_non_zero = ack_number, %[ 32 ] { let(flag == 0); ack_number ::= irregular (32); }; co_format_ack_zero = ack_number, %[ 0 ] { let(flag == 1); ack_number ::= uncompressed_value (32, 0); }; }; tcp_ecn_flags_enc === { uc_format = tcp_ecn_flags; %[ 2 ] co_format_irreg = tcp_ecn_flags, %[ 2 ] { let(ecn_used:uncomp_value == 1); Pelletier, et al. Expires July 8, 2006 [Page 73] Internet-Draft ROHC-TCP January 2006 tcp_ecn_flags ::= irregular(2); }; co_format_unused = { let(ecn_used:uncomp_value == 0); tcp_ecn_flags ::= static; }; }; tcp_res_flags_enc === { uc_format = tcp_res_flags; %[ 4 ] co_format_irreg = tcp_res_flags, %[ 4 ] { let(ecn_used:uncomp_value == 1); tcp_res_flags ::= irregular(4); }; co_format_unused = { let(ecn_used:uncomp_value == 0); tcp_res_flags ::= uncompressed_value(4, 0); }; }; tcp_irreg_ip_ecn === { uc_format = ip_ecn_flags; %[ 2 ] co_format_tc_present = ip_ecn_flags, %[ 2 ] { let(ecn_used:uncomp_value == 1); ip_ecn_flags ::= compressed_value(2, ip_inner_ecn:uncomp_value); }; co_format_tc_not_present = ip_ecn_flags, %[ 0 ] { let(ecn_used:uncomp_value == 0); ip_inner_ecn ::= static; % Global control field ip_ecn_flags ::= compressed_value(0,0); % Nothing transmit }; }; rsf_index_enc === { Pelletier, et al. Expires July 8, 2006 [Page 74] Internet-Draft ROHC-TCP January 2006 uc_format = rsf_flag; %[ 3 ] co_format_none = rsf_idx, %[ 2 ] { rsf_idx ::= '00'; rsf_flag ::= uncompressed_value (3, 0x00); }; co_format_rst_only = rsf_idx, %[ 2 ] { rsf_idx ::= '01'; rsf_flag ::= uncompressed_value (3, 0x04); }; co_format_syn_only = rsf_idx, %[ 2 ] { rsf_idx ::= '10'; rsf_flag ::= uncompressed_value (3, 0x02); }; co_format_fin_only = rsf_idx, %[ 2 ] { rsf_idx ::= '11'; rsf_flag ::= uncompressed_value (3, 0x01); }; }; optional_2bit_padding(used_flag) === { uc_format = ; co_format_used = padding, %[ 2 ] { let(used_flag == 1); padding ::= compressed_value (2, 0x0); }; co_format_unused = padding, { let(used_flag == 0); padding ::= compressed_value (0, 0x0); }; }; tcp === { uc_format = src_port, %[ 16 ] Pelletier, et al. Expires July 8, 2006 [Page 75] Internet-Draft ROHC-TCP January 2006 dst_port, %[ 16 ] seq_number, %[ 32 ] ack_number, %[ 32 ] data_offset, %[ 4 ] tcp_res_flags, %[ 4 ] tcp_ecn_flags, %[ 2 ] urg_flag, %[ 1 ] ack_flag, %[ 1 ] psh_flag, %[ 1 ] rsf_flags, %[ 3 ] window, %[ 16 ] checksum, %[ 16 ] urg_ptr, %[ 16 ] options; % n bits default_methods = { src_port ::= static; dst_port ::= static; seq_number ::= static; ack_number ::= static; rsf_flags ::= static; psh_flag ::= irregular (1); urg_flag ::= static; ack_flag ::= uncompressed_value (1, 1); urg_ptr ::= static; window ::= static; checksum ::= irregular (16); tcp_ecn_flags ::= static; tcp_res_flags ::= static; }; co_format_tcp_static = src_port, %[ 16 ] dst_port, %[ 16 ] { src_port ::= irregular(16); dst_port ::= irregular(16); }; co_format_tcp_dynamic = ecn_used, %[ 1 ] ack_stride_zero, %[ 1 ] ack_zero, %[ 1 ] urp_zero, %[ 1 ] tcp_res_flags, %[ 4 ] tcp_ecn_flags, %[ 2 ] urg_flag, %[ 1 ] ack_flag, %[ 1 ] psh_flag, %[ 1 ] Pelletier, et al. Expires July 8, 2006 [Page 76] Internet-Draft ROHC-TCP January 2006 rsf_flags, %[ 3 ] msn, %[ 16 ] seq_number, %[ 32 ] ack_number, % 0 or 32 bits window, %[ 16 ] checksum, %[ 16 ] urg_ptr, % 0 or 16 bits ack_stride, % 0 or 16 bits options, % n bits { ecn_used ::= irregular (1); ack_stride_zero ::= irregular (1); ack_zero ::= irregular (1); urp_zero ::= irregular (1); ack_flag ::= irregular (1); urg_flag ::= irregular (1); psh_flag ::= irregular (1); tcp_ecn_flags ::= irregular (2); rsf_flags ::= irregular (3); tcp_res_flags ::= irregular (4); msn ::= irregular (16); seq_number ::= irregular (32); window ::= irregular (16); checksum ::= irregular (16); urg_ptr ::= zero_or_irr16_enc(urp_zero:comp_value); ack_number ::= ack_enc_dyn(ack_zero:comp_value); ack_stride ::= zero_or_irr16_enc( ack_stride_zero:comp_value); data_offset ::= uncompressed_value(4, data_offset_value); options ::= list_tcp_options; }; co_format_tcp_replicate = reserved, %[ 2 ] window_presence, %[ 1 ] list_present, %[ 1 ] src_port_presence, %[ 2 ] dst_port_presence, %[ 2 ] ack_presence, %[ 1 ] urp_presence, %[ 1 ] urg_flag, %[ 1 ] ack_flag, %[ 1 ] psh_flag, %[ 1 ] rsf_flags, %[ 2 ] ecn_used, %[ 1 ] msn, %[ 16 ] seq_number, %[ 32 ] src_port, % 0, 8 or 16 bits Pelletier, et al. Expires July 8, 2006 [Page 77] Internet-Draft ROHC-TCP January 2006 dst_port, % 0, 8 or 16 bits window, % 0 or 16 bits urg_point, % 0 or 16 bits ack_number, % 0 or 32 bits ecn_padding, % 0 or 2 bits tcp_res_flags, % 0 or 4 bits tcp_ecn_flags, % 0 or 2 bits options, % n bits { reserved ::= '00'; list_present ::= irregular (1); msn ::= irregular (16); urg_flag ::= irregular (1); ack_flag ::= irregular (1); psh_flag ::= irregular (1); rsf_flags ::= rsf_index_enc; ecn_used ::= irregular (1); src_port_presence ::= compressed_value(2, src_port_presence_value); dst_port_presence ::= compressed_value(2, dst_port_presence_value); src_port ::= port_replicate(src_port_presence_value); dst_port ::= port_replicate(dst_port_presence_value); seq_number ::= irregular(32); ack_presence ::= compressed_value(1, ack_presence_value); window_presence ::= compressed_value(1, window_presence_value); urp_presence ::= compressed_value(1, urg_presence_value); ack_number ::= static_or_irreg32(ack_presence_value); window ::= static_or_irreg16( window_presence_value); urg_point ::= static_or_irreg16(urp_presence_value); ecn_padding ::= optional_2bit_padding( ecn_used:comp_value); tcp_res_flags ::= tcp_res_flags_enc; tcp_ecn_flags ::= tcp_ecn_flags_enc; data_offset ::= uncompressed_value(4, data_offset_value); options ::= tcp_list_presence_enc ((data_offset_value - 5) * 32, list_present:comp_value, ack_number:uncomp_value); }; % ECN from innermost IP header is taken from global control field % co_format_tcp_irregular = ip_ecn_flags, % 0 or 2 bits tcp_res_flags, % 0 or 4 bits Pelletier, et al. Expires July 8, 2006 [Page 78] Internet-Draft ROHC-TCP January 2006 tcp_ecn_flags, % 0 or 2 bits checksum, %[ 16 ] { ip_ecn_flags ::= tcp_irreg_ip_ecn; tcp_ecn_flags ::= tcp_ecn_flags_enc; tcp_res_flags ::= tcp_res_flags_enc; checksum ::= irregular (16); }; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Structures used in compressed base headers %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% tos_tc_enc(flag) === { uc_format = tos_tc; %[ 6 ] co_format_static = tos_tc, %[ 0 ] { let (flag == 0); tos_tc ::= static; }; co_format_irreg = tos_tc, %[ 6 ] padding, %[ 2 ] { let (flag == 1); tos_tc ::= irregular(6); padding ::= compressed_value (2, 0); }; }; ip_id_lsb (behavior, k, p) === { uc_format = ip_id, %[ 16 ] { let (ip_id:uncomp_length == 16); }; co_format_nbo = ip_id_offset, % k bits { let (behavior == 0); let (ip_id_offset:uncomp_value == ip_id:uncomp_value - msn:uncomp_value); let (ip_id_offset:uncomp_length == 16); ip_id_offset ::= lsb (k, p); Pelletier, et al. Expires July 8, 2006 [Page 79] Internet-Draft ROHC-TCP January 2006 }; co_format_non_nbo = ip_id_offset, % k bits { let (behavior == 1); let (ip_id_nbo:uncomp_value == (ip_id:uncomp_value / 256) + (ip_id:uncomp_value & 255) * 256); let (ip_id_nbo:uncomp_length == 16); let (ip_id_offset:uncomp_value == ip_id_nbo:uncomp_value - msn:uncomp_value); let (ip_id_offset:uncomp_length == 16); ip_id_offset ::= lsb (k, p); }; }; dont_fragment(version) === { uc_format = df; %[ 1 ] co_format_v4 = df, %[ 1 ] { let (version == 4); df ::= irregular(1); }; co_format_v6 = df, { let (version == 6); df ::= compressed_value(1,0); }; }; % Structures for updating the scaling control fields. % seq_number_scaling(payload_size) === { uc_format = seq_number; co_format_no_payload = { let(payload_size == 0); let (seq_number_residue:uncomp_value == seq_number:uncomp_value); let (seq_number_scaled:uncomp_value == 0); Pelletier, et al. Expires July 8, 2006 [Page 80] Internet-Draft ROHC-TCP January 2006 }; co_format_with_payload = { let(payload_size != 0); let(seq_number_residue:uncomp_value == mod(seq_number:uncomp_value, payload_size)); let(seq_number:uncomp_value == seq_number_scaled:uncomp_value * payload_size + seq_number_residue:uncomp_value); }; } ack_number_scaling === { uc_format = ack_number; co_format_stride_not_set = { let(ack_stride:uncomp_value == 0); let (ack_number_residue:uncomp_value == ack_number:uncomp_value); let (ack_number_scaled:uncomp_value == 0); }; co_format_stride_set = { let(ack_stride:uncomp_value != 0); let(ack_number_residue:uncomp_value == mod(ack_number:uncomp_value, payload_size)); let(ack_number:uncomp_value == ack_number_scaled:uncomp_value * ack_stride:uncomp_value + ack_number_residue:uncomp_value); }; } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Actual start of compressed packet formats % Important note: % The base header is the compressed representation % of the innermost IP header AND the TCP header. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % ttl_irregular_chain_flag is an "output argument" that should be % passed to the processing of the irregular chain for outer Pelletier, et al. Expires July 8, 2006 [Page 81] Internet-Draft ROHC-TCP January 2006 % IP headers. % co_baseheader(payload_size, ttl_irregular_chain_flag) === { uc_format_v4 = version, %[ 4 ] header_length, %[ 4 ] tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] length, %[ 16 ] ip_id, %[ 16 ] rf, %[ 1 ] df, %[ 1 ] mf, %[ 1 ] frag_offset, %[ 13 ] ttl_hopl, %[ 8 ] next_header, %[ 8 ] checksum, %[ 16 ] src_addr, %[ 32 ] dest_addr, %[ 32 ] src_port, %[ 16 ] dest_port, %[ 16 ] seq_number, %[ 32 ] ack_number, %[ 32 ] data_offset, %[ 4 ] tcp_res_flags, %[ 4 ] tcp_ecn_flags, %[ 2 ] urg_flag, %[ 1 ] ack_flag, %[ 1 ] psh_flag, %[ 1 ] rsf_flags, %[ 3 ] window, %[ 16 ] tcp_checksum, %[ 16 ] urg_ptr, %[ 16 ] options_list, % n bits { let (version:uncomp_value == 4); }; uc_format_v6 = version, %[ 4 ] tos_tc, %[ 6 ] ip_ecn_flags, %[ 2 ] flow_label, %[ 20 ] payload_length, %[ 16 ] next_header, %[ 8 ] ttl_hopl, %[ 8 ] src_addr, %[ 128 ] dest_addr, %[ 128 ] src_port, %[ 16 ] Pelletier, et al. Expires July 8, 2006 [Page 82] Internet-Draft ROHC-TCP January 2006 dest_port, %[ 16 ] seq_number, %[ 32 ] ack_number, %[ 32 ] data_offset, %[ 4 ] tcp_res_flags, %[ 4 ] tcp_ecn_flags, %[ 2 ] urg_flag, %[ 1 ] ack_flag, %[ 1 ] psh_flag, %[ 1 ] rsf_flags, %[ 3 ] window, %[ 16 ] tcp_checksum, %[ 16 ] urg_ptr, %[ 16 ] options_list, % n bits { let (version:uncomp_value == 6); let (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM); }; control_fields = ip_id_behavior, % 2 bits { let (version:uncomp_length == 4); seq_number ::= seq_number_scaling(payload_size); ack_number ::= ack_number_scaling; }; default_methods = { version ::= static; tos_tc ::= static; ip_ecn_flags ::= static; ttl_hopl ::= static; next_header ::= static; src_addr ::= static; dest_addr ::= static; flow_label ::= static; payload_length ::= inferred_ip_v6_length; header_length ::= uncompressed_value (4,5); length ::= inferred_ip_v4_length; ip_id ::= irregular(16); ip_id_behavior ::= static; rf ::= static; df ::= static; mf ::= static; Pelletier, et al. Expires July 8, 2006 [Page 83] Internet-Draft ROHC-TCP January 2006 frag_offset ::= static; checksum ::= inferred_ip_v4_header_checksum; src_port ::= static; dest_port ::= static; seq_number ::= static; ack_number ::= static; data_offset ::= inferred_offset; tcp_ecn_flags ::= static; psh_flag ::= irregular (1); urg_flag ::= uncompressed_value (1, 0); ack_flag ::= uncompressed_value (1, 1); window ::= static; tcp_checksum ::= irregular(16); urg_ptr ::= static; rsf_flags ::= uncompressed_value (3, 0); tcp_res_flags ::= static; options_list ::= static; }; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Common compressed packet format %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% co_format_co_common = discriminator, %[ 7 ] ttl_hopl_outer_flag, %[ 1 ] ack_flag, %[ 1 ] psh_flag, %[ 1 ] rsf_flags, %[ 2 ] msn, %[ 4 ] seq_indicator, %[ 2 ] ack_indicator, %[ 2 ] ack_stride_indicator, %[ 1 ] window_indicator, %[ 1 ] ip_id_indicator, %[ 2 ] urg_ptr_present, %[ 1 ] ecn_used, %[ 1 ] tos_tc_present, %[ 1 ] ttl_hopl_present, %[ 1 ] list_present, %[ 1 ] ip_id_behavior, %[ 2 ] urg_flag, %[ 1 ] Pelletier, et al. Expires July 8, 2006 [Page 84] Internet-Draft ROHC-TCP January 2006 df, %[ 1 ] header_crc, %[ 7 ] seq_number, % 0, 8, 16, 32 bits ack_number, % 0, 8, 16, 32 bits ack_stride, % 0 or 16 bits window, % 0 or 16 bits ip_id, % 0, 8, 16 bits urg_ptr, % 0 or 16 bits tos_tc, % 0 or 8 bits ttl_hopl, % 0 or 8 bits options_list, % n bits { discriminator ::= '1111101'; ttl_hopl_outer_flag::= irregular(1); % % Need to bind argument so that user can pass it on to the % structure for IPv4/IPv6 irregular chain. % let(ttl_irregular_chain_flag == ttl_hopl_outer_flag:uncomp_value); tos_tc_present ::= irregular(1); ttl_hopl_present ::= irregular(1); ack_flag ::= irregular(1); psh_flag ::= irregular(1); msn ::= lsb (4, 3); df ::= dont_fragment(version:uncomp_value); header_crc ::= crc7(this:uncomp_value, this:uncomp_length); urg_flag ::= irregular(1); urg_ptr_present ::= irregular(1); ecn_used ::= irregular(1); list_present ::= irregular(1); ip_id_behavior ::= ip_id_behavior_enc; rsf_flags ::= rsf_index_enc; window_indicator ::= irregular(1); ip_id_indicator ::= irregular(2); seq_indicator ::= irregular(2); ack_indicator ::= irregular(2); ack_stride_indicator ::= irregular(1); seq_number ::= variable_length_32_enc( seq_indicator:comp_value); ack_number ::= variable_length_32_enc( Pelletier, et al. Expires July 8, 2006 [Page 85] Internet-Draft ROHC-TCP January 2006 ack_indicator:comp_value); ack_stride ::= static_or_irreg16( ack_stride_indicator:comp_value); window ::= static_or_irreg16( window_indicator:comp_value); ip_id ::= variable_length_16_enc( ip_id_indicator:comp_value); urg_ptr ::= static_or_irreg16(urg_ptr_present:comp_value); ttl_hopl ::= static_or_irreg8(ttl_hopl_present:comp_value); tos_tc ::= tos_tc_enc(tos_tc_present:comp_value); options_list ::= tcp_list_presence_enc ((data_offset:uncomp_value - 5) * 32, list_present:comp_value, ack_number:uncomp_value); }; % 0 1 2 3 4 5 6 7 % +---+---+---+---+---+---+---+---+ tho controls % | 1 1 1 1 1 0 1 |tho| irregular chain TTL/Hoplimit % +===+===+===+===+===+===+===+===+ % |ACK|PSH| RSF | MSN | % +---+---+---+---+---+---+---+---+ % | sn | a_sn |ast|win| ip_id | % +---+---+---+---+---+---+---+---+ % |urg|ecn|tos|ttl|lst|IPIDbeh|URG| % +---+---+---+---+---+---+---+---+ % |DF | CRC | % +---+---+---+---+---+---+---+---+ % / SN / 0, 8, 16, 32 bits, % --- --- --- --- --- --- --- --- indicated by sn % / ACK_SN / 0, 8, 16, 32 bits, % --- --- --- --- --- --- --- --- indicated by a_sn % / ACK_STRIDE / 0 or 16 bits, indicated by ast % --- --- --- --- --- --- --- --- % / WINDOW / 0 or 16 bits, indicated by win % --- --- --- --- --- --- --- --- % / IP-ID / 0, 8, 16 bits, indicated by ip_id % --- --- --- --- --- --- --- --- % / URG-PTR / 16 bits, if urg=1 % --- --- --- --- --- --- --- --- % / TOS / 8 bits, if tos=1 % --- --- --- --- --- --- --- --- % / TTL / 8 bits, if ttl=1 % --- --- --- --- --- --- --- --- % / options_list / n*8 bits, if lst=1 % --- --- --- --- --- --- --- --- % Send LSBs of sequence number Pelletier, et al. Expires July 8, 2006 [Page 86] Internet-Draft ROHC-TCP January 2006 % co_format_rnd_1 = discriminator, %[ 7 ] seq_number, %[ 17 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '1011110'; msn ::= lsb(4, 4); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); seq_number ::= lsb(16, 32767); }; % 0 1 2 3 4 5 6 7 % +---+---+---+---+---+---+---+---+ % | 1 0 1 1 1 1 0 |S..| % +===+===+===+===+===+===+===+===+ % | ..SN... | % +---+---+---+---+---+---+---+---+ % | ...SN | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send scaled sequence number LSBs % co_format_rnd_2 = discriminator, %[ 4 ] seq_number_scaled, %[ 4 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '1100'; msn ::= lsb(4, 4); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); seq_number_scaled ::= lsb(4, 7); seq_number_residue ::= static; }; Pelletier, et al. Expires July 8, 2006 [Page 87] Internet-Draft ROHC-TCP January 2006 % 0 1 2 3 4 5 6 7 % +---+---+---+---+---+---+---+---+ % | 1 1 0 0 | SN_SCALED | % +===+===+===+===+===+===+===+===+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send acknowledgement number LSBs % co_format_rnd_3 = discriminator, %[ 1 ] ack_number, %[ 15 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '0'; msn ::= lsb(4, 4); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); ack_number ::= lsb(15, 8191); }; % 0 1 2 3 4 5 6 7 % +---+---+---+---+---+---+---+---+ % | 0 | ACK_SN... | % +===+===+===+===+===+===+===+===+ % | ...ACK_SN | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send acknowledgement number scaled % co_format_rnd_4 = discriminator, %[ 4 ] ack_number_scaled, %[ 4 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '1101'; msn ::= lsb(4, 4); Pelletier, et al. Expires July 8, 2006 [Page 88] Internet-Draft ROHC-TCP January 2006 header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); ack_number_scaled ::= lsb(4, 3); ack_number_residue ::= static; }; % 0 1 2 3 4 5 6 7 % +---+---+---+---+---+---+---+---+ % | 1 1 0 1 | ACK_SN_SCALED | % +===+===+===+===+===+===+===+===+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send ACK and sequence number % co_format_rnd_5 = discriminator, %[ 3 ] psh_flag, %[ 1 ] msn, %[ 4 ] header_crc, %[ 3 ] seq_number, %[ 14 ] ack_number, %[ 15 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '100'; msn ::= lsb(4, 4); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); ack_number ::= lsb(15, 8191); seq_number ::= lsb(14, 8191); }; % 0 1 2 3 4 5 6 7 % +---+---+---+---+---+---+---+---+ % | 1 0 0 |PSH| MSN | % +===+===+===+===+===+===+===+===+ % | CRC | SN.. | % +---+---+---+---+---+---+---+---+ % | ...SN... | % +---+---+---+---+---+---+---+---+ % |..S| ACK_SN... | % +---+---+---+---+---+---+---+---+ % | ...ACK_SN | % +---+---+---+---+---+---+---+---+ Pelletier, et al. Expires July 8, 2006 [Page 89] Internet-Draft ROHC-TCP January 2006 % Send both ACK and scaled sequence number LSBs % co_format_rnd_6 = discriminator, %[ 5 ] header_crc, %[ 3 ] psh_flag, %[ 1 ] ack_number, %[ 15 ] msn, %[ 4 ] seq_number_scaled, %[ 4 ], { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '10110'; msn ::= lsb(4, 4); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); ack_number ::= lsb(15, 8191); seq_number_scaled ::= lsb(4, 7); seq_number_residue ::= static; }; % +---+---+---+---+---+---+---+---+ % | 1 0 1 1 0 | CRC | % +===+===+===+===+===+===+===+===+ % |PSH| ACK_SN... | % +---+---+---+---+---+---+---+---+ % | ...ACK_SN... | % +---+---+---+---+---+---+---+---+ % | MSN | SN_SCALED | % +---+---+---+---+---+---+---+---+ % Send ACK and window % co_format_rnd_7 = discriminator, %[ 7 ] ack_number, %[ 17 ] window, %[ 16 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '1011111'; msn ::= lsb(4, 4); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); Pelletier, et al. Expires July 8, 2006 [Page 90] Internet-Draft ROHC-TCP January 2006 ack_number ::= lsb(17, 32767); window ::= irregular(16); }; % +---+---+---+---+---+---+---+---+ % | 1 0 1 1 1 1 1 |A..| % +===+===+===+===+===+===+===+===+ % | | % + ..ACK_SN + % | | % +---+---+---+---+---+---+---+---+ % | | % + WINDOW + % | | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send scaled sequence number and window. % co_format_rnd_8 = discriminator, %[ 4 ] seq_number_scaled, %[ 4 ] window, %[ 14 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '1010'; msn ::= lsb(4, 4); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); window ::= irregular(16); seq_number_scaled ::= lsb(4, 3); seq_number_residue ::= static; }; % +---+---+---+---+---+---+---+---+ % | 1 0 1 0 | SN_SCALED | % +===+===+===+===+===+===+===+===+ % | | % + WINDOW + % | | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | Pelletier, et al. Expires July 8, 2006 [Page 91] Internet-Draft ROHC-TCP January 2006 % +---+---+---+---+---+---+---+---+ % A packet halfway between co_common and compressed packets % Can send LSBs of TTL, RSF flags, change ECN behavior and % options list % co_format_rnd_9 = discriminator, %[ 6 ] rsf_flags, %[ 2 ] list_present, %[ 1 ] header_crc, %[ 7 ] msn, %[ 4 ] psh_flag, %[ 1 ] ttl_hopl, %[ 3 ] ecn_used, %[ 1 ] seq_number, %[ 15 ] ack_number, %[ 16 ] options_list, % 0 or X bits { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_ZERO)); discriminator ::= '101110'; msn ::= lsb(4, 4); header_crc ::= crc7 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); list_present ::= irregular(1); options_list ::= tcp_list_presence_enc ((data_offset:uncomp_value - 5) * 32, list_present:comp_value, ack_number:uncomp_value); rsf_flags ::= rsf_index_enc; ecn_used ::= irregular(1); ttl_hopl ::= lsb(3, 3); seq_number ::= lsb(15, 16383); ack_number ::= lsb(16, 16383); }; % +---+---+---+---+---+---+---+---+ % | 1 0 1 1 1 0 | RSF | % +===+===+===+===+===+===+===+===+ % |lst| CRC | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| TTL | % +---+---+---+---+---+---+---+---+ % |ECN| SN... | % +---+---+---+---+---+---+---+---+ % | ..SN | Pelletier, et al. Expires July 8, 2006 [Page 92] Internet-Draft ROHC-TCP January 2006 % +---+---+---+---+---+---+---+---+ % | | % + ACK_SN + % | | % +---+---+---+---+---+---+---+---+ % / options_list / n*8 bits, if lst=1 % --- --- --- --- --- --- --- --- % Send LSBs of sequence number % co_format_seq_1 = discriminator, %[ 4 ] ip_id, %[ 4 ] seq_number, %[ 16 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '1010'; msn ::= lsb(4, 4); ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 4, 3); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); seq_number ::= lsb(16, 32767); }; % +---+---+---+---+---+---+---+---+ % | 1 0 1 0 | IP-ID | % +===+===+===+===+===+===+===+===+ % | | % + SN + % | | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send scaled sequence number LSBs % co_format_seq_2 = discriminator, %[ 5 ] ip_id, %[ 7 ] seq_number_scaled, %[ 4 ] msn, %[ 4 ] Pelletier, et al. Expires July 8, 2006 [Page 93] Internet-Draft ROHC-TCP January 2006 psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '11010'; msn ::= lsb(4, 4); ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 7, 3); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); seq_number_scaled ::= lsb(4, 7); seq_number_residue ::= static; }; % +---+---+---+---+---+---+---+---+ % | 1 1 0 0 1 | IP-ID... | % +===+===+===+===+===+===+===+===+ % | ...IP-ID | SN_SCALED | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send acknowledgement number LSBs % co_format_seq_3 = discriminator, %[ 4 ] ip_id, %[ 4 ] ack_number, %[ 16 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '1001'; msn ::= lsb(4, 4); ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 4, 3); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); Pelletier, et al. Expires July 8, 2006 [Page 94] Internet-Draft ROHC-TCP January 2006 ack_number ::= lsb(16, 16383); }; % +---+---+---+---+---+---+---+---+ % | 1 0 0 1 | IP-ID | % +===+===+===+===+===+===+===+===+ % | | % + ACK_SN + % | | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send scaled acknowledgement number scaled % co_format_seq_4 = discriminator, %[ 1 ] ack_number_scaled, %[ 4 ] ip_id, %[ 3 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '0'; msn ::= lsb(4, 4); % % Note that due to having very few ip_id bits, no reordering % offset % ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 3, 1); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); ack_number_scaled ::= lsb(4, 3); ack_number_residue ::= static; }; % +---+---+---+---+---+---+---+---+ % | 0 | ACK_SN_SCALED | IP-ID | % +===+===+===+===+===+===+===+===+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ Pelletier, et al. Expires July 8, 2006 [Page 95] Internet-Draft ROHC-TCP January 2006 % Send ACK and sequence number % co_format_seq_5 = discriminator, %[ 4 ] ip_id, %[ 4 ] ack_number, %[ 16 ] seq_number, %[ 16 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '1000'; msn ::= lsb(4, 4); ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 4, 3); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); ack_number ::= lsb(16, 16383); seq_number ::= lsb(16, 32767); }; % +---+---+---+---+---+---+---+---+ % | 1 0 0 0 | IP-ID | % +===+===+===+===+===+===+===+===+ % | | % + ACK_SN + % | | % +---+---+---+---+---+---+---+---+ % | | % + SN + % | | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send both ACK and scaled sequence number LSBs % co_format_seq_6 = discriminator, %[ 6 ] seq_number_scaled, %[ 4 ] ip_id, %[ 6 ] ack_number, %[ 16 ] msn, %[ 4 ] psh_flag, %[ 1 ] Pelletier, et al. Expires July 8, 2006 [Page 96] Internet-Draft ROHC-TCP January 2006 header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '110110'; seq_number_scaled ::= lsb(4, 7); seq_number_residue ::= static; ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 6, 3); ack_number ::= lsb(16, 16383); msn ::= lsb(4, 4); psh_flag ::= irregular (1); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); }; % +---+---+---+---+---+---+---+---+ % | 1 1 0 1 0 0 |SN_SC..| % +===+===+===+===+===+===+===+===+ % |..SN_SC| IP-ID | % +---+---+---+---+---+---+---+---+ % | | % + ACK_SN + % | | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send ACK and window % co_format_seq_7 = discriminator, %[ 4 ] window, %[ 15 ] ip_id, %[ 5 ] ack_number, %[ 16 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '1100'; msn ::= lsb(4, 4); Pelletier, et al. Expires July 8, 2006 [Page 97] Internet-Draft ROHC-TCP January 2006 ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 5, 3); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); ack_number ::= lsb(16, 32767); window ::= lsb(15, 16383); }; % +---+---+---+---+---+---+---+---+ % | 1 1 0 0 | WINDOW.. | % +===+===+===+===+===+===+===+===+ % | ..WINDOW.. | % +---+---+---+---+---+---+---+---+ % | ..WINDOW | IP-ID | % +---+---+---+---+---+---+---+---+ % | | % + ACK + % | | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % Send scaled sequence number and window. % co_format_seq_8 = discriminator, %[ 6 ] ip_id, %[ 6 ] seq_number_scaled, %[ 4 ] window, %[ 16 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '110111'; msn ::= lsb(4, 4); ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 6, 3); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); window ::= irregular(16); seq_number_scaled ::= lsb(4, 7); seq_number_residue ::= static; Pelletier, et al. Expires July 8, 2006 [Page 98] Internet-Draft ROHC-TCP January 2006 }; % +---+---+---+---+---+---+---+---+ % | 1 1 0 1 1 1 |IP-ID..| % +===+===+===+===+===+===+===+===+ % | ..IP-ID | SN_SCALED | % +---+---+---+---+---+---+---+---+ % | | % + WINDOW + % | | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| CRC | % +---+---+---+---+---+---+---+---+ % A packet halfway between co_common and compressed packets % Can send LSBs of TTL, RSF flags, change ECN behavior and % options list % co_format_seq_9 = discriminator, %[ 4 ] ip_id, %[ 4 ] list_present, %[ 1 ] header_crc, %[ 7 ] msn, %[ 4 ] psh_flag, %[ 1 ] ttl_hopl, %[ 3 ] ecn_used, %[ 1 ] ack_number, %[ 15 ] rsf_flags, %[ 2 ] seq_number, %[ 14 ] options_list, % Nx8 bits { let ((ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior:uncomp_value == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator ::= '1011'; msn ::= lsb(4, 4); ip_id ::= ip_id_lsb (ip_id_behavior:uncomp_value, 4, 3); header_crc ::= crc7 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); list_present ::= irregular(1); options_list ::= tcp_list_presence_enc ((data_offset:uncomp_value - 5) * 32, list_present:comp_value, ack_number:uncomp_value); Pelletier, et al. Expires July 8, 2006 [Page 99] Internet-Draft ROHC-TCP January 2006 rsf_flags ::= rsf_index_enc; ecn_used ::= irregular(1); ttl_hopl ::= lsb(3, 3); seq_number ::= lsb(14, 8191); ack_number ::= lsb(15, 8191); }; % +---+---+---+---+---+---+---+---+ % | 1 0 1 1 | IP-ID | % +===+===+===+===+===+===+===+===+ % |lst| CRC | % +---+---+---+---+---+---+---+---+ % | MSN |PSH| TTL | % +---+---+---+---+---+---+---+---+ % |ECN| ACK_SN... | % +---+---+---+---+---+---+---+---+ % | ..ACK_SN | % +---+---+---+---+---+---+---+---+ % | RSF | SN.. | % +---+---+---+---+---+---+---+---+ % | ..SN | % +---+---+---+---+---+---+---+---+ % / options_list / n*8 bits, if lst=1 % --- --- --- --- --- --- --- --- }; 8.3. Feedback Formats and Options 8.3.1. Feedback Formats This section describes the feedback format for ROHC-TCP. ROHC-TCP uses the ROHC feedback format described in section 5.2.2 of [RFC3095]. All feedback formats carry a field labelled SN. The SN field contains LSBs of the Master Sequence Number (MSN) described in Section 6.1.1. The sequence number to use is the MSN corresponding to the header that caused the feedback information to be sent. If that MSN cannot be determined, for example when decompression fails, the MSN to use is that corresponding to the latest successfully decompressed header. Pelletier, et al. Expires July 8, 2006 [Page 100] Internet-Draft ROHC-TCP January 2006 FEEDBACK-1 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | MSN | +---+---+---+---+---+---+---+---+ MSN: The lsb-encoded master sequence number. A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, FEEDBACK-2 must be used. FEEDBACK-2 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |Acktype| MSN | +---+---+---+---+---+---+---+---+ | MSN | +---+---+---+---+---+---+---+---+ / Feedback options / +---+---+---+---+---+---+---+---+ Acktype: 0 = ACK 1 = NACK 2 = STATIC-NACK 3 is reserved (MUST NOT be used for parsability) MSN: The lsb-encoded master sequence number. Feedback options: A variable number of feedback options, see Section 8.3.2. Options may appear in any order. 8.3.2. Feedback Options A ROHC-TCP Feedback option has variable length and the following general format: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type | Opt Len | +---+---+---+---+---+---+---+---+ / option data / Opt Len octets +---+---+---+---+---+---+---+---+ Each ROHC-TCP feedback option can appear at most once within a FEEDBACK-2. Pelletier, et al. Expires July 8, 2006 [Page 101] Internet-Draft ROHC-TCP January 2006 8.3.2.1. The CRC option The CRC option contains an 8-bit CRC computed over the entire feedback payload, without the packet type and code octet, but including any CID fields, using the polynomial of section 5.9.1 of [RFC3095]. If the CID is given with an Add-CID octet, the Add-CID octet immediately precedes the FEEDBACK-1 or FEEDBACK-2 format. For purposes of computing the CRC, the CRC fields of all CRC options are zero. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type = 1 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | CRC | +---+---+---+---+---+---+---+---+ When receiving feedback information with a CRC option, the compressor MUST verify the information by computing the CRC and comparing the result with the CRC carried in the CRC option. If the two are not identical, the feedback information MUST be ignored. 8.3.2.2. The REJECT option The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow. +---+---+---+---+---+---+---+---+ | Opt Type = 2 | Opt Len = 0 | +---+---+---+---+---+---+---+---+ When receiving a REJECT option, the compressor MUST stop compressing the packet stream, and SHOULD refrain from attempting to increase the number of compressed packet streams for some time. Any FEEDBACK packet carrying a REJECT option MUST also carry a CRC option. 8.3.2.3. The MSN-NOT-VALID option The MSN-NOT-VALID option indicates that the MSN of the feedback is not valid. A compressor MUST NOT use the MSN of the feedback to find the corresponding sent header when this option is present. +---+---+---+---+---+---+---+---+ | Opt Type = 3 | Opt Len = 0 | +---+---+---+---+---+---+---+---+ Pelletier, et al. Expires July 8, 2006 [Page 102] Internet-Draft ROHC-TCP January 2006 8.3.2.4. The MSN option The MSN option provides 2 additional bits of MSN. +---+---+---+---+---+---+---+---+ | Opt Type = 4 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | MSN | Reserved | +---+---+---+---+---+---+---+---+ 8.3.2.5. The LOSS option The LOSS option allows the decompressor to report the largest observed number of packets lost in sequence. +---+---+---+---+---+---+---+---+ | Opt Type = 7 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | longest loss event (packets) | +---+---+---+---+---+---+---+---+ The decompressor MAY choose to ignore the oldest loss events. Thus, the value reported may decrease. Since setting the reference window too small can reduce robustness, a FEEDBACK packet carrying a LOSS option SHOULD also carry a CRC option. The compressor MAY choose to ignore decreasing loss values. 8.3.2.6. The CONTEXT_MEMORY Feedback Option The CONTEXT_MEMORY option informs the compressor that the decompressor does not have sufficient memory resources to handle the context of the packet stream, as the stream is currently compressed. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type = 9 | Opt Len = 0 | +---+---+---+---+---+---+---+---+ When receiving a CONTEXT_MEMORY option, the compressor SHOULD take actions to compress the packet stream in a way that requires less decompressor memory resources, or stop compressing the packet stream. 8.3.2.7. Unknown option types If an option type unknown to the compressor is encountered, it must continue parsing the rest of the FEEDBACK packet, which is possible since the length of the option is explicit, but MUST otherwise ignore Pelletier, et al. Expires July 8, 2006 [Page 103] Internet-Draft ROHC-TCP January 2006 the unknown option. 9. Security Consideration A malfunctioning or malicious header compressor could cause the header decompressor to reconstitute packets that do not match the original packets but still have valid IP, and TCP headers and possibly also valid TCP checksums. Such corruption may be detected with end-to-end authentication and integrity mechanisms that will not be affected by the compression. Moreover, this header compression scheme uses an internal checksum for verification of reconstructed headers. This reduces the probability of producing decompressed headers not matching the original ones without this being noticed. Denial-of-service attacks are possible if an intruder can introduce (for example) bogus IR, CO or FEEDBACK packets onto the link and thereby cause compression efficiency to be reduced. However, an intruder having the ability to inject arbitrary packets at the link layer in this manner raises additional security issues that dwarf those related to the use of header compression. 10. IANA Considerations The ROHC profile identifier 0x00XX <# Editor's Note: To be replaced before publication #> has been reserved by the IANA for the profile defined in this document. <# Editor's Note: To be removed before publication #> A ROHC profile identifier must be reserved by the IANA for the profile defined in this document. Profiles 0x0000-0x0005 have previously been reserved, which means this profile could be 0x0006. As for previous ROHC profiles, profile numbers 0xnnXX must also be reserved for future updates of this profile. A suggested registration in the "RObust Header Compression (ROHC) Profile Identifiers" name space would then be: Profile Usage Document identifier 0x0006 ROHC TCP [RFCXXXX (this)] 0xnn06 Reserved Pelletier, et al. Expires July 8, 2006 [Page 104] Internet-Draft ROHC-TCP January 2006 11. Acknowledgements The authors would like to thank Qian Zhang, Hong Bin Liao, Richard Price and Fredrik Lindstroem for their work with early versions of this specification. Thanks also to Robert Finking and Carsten Borman for valuable input. Finally, thanks to Joe Touch for his thorough review and comments. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC4164] Pelletier, G., "Robust Header Compression (ROHC): Context Replication for ROHC profiles", RFC 4164, August 2005. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [ROHC-FN] Finking, R. and G. Pelletier, "Formal Notation for Robust Header Compression (ROHC-FN)", I-D draft-ietf-rohc-formal-notation-09.txt, June 2005. 12.2. Informative References [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, Pelletier, et al. Expires July 8, 2006 [Page 105] Internet-Draft ROHC-TCP January 2006 October 1996. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999. [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgment (SACK) Option for TCP", RFC 2883, July 2000. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004. [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A compression profile for IP", RFC 3843, June 2003. [RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005. [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, December 2005. [TCP-BEH] West, M. and S. McCann, "TCP/IP Field Behavior", I-D draft-ietf-rohc-tcp-field-behavior-04.txt, October 2004. Pelletier, et al. Expires July 8, 2006 [Page 106] Internet-Draft ROHC-TCP January 2006 Authors' Addresses Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden Phone: +46 (0) 8 404 29 43 Email: ghyslain.pelletier@ericsson.com Lars-Erik Jonsson Ericsson Box 920 Lulea SE-971 28 Sweden Phone: +46 (0) 8 404 29 61 Email: lars-erik.jonsson@ericsson.com Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden Phone: +46 (0) 8 404 41 58 Email: kristofer.sandlund@ericsson.com Mark A West Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hampshire SO51 0ZN UK Phone: +44 1794 833311 Email: mark.a.west@roke.co.uk URI: http://www.roke.co.uk Pelletier, et al. Expires July 8, 2006 [Page 107] Internet-Draft ROHC-TCP January 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pelletier, et al. Expires July 8, 2006 [Page 108]