Network Working Group Ghyslain Pelletier, Editor, Ericsson AB INTERNET-DRAFT Lars-Erik Jonsson, Ericsson AB Expires: January 2005 Mark A West, Siemens/Roke Manor Richard Price, Siemens/Roke Manor Kristofer Sandlund, Effnet July 16, 2004 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) Status of this memo By submitting this Internet-Draft, I (we) certify that any applicable patent or other IPR claims of which I am (we are) aware have been disclosed, and any of which I (we) become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, I (we) accept the provisions of Section #3 of RFC 3667 (BCP 78). 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF ROHC WG. Comments should be directed to the ROHC WG mailing list, rohc@ietf.org. Abstract 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. Pelletier, et al. [Page 1] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 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 (RFC 1144 [14], RFC 2507 [21]) have not addressed how to compress TCP options such as SACK (Selective Acknowledgements) (RFC 2018 [20], RFC 2883 [22]) and Timestamps (RFC 1323 [15]). Table of Contents 1. Introduction.....................................................3 2. Terminology......................................................4 3. Background.......................................................5 3.1. Existing TCP/IP Header Compression Schemes..................5 3.2. Classification of TCP/IP Header Fields......................6 3.3. Characteristics of Short-lived TCP Transfers................8 4. Overview of the TCP/IP Profile...................................9 4.1. General Concepts............................................9 4.2. Context Replication.........................................9 4.3. State Machines and Profile Operation........................9 4.4. Packet Formats and Encoding Methods.........................9 4.5. Irregular Chain.............................................9 4.6. TCP Options................................................10 4.6.1. Compressing TCP Options with List Compression.........10 4.6.1.1. List Compression.................................10 4.6.1.2. Table-based Item Compression.....................11 4.6.1.3. Item Tables......................................12 4.6.1.4. Constraints to List Compression..................13 4.6.2. Item Table Mappings...................................13 4.6.3. Replication of TCP Options............................14 4.6.4. Compressing Extension Headers.........................14 4.6.5. Explicit Congestion Notification (ECN) in TCP Headers.14 5. Compressor and decompressor State Machines......................15 5.1. Compressor States and Logic................................15 5.1.1. Initialization and Refresh (IR) State.................15 5.1.2. Compression (CO) State................................16 5.1.3. Feedback Logic........................................16 5.1.4. State Transition Logic................................16 5.1.4.1. Optimistic Approach, Upward Transition...........16 5.1.4.2. Optional Acknowledgements (ACKs), Upward Transition ..........................................................17 5.1.4.3. Timeouts, Downward Transition....................17 5.1.4.4. Negative ACKs (NACKs), Downward Transition.......17 5.1.4.5. Need for Updates, Downward Transition............17 5.1.5. State Machine Supporting Context Replication..........17 5.2. Decompressor States and Logic..............................18 5.2.1. No Context (NC) State.................................19 5.2.2. Static Context (SC) State.............................19 5.2.3. Full Context (FC) State...............................19 5.2.4. Allowing Decompression................................20 Pelletier, et. al [Page 2] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 5.2.5. Reconstruction and Verification.......................20 5.2.6. Actions upon CRC Failure..............................20 5.2.7. Feedback Logic........................................20 6. ROHC-TCP - TCP/IP Compression (Profile 0x0006)..................22 6.1. Considerations for the Feedback Channel....................22 6.2. Master Sequence Number (MSN)...............................22 6.3. CRC Calculations...........................................23 6.4. Initialization.............................................23 6.5. Packet Types...............................................23 6.5.1. Initialization and Refresh Packets (IR)...............24 6.5.2. Context Replication Packets (IR-CR)...................25 6.5.3. Compressed Packets (CO)...............................27 6.6. Packet Formats.............................................27 6.6.1. Extension Headers.....................................28 6.6.1.1. IPv6 DEST opt header.............................28 6.6.1.2. IPv6 HOP opt header..............................29 6.6.1.3. IPv6 Routing Header..............................30 6.6.1.4. GRE Header.......................................31 6.6.1.5. MINE header......................................35 6.6.1.6. Authentication Header (AH) header................37 6.6.1.7. Encapsulation Security Payload (ESP) header......38 6.6.2. IPv6 Header...........................................40 6.6.3. IPv4 Header...........................................42 6.6.4. TCP Header............................................47 6.6.5. TCP Options...........................................52 6.6.6. TCP/IP CO Packets.....................................62 6.6.7. Static Chain..........................................87 6.6.8. Dynamic Chain.........................................88 6.6.9. Irregular Chain.......................................88 6.6.10. Replication Chain....................................88 6.7. Feedback Formats and Options...............................89 6.7.1. Feedback Formats......................................89 6.7.2. Feedback Options......................................90 6.7.3. The CONTEXT_MEMORY Feedback Option....................90 7. Security Consideration..........................................90 8. IANA Considerations.............................................91 9. Acknowledgments.................................................91 10. Authors' Addresses.............................................92 11. References.....................................................93 11.1. Normative references......................................93 11.2. Informative References....................................93 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 [21]. Additional considerations that makes robustness an important objective for a TCP compression scheme are introduced in [10]. Finally, existing TCP/IP header compression schemes (RFC 1144 [14], RFC 2507 [21]) are limited in their handling Pelletier, et. al [Page 3] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 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 [20], RFC 2883 [22]) and Timestamps (RFC 1323 [15]). 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 [2], compliant with the requirements on ROHC TCP/IP header compression [10]. 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 [1]. This document reuses some of the terminology found in RFC 3095 [2]. 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 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 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 Pelletier, et. al [Page 4] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 useful for compression of multiple short-lived TCP connections that may be occurring simultaneously or near-simultaneously. ROHC Context Replication (ROHC-CR) "ROHC-CR" in this document normatively refers to the context replication mechanism for ROHC profiles defined in [3]. ROHC Formal Notation (ROHC-FN) "ROHC-FN" in this document normatively refers to the formal notation for ROHC profiles defined in [4], including the library of encoding methods it specifies. Short-lived TCP Transfer Short-lived TCP transfers refer to TCP connections transmitting only small amounts of data for each single connection. Short TCP flows seldom need to operate beyond the slow-start phase of TCP to complete their transfer, which also means that the transmission ends before any significant increase of the TCP congestion window may occur. 3. Background This chapter provides some background information on TCP/IP header compression. The fundamentals of general header compression may be found in [2]. 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 [11]. 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 [14]) 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 Pelletier, et. al [Page 5] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 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 [21]) improves somewhat on CTCP by augmenting the repair mechanism of CTCP with a local repair mechanism called TWICE and with a link-level 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 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 link. 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 [11]. The main conclusion is that most of the header fields can easily be compressed away since they never or seldom change. The following fields do however require more sophisticated mechanisms: - IPv4 Identification (16 bits) - IP-ID - TCP Sequence Number (32 bits) - SN - TCP Acknowledgement Number (32 bits) - ACKN Pelletier, et. al [Page 6] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 - TCP Reserved (4 bits) - TCP ECN flags (2 bits) - ECN - TCP Window (16 bits) - WINDOW - TCP Options - Maximum Segment Size (4 octets) - MSS - Window Scale (3 octets) - WSopt - SACK Permitted (2 octets) - TCP SACK - SACK - TCP Timestamp (32 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. However, designers of IPv4 stacks for cellular terminals should use an assignment policy close to Sequential. Some IPv4 stacks do use a sequential assignment when generating IP-ID values but do not transmit the contents 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 3095 [2], the IP-ID is generally inferred from the RTP Sequence Number. However, with respect to TCP compression, the analysis in [11] reveals that there is no obvious candidate to this purpose among the TCP fields. The change pattern of several TCP fields (Sequence Number, Acknowledgement Number, Window, etc.) is very hard to predict and differs entirely from the behavior of RTP fields discussed in [2]. Of particular importance to a TCP/IP header compression scheme is the understanding of the sequence and acknowledgement number [11]. 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 bound the jumps in acknowledgement number. Another important behavior of the TCP/IP header is the dependency between the sequence number and the acknowledgment number. It is well known that most TCP connections only 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 acknowledgement number remains constant for most packets; on the backward path (from client to server), only the sequence number is changing and the acknowledgement number remains constant for most packets. With respect to TCP options, it is noted that most options (such as MSS, WSopt, SACK-permitted, etc.) may appear only on a SYN segment. Every implementation should (and we expect most will) ignore unknown options on SYN segments. Pelletier, et. al [Page 7] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 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 [2]. 3.3. Characteristics of Short-lived TCP Transfers Recent studies shows that the majority of TCP flows are short-lived transfers with an average and a median size no larger than 10KB. Short-lived TCP transfers will degrade the performance of header compression schemes that establish a new context by initially sending full headers. It is hard to improve the performance for a single, unpredictable, short-lived connection. However, there are common cases where there will be multiple TCP connections between the same pair of hosts. A mobile user browsing several web pages from the same web server (this is more the case with HTTP/1.0 than HTTP/1.1) is one example. In such case, multiple short-lived TCP/IP flows occur simultaneously or near simultaneously within a relatively short time interval. It may be expected that most (if not all) of the IP header of the these connections will be almost identical to each other, with only small relative jumps for the IP-ID field. Furthermore, a subset of the TCP fields may also be very similar from one connection to another. For example, one of the port numbers may be reused (the service port) while the other (the ephemeral port) may be changed only by a small amount relative to the just-closed connection. With regard to header compression, this means that parts of a compression context used for a TCP connection may be reusable for another TCP connection. A mechanism supporting context replication, where a new context is initialized from an existing one, provide useful optimizations for a sequence of short-lived TCP connections. Context replication is possible due to the fact that there is much similarity in header field values and context values among multiple simultaneous or near simultaneous connections. All header fields and related context values have been classified in detail in [11]. The main 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 [Page 8] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 4. Overview of the TCP/IP Profile 4.1. General Concepts Many of the concepts behind the ROHC-TCP profile are similar to those described in RFC 3095 [2]. Like for other ROHC profiles, ROHC-TCP makes use of the ROHC protocol as described in [2], in sections 5.1 to 5.2.6. This includes data structures, reserved packet types, general packet formats, segmentation and initial decompressor processing. 4.2. Context Replication For ROHC-TCP, context replication may be particularly useful for short-lived TCP flows [10]. ROHC-TCP therefore supports context replication as defined in ROHC-CR [3]; the compressor MAY support context replication, while a decompressor implementation is REQUIRED to support decompression of the IR-CR packet type. 4.3. State Machines and Profile Operation Header compression with ROHC can be characterized as an interaction between two state machines, one compressor machine and one decompressor machine, each instantiated once per context. For ROHC-TCP compression, the compressor has two states and the decompressor has three states. The two compressor states are the Initialization and Refresh (IR) state, and the Compression (CO) state. The three states of the decompressor are No Context (NC), Static Context (SC) and Full Context (FC). The compressor may also implement a third state, the Context Replication (CR) state, to support context replication ROHC-CR [3]. Transitions need not be synchronized between the two state machines. 4.4. Packet Formats and Encoding Methods The packet formats used for ROHC-TCP and found in this document 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 [4]. 4.5. 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 [2]. Pelletier, et. al [Page 9] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 This irregular chain handles fields of tunneling headers and of extension headers, for which the change pattern is classified as IRREGULAR and that have to be sent in each compressed packet. 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 6.5.3). Note that the TCP header and the innermost IP header are not a part of the irregular chain. This is because the irregular fields of these headers are included in the base header of the compressed packet. <# Editor's Note: Should we add TCP checksum to irregular chain? #> 4.6. TCP Options 4.6.1. Compressing TCP Options with List Compression The options in the TCP header are compressed using list compression as defined by the ROHC-FN [4]. The following subsections explain how this encoding is applied to the TCP options in more details. 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 list_item format and an irregular format. 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. These irregular fields are present in each compressed packet, as part of the irregular chain. 4.6.1.1. List Compression The TCP options in the uncompressed packet can be structured as an ordered list, whose order and presence are most of the time constant between packets. The generic structure of such a list is as follows: +--------+--------+--...--+--------+ list: | item 1 | item 2 | | item n | +--------+--------+--...--+--------+ 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. Pelletier, et. al [Page 10] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 2) While 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; the irregular content is sent as part of the irregular chain in the general compressed packet format (section 6.5.3). 4) When the structure of the list changes, a compressed list is sent, including a representation of its structure and order. 4.6.1.2. Table-based Item Compression The Table-based item compression compressses individual items sent in compressed lists. The compressor assigns a unique identifier "Index" to each "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 by receiving an acknowledgment from the decompressor or by sending L (Index, Item) pairs (not necessarily consecutively). The value for L is maintained by the compressor. After such confidence is obtained, the Index alone is sent in compressed lists to indicate the corresponding Item. The compressor may reassign an existing Index to a new item, and then needs to re-establish the mapping as described above. Decompressor Logic 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 sucessfully verified usng the CRC. The decompressor retrieves the item from the table whenever an Index without an accompanying Item is received. Pelletier, et. al [Page 11] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 4.6.1.3. Item Tables Compressor Logic The compressor uses the following structure to represent an entry in the Item Table: +-------+------+---------+--------------------------+ Index i | Known | Item | Counter | MSN_1, MSN_2, ..., MSN_L | +-------+------+---------+--------------------------+ The flag "Known" indicates whether the mapping between Index i and Item has been established, i.e., if Index i can be sent in compressed lists without its corresponding Item. The "Counter" field is useful to obtain confidence that the context at the decompressor contains the (Index, Item) pair. The list of sequence numbers, [MSN 1, ..., MSN L], is useful in relating an acknowledgment received from the decompressor with the (Index, Item) pair, meaning that it is now part of the decompressor context. The flag "Known" is initially set to a value of zero. It is also set to zero whenever Index i is assigned to a new Item. "Known" is set to a non-zero value when either of the following conditions occur: a) The corresponding (Index, Item) pair is acknowledged; b) Counter >= L (confidence based of the optimistic approach). When the compressor sets the flag "Known", the sequence number list can be discarded. Decompressor Logic The decompressor uses the following structure to represent an entry in the Item Table: +-------+------+ Index i | Known | item | +-------+------+ The flag "Known" is initially set to a value of zero. "Known" is set to a non-zero value when the decompressor receives an (Index, Item) pair and inserts the Item into the table at position Index. 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. Pelletier, et. al [Page 12] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 4.6.1.4. Constraints to List Compression List compression, as defined in the ROHC-FN [4], allows 7-bit indexes to be used in the Item table. For ROHC-TCP, the compressor MUST use the low-order 4 bits of the item count (i.e. large_xi of [4], section 5.5.5) to describe an index. In other words, the compressor MUST NOT map items with indexes larger than a value of 15. This is because no more than 16 different options are expected to be used in a TCP flow. 4.6.2. Item Table Mappings 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. The compressor can thus omit from the compressed packet format an option type that corresponds to a reserved item in the item table. This is because the type of the option can be known based on the index number. 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 occurence 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 Pelletier, et. al [Page 13] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 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 consistence, the compressor should still established an entry in the list by setting the presence bit, like for the other type of options. The EOL option The size of the compressed format for the EOL option can be of more than one octets, 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 of undefined format. The Generic option The generic option can be used to compress any type of TCP options, in particular those that do not have a reserved index in the item table. 4.6.3. Replication of TCP Options TCP options can be replicated. When parts (or all) of the options are replicated, the entire item table in the context is replicated. The list of options for the new flow is then transmitted as a generic compressed list, like for other compressed packets. 4.6.4. Compressing Extension Headers In RFC 3095 [2], list compression is used to compress extension headers. ROHC-TCP compresses the same type of extension headers. However, these headers are treated exactly as other headers and thus have a static chain, a dynamic chain as well as an irregular chain (see also section 4.5 above). 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.6.5. Explicit Congestion Notification (ECN) in TCP Headers When the ECN is used in the TCP headers, the TOC/TC fields of all IP headers in this flow must be sent uncompressed in all packets. This is because of the possible use of the "full-functionality option" of section 9.1 of RFC 3168 [23]. Pelletier, et. al [Page 14] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 5. Compressor and decompressor State Machines The header compression state machines and their associated logic as specified in this section are a simplified version of the ones found in [2]. 5.1. Compressor States and Logic The two compressor states are the Initialization and Refresh (IR) state, and the Compression (CO) state. The compressor always starts in the lower compression state (IR). The compressor will normally operate in the higher compression state (CO), under the constraint that the compressor is sufficiently confident that the decompressor has the information necessary to reconstruct a header compressed according to this state. The figure below shows the state machine for the compressor. The details of each state, state transitions, and compression logic are given in sub-sections following the figure. Optimistic approach / ACK ACK +------>------>------>------+ +->-+ | | | | | v | v +----------+ +----------+ | IR State | | CO State | +----------+ +----------+ ^ | | Timeout / NACK / STATIC-NACK | +-------<-------<-------<--------+ The transition from IR state to CO state is based on the following principles: the need for update and the optimistic approach principle or, if a feedback channel is established, feedback received from the decompressor. 5.1.1. Initialization and Refresh (IR) State The purpose of the IR state is to initialize the static parts of the context at the decompressor or to recover after failure. In this state, the compressor sends complete header information. This includes static and non-static fields in uncompressed form plus some additional information. The compressor stays in the IR state until it is fairly confident that the decompressor has received the static information correctly. Pelletier, et. al [Page 15] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 5.1.2. Compression (CO) State The purpose of the CO state is to efficiently communicate irregularities in the packet stream when needed while maintaining the most optimal compression ratio. When operating in this state, the compressor normally sends most or all of the information in a compressed form. 5.1.3. Feedback Logic The compressor state machine makes use of feedback from decompressor to compressor for transitions in the backward direction, and optionally to improve the forward transition. The reception of either positive feedback (ACKs) or negative feedback (NACKs) establishes the feedback channel from the decompressor. Once there is an established feedback channel, the compressor makes use of this feedback for optionally improving the transitions among different states. This helps increasing the compression efficiency by providing the information needed for the compressor to achieve the necessary confidence level. When the feedback channel is established, it becomes superfluous for the compressor to send periodic refreshes. 5.1.4. State Transition Logic The compressor makes its decisions about when to transit between the IR and the CO states on the basis of: - variations in the packet headers - positive feedback from decompressor (Acknowledgements -- ACKs) - negative feedback from decompressor (Negative ACKS -- NACKs) - confidence level regarding error-free decompression of a packet 5.1.4.1. Optimistic Approach, Upward Transition Transition to the CO state is carried out according to the optimistic approach principle. This means that the compressor transits to the CO state when it is fairly confident that the decompressor has received enough information to correctly decompress packets sent according to the higher compression state. In general, there are many approaches where the compressor can obtain such information. A simple and general approach can be achieved by sending uncompressed or partial full headers periodically. Pelletier, et. al [Page 16] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 5.1.4.2. Optional Acknowledgements (ACKs), Upward Transition The compressor can also transit to the CO state based on feedback received by the decompressor. If a feedback channel is available, the decompressor MAY use positive feedback (ACKs) to acknowledge successful decompression of packets. Upon reception of an ACK for a context-updating packet, the compressor knows that the decompressor has received the acknowledged packet and the transition to the CO state can be carried out immediately. This functionality is optional, so a compressor MUST NOT expect to get such ACKs initially or during normal operation, even if a feedback channel is available or established. 5.1.4.3. Timeouts, Downward Transition When the optimistic approach is used (i.e. until a feedback channel is established), there will always be a possibility of failure since the decompressor may not have received sufficient information for correct decompression. Therefore, unless the decompressor has established a feedback channel, the compressor MUST periodically transit to the IR state. 5.1.4.4. Negative ACKs (NACKs), Downward Transition Negative acknowledgments (NACKs) are also called context requests. Upon reception of a NACK, the compressor transits back to the IR state and sends updates (such as IR-DYN or IR) to the decompressor. 5.1.4.5. Need for Updates, Downward Transition When the header to be compressed does not conform to the established pattern or when the compressor is not confident whether the decompressor has the synchronized context, the compressor will transit to the IR state. 5.1.5. State Machine Supporting Context Replication For a profile supporting context replication, the additional compressor logic (including corresponding state transition and feedback logic) defined by ROHC-CR [3] must be added to the compressor state machine described above. Pelletier, et. al [Page 17] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 The following figure shows the resulting state machine: Optimistic approach / ACK +--->------>------>------>------>------>------>---+ | | | BCID Selection Optimistic approach / ACK | ACK | +------>----->------+ +----->----->----->-----+ | +->-+ | | | | | | | | | | v | v v | v +---------+ +---------+ +---------+ | IR | | CR | | CO | | State | | State | | State | +---------+ +---------+ +---------+ ^ ^ | | | | NACK / STATIC-NACK | | | +---<-----<-----<----+ | | | | Timeout / NACK / STATIC-NACK | +-----<-------<-------<-------<-------<-------<----+ 5.2. 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. Success +-->------>------>------>------>------>--+ | | No Static | No Dynamic Success | Success +-->--+ | +-->--+ +--->----->---+ +-->--+ | | | | | | | | | | v | | v | v | v +-----------------+ +---------------------+ +-------------------+ | No Context (NC) | | Static Context (SC) | | Full Context (FC) | +-----------------+ +---------------------+ +-------------------+ ^ | ^ | | k_2 out of n_2 failures | | k_1 out of n_1 failures | +-----<------<------<-----+ +-----<------<------<-----+ Pelletier, et. al [Page 18] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 5.2.1. No Context (NC) State Initially, while working in the NC state, the decompressor has not yet successfully decompressed a packet. Upon receiving an IR or an IR-DYN packet, the decompressor will verify the correctness of this packet by validating its header using the CRC check. If the decompressed packet is successfully verified, the decompressor will update the context and use this packet as the reference packet. Once a packet has been decompressed correctly, the decompressor can transit to the FC state, and only upon repeated failures will it transit back to a lower state. 5.2.2. Static Context (SC) State In the SC state, the decompressor assumes static context damage when the CRC check of k_2 out of the last n_2 decompressed packets have failed. The decompressor moves to the NC state and discards all packets until a packet (e.g. IR or IR-DYN packet) that successfully passes the verification check is received. The decompressor may send feedback (see section 5.2.7) when assuming static context damage. Note that appropriate values for k and n, are related to the residual error rate of the link. When the residual error rate is close to zero, k = n = 1 may be appropriate. 5.2.3. Full Context (FC) State In the FC state, the decompressor assumes context damage when the CRC check of k_1 out of the last n_1 decompressed packets have failed, (where k and n are related to the residual error rate of the link as in section 5.2.2). The decompressor moves to the SC state and discards all packets until a packet carrying a 7- or 8-bit CRC that successfully passes the verification check is received. The decompressor may send feedback (see section 5.2.7) when assuming context damage. Upon receiving an IR or an IR-DYN packet, the decompressor SHOULD verify the correctness of its header using CRC validation. If the verification succeeds, the decompressor will update the context and use this packet as the reference packet. Consequently, the decompressor will convert the packet into the original packet and pass it to the network layer of the system. Upon receiving other types of packet, the decompressor will decompress it. The decompressor MUST verify the correctness of the decompressed packet by CRC check. If this verification succeeds, the decompressor passes the decompressed packet to the system's network layer. The decompressor will then use this packet as the reference Pelletier, et. al [Page 19] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 value, if it is not older than the current reference packet (based on sequence numbers in the compressed packet or in the uncompressed header). 5.2.4. Allowing Decompression In the No Context state, only packets carrying sufficient information on the static fields (i.e. IR packets) can be decompressed. In the Static Context state, only packets carrying a 7- or 8-bit CRC may be decompressed (i.e. IR, IR-DYN and some CO packets). In the Full Context state, decompression may be attempted regardless of the type of packet received. If decompression may not be performed, the packet is discarded. As per ROHC-CR [3], IR-CR packets may be decompressed in any state. 5.2.5. Reconstruction and Verification The CRC carried within compressed headers MUST be used to verify decompression. When the decompression is verified and successful, the decompressor updates the context with the information received in the current header; otherwise if the reconstructed header fails the CRC check, these updates MUST NOT be performed. 5.2.6. Actions upon CRC Failure When a CRC check fails, the decompressor MUST discard the packet. The actions to be taken when CRC verification fails following the decompression of an IR-CR packet are specified in [3]. For other packet types carrying a CRC, if feedback is used the logic specified in section 5.2.7 must be followed when CRC verification fails. Note: Decompressor implementations may attempt corrective or repair measures prior to performing the above actions, and the result of any attempt MUST be verified using the CRC check. 5.2.7. 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) will establish this channel. The decompressor will then use the feedback channel to send error recovery requests and (optionally) acknowledgements of significant context updates. Pelletier, et. al [Page 20] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 Once the decompressor establishes a feedback channel, the compressor will operate using an optimistic logic. In particular, this means that the compressor will rely on specific decompressor feedback logic: - the decompressor will send negative acknowledgements in case when context damage is assumed or in other failure situations; - the decompressor is not strictly expected to send feedback upon successful decompression, other than for the purpose of improving the forward state transition. Once the feedback channel is established, the decompressor is REQUIRED to continue sending feedback for the lifetime of the packet stream as follow: In NC state: The decompressor SHOULD send a STATIC-NACK if a packet of a type other than IR is received, or if an IR packet has failed the CRC check. In SC state: The decompressor SHOULD send a STATIC-NACK when decompression of an IR, an IR-DYN or a CO packet carrying a 7-bit CRC fails and if static context damage is assumed (see also section 5.2.2). If any other packet type is received, the decompressor SHOULD treat it as a CRC mismatch when deciding if feedback is to be sent. In FC state: The decompressor SHOULD send a NACK when decompression of any packet type fails and if context damage is assumed (see also section 5.2.3). When decompression fails, the feedback rate SHOULD be limited. For example, feedback could be sent only when decompression of several consecutive packets have failed. In addition, the decompressor should also limit the rate at which feedback is sent on successful decompression, if sent at all. The decompressor may limit the feedback rate by sending feedback for one out of a number of packets providing the same type of feedback. 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 7- or 8-bit CRC is correctly decompressed, the compressor may optionally send an ACK. Pelletier, et. al [Page 21] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 Finally, when the decompressor ACKs an IR packet, it MUST use the CRC option (see [2], section 5.7.6.3) when sending this feedback. This is necessary to ensure that a context does not erroneously become a candidate for later use as a base context for replication [3]. 6. ROHC-TCP - TCP/IP Compression (Profile 0x0006) This section describes a ROHC profile for TCP/IP compression. The profile identifier for ROHC-TCP is 0x0006. 6.1. Considerations for the Feedback Channel The ROHC-TCP profile may be used in environments with or without feedback capabilities from decompressor to compressor. ROHC-TCP however assumes that if a ROHC feedback channel is available and is used at least once by the decompressor, this channel will be present during the entire compression operation. Otherwise, if the connection is broken and the channel disappears, header compression should be restarted. To parallel RFC 3095 [2], 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. 6.2. Master Sequence Number (MSN) Feedback packets of types ACK and NACK carry information about sequence number or acknowledgement number from decompressor to compressor. Unfortunately, there is no guarantee that sequence number and acknowledgement number fields will be used by every IP protocol stack. In addition, the combined size of the sequence number field and the acknowledgement number field is rather large, and they can therefore not be carried efficiently within the feedback packet. 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. Pelletier, et. al [Page 22] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 2. Inferring the value of incrementing fields such as the IP-ID. The MSN field is present in every packets sent by the compressor. The 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 monotonously. 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.3. CRC Calculations The 3-bit and 7-bit CRCs both cover the entire uncompressed header chain. Note that there is no division between CRC-STATIC or CRC- DYNAMIC fields in ROHC-TCP, as opposed to profiles defined in [2]. 6.4. Initialization The static context of ROHC TCP streams can be initialized in either two ways: 1) By using an IR packet as in section 6.5.1, where the profile is six (6) and the static chain ends with the static part of a TCP packet. 2) By replicating an existing context using the mechanism defined by ROHC-CR. This is done with the IR-CR packet defined in section 6.5.2, where the profile number is six (6) and the static replication chain ends with the static part of a TCP packet. 6.5. Packet Types Pelletier, et. al [Page 23] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ROHC-TCP defines two different packet types: the Initialization and Refresh (IR) packet type, and the Compressed packet type (CO). Each type corresponds to one of the possible states of the compressor. Each packet type also defines a number of packet formats: 30 packet formats are defined for compressed headers (CO), and two for initialization and refresh (IR). Finally, the profile-specific part of the IR-CR packet [3] is also defined in this section. 6.5.1. Initialization and Refresh Packets (IR) ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets as defined in [2] (section 5.2.3. and 5.2.4. respectively). The 8-bit CRC is computed according to section 5.9.1 of [2]. o 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 zero. 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 0 | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / Profile Specific Part / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - CRC: 8-bit CRC, computed according to section 5.9.1 of [2]. Pelletier, et. al [Page 24] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 Profile Specific_Part: The format of this field is defined using the formal notation in section 6.6. It consists in the static chain, the dynamic chain, the irregular chain and the TCP options. Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. o Packet type: IR-DYN 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 +---+---+---+---+---+---+---+---+ | | / Profile_Specific_Part / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - CRC: 8-bit CRC, computed according to section 5.9.1 of [2]. Profile_Specific_Part: The format of this field is defined using the formal notation in section 6.6. It consists in the dynamic chain, the irregular chain and the TCP options only. Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. 6.5.2. Context Replication Packets (IR-CR) Pelletier, et. al [Page 25] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 Context replication requires a dedicated IR packet format that uniquely identifies the IR-CR packet for the ROHC-TCP profile. o 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 packet, as defined in ROHC-CR [3], section 3.4.2. With consideration to the extensibility of the IR packet type defined in RFC 3095 [2], 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 one. 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 1 | 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 +---+---+---+---+---+---+---+---+ | | present if B = 1, / Base CID / 1 octet if for small CIDs, or | | 1-2 octets if for large CIDs +---+---+---+---+---+---+---+---+ | | | Profile_Specific_Part / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - B: B = 1 indicates that the Base CID field is present. Pelletier, et. al [Page 26] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 CRC7: The CRC over the original, uncompressed, header. This 7-bit CRC is computed according to section 3.4.1.1 of [3]. Profile Specific Part: Static and dynamic subheader information used for replication. The format of this field is defined using the formal notation in section 6.6. Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. 6.5.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 bits +---+---+---+---+---+---+---+---+ : : / Header Chain Irregular Part / variable (see section 6.6.9) : : --- --- --- --- --- --- --- --- : : / TCP Options Irregular Part / variable (see section 6.6.5) : : --- --- --- --- --- --- --- --- 6.6. Packet Formats Pelletier, et. al [Page 27] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 This section describes the set of compressed TCP/IP packet formats. The normative description of the packet formats is given using a formal notation, the ROHC-FN [4] . 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 [4] for an explanation of the Formal Notation itself, and the encoding methods used to compress each of the fields in the TCP/IP header. The following constants are defined to improve readability of the packet formats in this section: IPPROTO_TCP = 6 IPPROTO_IP = 255 % place-holder for IP header in chain 6.6.1. Extension Headers 6.6.1.1. IPv6 DEST opt header tlv_header ::= multiple_formats, { uncompressed_format ::= length, % 8 bits option_value, % n bits format_0 ::= length, % 8 bits option_value, % n bits { length ::= irregular (8), option_value ::= uncompressible { field_length ::= length.uncomp_value * 64 - 64 } } } ip_dest_opt ::= multiple_formats, { uncompressed_format ::= next_header, % 8 bits length_and_value, % 8 + n bits default_methods ::= { next_header ::= static, length_and_value ::= static, }, Pelletier, et. al [Page 28] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 format_dest_opt_static ::= next_header, % 8 bits { chain_item ::= value (8, 60), % verify correct header next_header ::= chain_next (8), % identify next header in chain % % it is assumed that, for TCP, it does not make sense to % send the static chain on its own; therefore it is ok % to simply ignore fields that do not appear in the % static chain (the definition of these fields will be % filled in by the dynamic chain) % % note that, for another profile, it may be necessary % to be able to define the width of such fields (to % maintain structure) without actually compressing them % (i.e. where the static chain was being sent alone) % }, format_dest_opt_dynamic ::= length_and_value, % 8 + n bits { chain_item ::= select (60), length_and_value ::= tlv_header, }, format_dest_opt_replicate_0 ::= discriminator, % 8 bits { chain_item ::= select (60), discriminator ::= '00000000' }, format_dest_opt_replicate_1 ::= discriminator, % 8 bits length_and_value, % 8 + n bits { chain_item ::= select (60), discriminator ::= '10000000', length_and_value ::= tlv_header } } 6.6.1.2. IPv6 HOP opt header Pelletier, et. al [Page 29] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ip_hop_opt ::= multiple_formats, { uncompressed_format ::= next_header, % 8 bits length_and_value, % 8 + n bits default_methods ::= { next_header ::= static, length_and_value ::= static, }, format_hop_opt_static ::= next_header, % 8 bits { chain_item ::= value (8, 0), % verify correct header next_header ::= chain_next (8), % identify next header }, format_hop_opt_dynamic ::= length_and_value, % 8 + n bits { chain_item ::= select (0), length_and_value ::= tlv_header }, format_hop_opt_replicate_0 ::= discriminator, % 8 bits { chain_item ::= select (0), discriminator ::= '00000000' }, format_hop_opt_replicate_1 ::= discriminator, % 8 bits length_and_value, % 8 + n bits { chain_item ::= select (0), discriminator ::= '10000000', length_and_value ::= tlv_header } } 6.6.1.3. IPv6 Routing Header Pelletier, et. al [Page 30] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ip_route_opt ::= multiple_formats, { uncompressed_format ::= next_header, % 8 bits length_and_value, % 8 + n bits default_methods ::= { next_header ::= static, length_and_value ::= static, }, format_route_opt_static ::= next_header, % 8 bits { chain_item ::= value (8, 43), % verify correct header next_header ::= chain_next (8), % identify next header length_and_value ::= tlv_header }, format_route_opt_dynamic ::= { chain_item ::= select (43) }, format_route_opt_replicate_0 ::= discriminator, % 8 bits { chain_item ::= select (43), discriminator ::= '00000000' }, format_route_opt_replicate_1 ::= discriminator, % 8 bits length_and_value, % 8 + n bits { chain_item ::= select (43), discriminator ::= '10000000', length_and_value ::= tlv_header } } 6.6.1.4. GRE Header optional32 ::= multiple_formats, { uncompressed_format ::= flag, % 1 bit item, % 32 bits format_0 ::= item, % 0 or 32 bits { Pelletier, et. al [Page 31] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 item ::= alt (flag), { guard ::= select (1), { item ::= irregular (32) } guard ::= select (0), { item ::= value (0, 0) } } } } lsb_7_or_31 ::= multiple_formats, { uncompressed_format ::= item, % 32 bits format_lsb_7 ::= discriminator, % 1 bit item, % 7 bits { discriminator ::= '0', item ::= lsb (7, 8) }, format_lsb_31 ::= discriminator, % 1 bit item, % 31 bits { discriminator ::= '1', item ::= lsb (31, 256) } } gre ::= multiple_formats, { uncompressed_format ::= c_flag, % 1 bit r_flag, % 1 bit k_flag, % 1 bit s_flag, % 1 bit reserved0, % 9 bits version, % 3 bits protocol, % 16 bits checksum, % 0 or 16 bits reserved1, % 0 or 16 bits key, % 0 or 32 bits sequence_number, % 0 or 32 bits default_methods ::= { Pelletier, et. al [Page 32] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 c_flag ::= static, r_flag ::= static, k_flag ::= static, s_flag ::= static, reserved0 ::= value (9, 0), version ::= static, protocol ::= static, reserved1 ::= static, key ::= static checksum ::= alt (c_flag) { guard ::= select (0) { checksum ::= value (0, 0), reserved1 ::= value (0, 0) } guard ::= select (1) { checksum ::= irregular (16), reserved1 ::= value (16, 0) } } } format_gre_static ::= protocol.discriminator, % 1 bit c_flag, % 1 bit r_flag, % 1 bit k_flag, % 1 bit s_flag, % 1 bit version, % 3 bits key, % 0 or 32 bits { chain_item ::= value (8, 47), protocol ::= multiple_formats, { uncompressed_format ::= protocol, % 8 bits default_methods ::= { next_protocol ::= control_field { base_value ::= expression (255), compressed_method ::= chain_next (8) } }, ether_v4 ::= discriminator, % 1 bit next_protocol, % 0 bit { discriminator ::= '0', protocol ::= value (16, 0x0800) }, ether_v6 ::= discriminator, % 1 bit next_protocol, % 0 bit { Pelletier, et. al [Page 33] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 discriminator ::= '1' protocol ::= value (16, 0x86DD) } } c_flag ::= irregular (1), r_flag ::= irregular (1), k_flag ::= irregular (1), s_flag ::= irregular (1), ver ::= irregular (3), key ::= optional32 { flag ::= k_flag, item ::= key }, } format_gre_dynamic ::= checksum, % 0 or 16 bits reserved1, % 0 or 16 bits sequence_number, % 0 or 32 bits { chain_item ::= select (47), sequence_number ::= optional32 { flag ::= s_flag, item ::= sequence_number }, }, format_gre_replicate_0 ::= discriminator, checksum, % 0 or 16 bits reserved1, % 0 or 16 bits sequence_number, % 0, 8 or 32 bits { chain_item ::= select (47), discriminator ::= '00000000', sequence_number ::= alt (s_flag) { guard ::= select (0) { sequence_number ::= value (0, 0) } guard ::= select (1) { sequence_number ::= lsb_7_or_31 } } }, format_gre_replicate_1 ::= discriminator, % 8 bits c_flag, % 1 bit Pelletier, et. al [Page 34] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 r_flag, % 1 bit k_flag, % 1 bit s_flag, % 1 bit reserved, % 1 bit version, % 3 bits checksum, % 0 or 16 bits reserved1, % 0 or 16 bits key, % 0 or 32 bits sequence_number, % 0 or 32 bits { chain_item ::= select (47), discriminator ::= '10000000', c_flag ::= irregular (1), r_flag ::= irregular (1), k_flag ::= irregular (1), s_flag ::= irregular (1), reserved ::= '0', ver ::= irregular (3), key ::= optional32 { flag ::= k_flag, item ::= key }, sequence_number ::= optional32 { flag ::= s_flag, item ::= sequence_number }, }, format_gre_irregular ::= checksum, % 0 or 16 bits reserved1, % 0 or 16 bits sequence_number, % 0, 8 or 32 bits { chain_item ::= select (47), sequence_number ::= alt (s_flag) { guard ::= select (0) { sequence_number ::= value (0, 0) } guard ::= select (1) { sequence_number ::= lsb_7_or_31 } } } } 6.6.1.5. MINE header Pelletier, et. al [Page 35] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 mine ::= multiple_formats, { uncompressed_format ::= protocol, % 8 bits s_bit, % 1 bit res_bits, % 7 bits checksum, % 16 bits orig_dest, % 32 bits orig_src, % 0 or 32 bits default_methods ::= { protocol ::= static, s_bit ::= static, res_bits ::= static, checksum ::= inferred_mine_header_checksum, orig_dest ::= static, orig_src ::= static }, format_mine_static ::= protocol, % 8 bits s_bit, % 1 bit, res_bits, % 7 bits, orig_dest, % 32 bits orig_src, % 0 or 32 bits { chain_item ::= value (8, 55), % verify correct header protocol ::= chain_next (8), % identify next header in chain s_bit ::= irregular (1), res_bits ::= irregular (7), % % include reserved - no benefit in removing them % orig_dest ::= irregular (32), orig_src ::= optional32 { flag ::= s_bit, item ::= orig_src } }, format_mine_dynamic ::= { chain_item ::= select (55), }, format_mine_replicate_0 ::= discriminator, % 8 bits checksum, % 0 bit Pelletier, et. al [Page 36] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 { chain_item ::= select (55), discriminator ::= '00000000' }, format_mine_replicate_1 ::= discriminator, % 8 bits s_bit, % 1 bit res_bits, % 7 bits orig_dest, % 32 bits orig_src, % 0 or 32 bits { chain_item ::= select (55), discriminator ::= '10000000', s_bit ::= irregular (1), res_bits ::= irregular (7), orig_dest ::= irregular (32), orig_src ::= optional32 { flag ::= s_bit, item ::= orig_src } } } 6.6.1.6. Authentication Header (AH) header ah ::= multiple_formats, { uncompressed_format ::= next_header, % 8 bits length, % 8 bits res_bits, % 16 bits spi, % 32 bits sequence_number, % 32 bits auth_data, % n bits default_methods ::= { next_header ::= static, length ::= static, res_bits ::= static, spi ::= static, sequence_number ::= static, auth_data ::= uncompressible { field_length ::= length.uncomp_value * 32 - 32 } }, format_ah_static ::= next_header, % 8 bits length, % 8 bits Pelletier, et. al [Page 37] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 spi, % 32 bits { chain_item ::= value (8, 51), % verify correct header next_header ::= chain_next (8), % identify next header length ::= irregular (8), spi ::= irregular (32) }, format_ah_dynamic ::= res_bits, % 16 bits sequence_number, % 32 bits auth_data, % n bits { chain_item ::= select (51), res_bits ::= irregular (16), sequence_number ::= irregular (32), }, format_ah_replicate_0 ::= discriminator, % 8 bits sequence_number, % 8 or 32 bits auth_data, % n bits { chain_item ::= select (51), discriminator ::= '00000000', sequence_number ::= lsb_7_or_31, }, format_ah_replicate_1 ::= discriminator, % 8 bits length, % 8 bits res_bits, % 16 bits spi, % 32 bits sequence_number, % 32 bits auth_data, % n bits { chain_item ::= select (51), discriminator ::= '10000000', length ::= irregular (8), res_bits ::= irregular (16), spi ::= irregular (32), sequence_number ::= irregular (32), }, format_ah_irregular ::= sequence_number, % 8 or 32 bits auth_data, % n bits { chain_item ::= select (51), sequence_number ::= lsb_7_or_31, } } 6.6.1.7. Encapsulation Security Payload (ESP) header Pelletier, et. al [Page 38] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 esp_null ::= multiple_formats, { uncompressed_format ::= spi, % 32 bits sequence_number, % 32 bits payload, % n bits re, % n bits next_header, % 8 bits auth_data % 96 bits (12 octets) default_methods ::= { spi ::= static, next_header ::= static }, format_esp_static ::= next_header, % 8 bits spi, % 32 bits { chain_item ::= value (8, 50), % verify correct header next_header ::= chain_next (8), % 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) }, format_esp_dynamic ::= sequence_number, % 32 bits { chain_item ::= select (50), sequence_number ::= irregular (32) }, format_esp_replicate_0 ::= discriminator, % 8 bits sequence_number, % 8 or 32 bits { chain_item ::= select (50), discriminator ::= '00000000', sequence_number ::= lsb_7_or_31 }, format_esp_replicate_1 ::= discriminator, % 8 bits spi, % 32 bits sequence_number, % 32 bits { chain_item ::= select (50), discriminator ::= '10000000', spi ::= irregular (32), sequence_number ::= irregular (32) }, format_esp_irregular ::= sequence_number, % 8 or 32 bits Pelletier, et. al [Page 39] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 { chain_item ::= select (50), sequence_number ::= lsb_7_or_31 } } 6.6.2. IPv6 Header ipv6 ::= multiple_formats, { uncompressed_format ::= version, % 4 bits traffic_class, % 6 bits ecn_flags, % 2 bits flow_label, % 20 bits payload_length, % 16 bits next_header, % 8 bits hop_limit, % 8 bits src_addr, % 128 bits dst_addr, % 128 bits default_methods ::= { version ::= value (4, 6), traffic_class ::= static, ecn_flags ::= static, flow_label ::= static, payload_length ::= inferred_length, next_header ::= static, hop_limit ::= static, src_addr ::= static, dst_addr ::= static }, format_ipv6_static ::= version_flag, % 1 bit reserved, % 2 bits fl_zerom % 1 bit flow_label, % 4 or 20 bits next_header, % 8 bits src_addr, % 128 bits dst_addr, % 128 bits { chain_item ::= select (255), tcpip.version ::= select (6), version_flag ::= control_field, { base_field ::= expression (1), compressed_method ::= irregular (1) } reserved ::= '00', Pelletier, et. al [Page 40] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 fl_zero ::= control_field { base_field ::= choice (2), compressed_method ::= irregular (1) }, flow_label ::= alt (fl_zero) { guard ::= select (0) { flow_label ::= irregular (20) } guard ::= select (1) { flow_label ::= value (20, 0) reserved ::= '0000' } }, next_header ::= chain_next (8), src_addr ::= irregular(128), dest_addr ::= irregular(128) }, % % 3095-compatible style... % format_ipv6_static_3095 ::= version, % 4 bits flow_label, % 20 bits next_header, % 8 bits src_addr, % 128 bits dst_addr, % 128 bits { chain_item ::= select (255), version ::= select (6), % verify it version ::= irregular (4), % include it in the chain flow_label ::= irregular (20), next_header ::= chain_next (8), src_addr ::= irregular(128), dest_addr ::= irregular(128) }, format_ipv6_dynamic ::= traffic_class, % 6 bits ecn_flags, % 2 bits Pelletier, et. al [Page 41] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 hop_limit, % 8 bits { chain_item ::= select (255), traffic_class ::= irregular (6), ecn_flags ::= irregular (2), hop_limit ::= irregular (8), }, format_ipv6_replicate ::= traffic_class, % 6 bits ecn_flags, % 2 bits { chain_item ::= select (255), traffic_class ::= irregular (8), ecn_flags ::= irregular (2) }, format_ipv6_irregular ::= alt (next_header) { guard ::= select (IPPROTO_TCP) { % % this is the 'inner' header, so no % irregular chain is required... % } % % for 'outer' headers, an irregular % chain is required... % ipv6_irregular ::= traffic_class, % 0 or 6 bits ecn_flags, % 0 or 2 bits { chain_item ::= select (255), traffic_class ::= alt (tcpip.ecn_and_reserved_used) { guard ::= select (1) { traffic_class ::= irregular (6), ecn_flags ::= irregular (2) }, guard ::= select (0) { traffic_class ::= static, ecn_flags ::= static } } } } } 6.6.3. IPv4 Header Pelletier, et. al [Page 42] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ipv4 ::= multiple_formats, { uncompressed_format ::= version, % 4 bits hdr_length, % 4 bits protocol, % 8 bits tos, % 6 bits ecn_flags, % 2 bits ttl, % 8 bits df, % 1 bit mf, % 1 bit rf, % 1 bit offset, % 13 bits ip_id, % 16 bits src_addr, % 32 bits dst_addr, % 32 bits checksum, % 16 bits length, % 16 bits default_methods ::= { version ::= static, hdr_length ::= value (4, 5), protocol ::= static, tos ::= static, ecn_flags ::= static, ttl ::= static, df ::= static, mf ::= value (1, 0), rf ::= static, offset ::= value (13, 0), ip_id ::= value (16, 0), ip_id.nbo_flag ::= static, ip_id.behavior ::= static, src_addr ::= static, dst_addr ::= static, checksum ::= inferred_ip_v4_header_checksum, length ::= inferred_ip_length, }, format_ipv4_static ::= version_flag, % 1 bit protocol, % 7 bits src_addr, % 32 bits dst_addr, % 32 bits { version_flag ::= control_field, { base_field ::= expression(0), compressed_method ::= irregular(1) } protocol ::= chain_next (7), src_addr ::= irregular(32), Pelletier, et. al [Page 43] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 dest_addr ::= irregular(32) }, % % 3095 compatible version % format_ipv4_static ::= version, % 4 bits reserved, % 4 bits protocol, % 8 bits src_addr, % 32 bits dst_addr, % 32 bits { version ::= select (4), % check it version ::= irregular (4), % put it in the header reserved ::= '0000', protocol ::= chain_next (8), src_addr ::= irregular(32), dest_addr ::= irregular(32) }, format_ipv4_dynamic ::= reserved, % 4 bits df, % 1 bit ip_id.behavior, % 2 bits ip_id.nbo_flag, % 1 bit ip_tos, % 6 bits ip_ecn, % 2 bits ip_ttl, % 8 bits ip_id, % 0/16 bits { ip_df ::= irregular (1), tos ::= irregular (6), ecn_flags ::= irregular (2), ttl ::= irregular (8), % % compressor chooses behaviour of IP-ID % 00 = sequential % 01 = sequential [MUST NOT BE USED!] % 10 = random % 11 = zero % ip_id.behavior ::= control_field { base_value ::= choice (4), encoding_method ::= irregular (2) } ip_id ::= alt (ip_id.behavior) { guard ::= select (0) % sequential behaviour... { ip_id ::= nbo (16), { Pelletier, et. al [Page 44] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 nbo_flag ::= irregular (1), nbo_value ::= irregular (16) } }, guard ::= select (2) % random IP ID... { ip_id ::= irregular (16), ip_id.nbo_flag ::= control_field { base_value ::= expression (1), encoding_method ::= irregular (1) } }, guard ::= select (3) % zero IP ID... { ip_id ::= value (16, 0), ip_id.nbo_flag ::= control_field { base_value ::= expression (1), encoding_method ::= irregular (1) } } } }, format_ipv4_replicate_0 ::= discriminator, % 8 bits ip_id, % 0 or 16 bits tos, % 6 bits ecn_flags, % 2 bits { chain_item ::= select (255) discriminator ::= '00000000', ip_id ::= alt (ip_id.behavior) { guard ::= select (0) % sequential behaviour... { ip_id ::= nbo (16), { nbo_flag ::= static, nbo_value ::= irregular (16) } }, guard ::= select (2) % random IP ID... { ip_id ::= irregular (16) }, guard ::= select (3) % zero IP ID... { ip_id ::= value (16, 0) } } Pelletier, et. al [Page 45] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tos ::= irregular (6), ecn_flags ::= irregular (2) }, format_ipv4_replicate_1 ::= discriminator, % 4 bits df, % 1 bit ip_id.behavior, % 2 bits ip_id.nbo_flag, % 1 bit ip_tos, % 6 bits ip_ecn, % 2 bits ip_ttl, % 8 bits ip_id, % 0/16 bits { chain_item ::= select (255) discriminator ::= '1000', ip_df ::= irregular (1), tos ::= irregular (6), ecn_flags ::= irregular (2), ttl ::= irregular (8), % % compressor chooses behaviour of IP-ID % 00 = sequential % 01 = sequential [MUST NOT BE USED!] % 10 = random % 11 = zero % ip_id.behavior ::= control_field { base_value ::= choice (4), encoding_method ::= irregular (2) } ip_id ::= alt (ip_id.behavior) { guard ::= select (0) % sequential behaviour... { ip_id ::= nbo (16), { nbo_flag ::= irregular (1), nbo_value ::= irregular (16) } }, guard ::= select (2) % random IP ID... { ip_id ::= irregular (16), ip_id.nbo_flag ::= control_field { base_value ::= expression (1), encoding_method ::= irregular (1) } }, Pelletier, et. al [Page 46] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 } }, format_ipv4_irregular ::= alt (protocol) { guard ::= select (IPPROTO_TCP) { % % this is the 'inner' header, so no % irregular chain is required... % } % % for 'outer' headers, irregular % chain is required... % format_ipv4_irregular ::= ip_id, % 0 or 16 bits tos, % 0 or 6 bits ecn_flags, % 0 or 2 bits { chain_item ::= select (255) ip_id ::= alt (ip_id.behavior) { guard ::= select (2) % random IP ID... { ip_id ::= irregular (16), }, guard ::= select (0) % sequential IP ID... { ip_id ::= irregular (16), } } tos ::= alt (tcpip.ecn_and_reserved_used) { guard ::= select (1) { tos ::= irregular (6), ecn_flags ::= irregular (2) } guard ::= select (0) { tos ::= static, ecn_flags ::= static } } } } } 6.6.4. TCP Header Pelletier, et. al [Page 47] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 port_replicate ::= multiple_formats, { uncompressed_format ::= port, % 16 bits format_port_static ::= discriminator, % 2 bits port, % 0 bit { discriminator ::= '00', port ::= static }, format_port_lsb8 ::= discriminator, % 2 bits port, % 8 bits { discriminator ::= '01', port ::= lsb (8, 64) }, format_port_irr ::= discriminator, % 2 bits port, % 16 bits { discriminator ::= '10', port ::= irregular (16) } } tcp ::= multiple_formats, { uncompressed_format ::= src_port, % 16 bits dst_port, % 16 bits rsf_flags, % 3 bits psh_flag, % 1 bit urg_flag, % 1 bit ack_flag, % 1 bit offset, % 4 bits ecn_flags, % 2 bits res_flags, % 4 bits urg_ptr, % 16 bits window, % 16 bits checksum, % 16 bits seq_number, % 32 bits ack_number, % 32 bits options, % n bits default_methods ::= { Pelletier, et. al [Page 48] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 src_port ::= static, dst_port ::= static, seq_number ::= static, ack_number ::= static, rsf_flags ::= static, psh_flag ::= irregular (1), urg_flag ::= static, ack_flag ::= value (1, 1), urg_ptr ::= static, window ::= static, checksum ::= irregular (16), offset ::= expression (options.uncomp_length / 4 + 5) ecn_flags ::= static, reserved ::= static, }, format_tcp_static ::= src_port, % 16 bits dst_port, % 16 bits { next_header ::= value (8, 6), src_port ::= irregular(16), dest_port ::= irregular(16) }, format_tcp_dynamic ::= ecn_and_reserved_used, % 1 bit ack_flag, % 1 bit urg_flag, % 1 bit psh_flag, % 1 bit ecn_flags, % 2 bits ack_zero % 1 bit urp_zero, % 1 bit reserved, % 1 bit rsf_flags, % 3 bits res_flags, % 4 bits msn, % 16 bits seq_number, % 32 bits ack_number % 0 or 32 bits window, % 16 bits checksum, % 16 bits urg_ptr, % 0 or 16 bits options, % n bits { next_header ::= select (6), ecn_and_reserved_used ::= control_field { base_field ::= choice (2), encoding_method ::= irregular (1) }, ack_flag ::= irregular (1), urg_flag ::= irregular (1), psh_flag ::= irregular (1), Pelletier, et. al [Page 49] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ecn_flags ::= irregular (2), reserved ::= '00', rsf_flags ::= irregular (3), reserved ::= irregular (4), msn ::= control_field { base_field ::= counter (16), compressed_method ::= irregular (16) }, seq_number ::= irregular (32), window ::= irregular (16), checksum ::= irregular (16), urp_zero ::= control_field { base_field ::= choice (2), compressed_method ::= irregular (1) }, urg_ptr ::= alt (urp_zero) { guard ::= select (0) { urg_ptr ::= irregular (16) } guard ::= select (1) { urg_ptr ::= value (16, 0) } }, ack_zero ::= control_field { base_field ::= choice (2), compressed_method ::= irregular (1) }, ack_number ::= alt (ack_zero) { guard ::= select (0) { ack_number ::= irregular (32) } guard ::= select (1) { ack_number ::= value (32, 0) } }, options ::= tcp_options } format_tcp_replicate ::= reserved, % 2 bits Pelletier, et. al [Page 50] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 src_port.discriminator, % 2 bits dst_port.discriminator, % 2 bits ack_number.discriminator, % 1 bit urp.discriminator, % 1 bit urg_flag, % 1 bit ack_flag, % 1 bit psh_flag, % 1 bit rsf_flags, % 2 bits ecn_flags, % 2 bits ecn_and_reserved_used, % 1 bit msn, % 16 bits seq_number, % 32 bits src_port, % 0, 8 or l6 bits dst_port, % 0, 8 or 16 bits urg_point, % 0 or 16 bits ack_number, % 0 or 32 bits ecn_and_reserved, % 0 or 8 bits options, % n bits { reserved ::= '00', msn ::= control_field, { base_field ::= counter (16), compressed_method ::= irregular (16) }, urg_flag ::= irregular (1) ack_flag ::= irregular (1) psh_flag ::= irregular (1) rsf_flags ::= index(3, [0, 1, 2, 4]), ecn_and_reserved_used ::= control_field { base_field ::= choice (2), encoding_method ::= irregular (1) }, ecn_flags ::= irregular (2), src_port ::= port_replicate, dst_port ::= port_replicate, seq_number ::= irregular(32), ack_number ::= multiple_formats, { uncompressed_format ::= ack_number % 32 bits ack_zero ::= discriminator, % 1 bit ack_number, % 0 bit { discriminator ::= '0', ack_number ::= static, }, ack_non_zero ::= discriminator, % 1 bit ack_number, % 32 bits { discriminator ::= '1', Pelletier, et. al [Page 51] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ack_number ::= irregular (32) } }, window ::= multiple_formats, { uncompressed_format ::= window, % 16 bits window_static ::= discriminator, % 1 bit window, % 0 bit { discriminator ::= '0', window ::= static }, window_irreg ::= discriminator, % 1 bit window, % 16 bits { discriminator ::= '1', window ::= irregular (16) } }, urg_point ::= multiple_formats, { uncompressed_format ::= urg_point, % 16 bits urp_static ::= discriminator, % 1 bit urg_point, % 0 bit { discriminator ::= '0', urg_point ::= static }, urp_irreg ::= discriminator, % 1 bit urg_point, % 16 bits { discriminator ::= '1', urg_point ::= irregular (16) } }, options ::= tcp_options } format_tcp_irregular ::= checksum, % 16 bits { next_header ::= select (6), checksum ::= irregular (16) } } 6.6.5. TCP Options Pelletier, et. al [Page 52] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tcp_opt_mss ::= multiple_formats, { uncompressed_format ::= type, % 8 bits length, % 8 bits mss, % 16 bits default_methods ::= { type ::= value (8, 2), length ::= value (8, 4), mss ::= static }, format_mss_list_item ::= mss, % 16 bits { mss ::= irregular (16) }, % format_mss_replicate_0 ::= discriminator, % 8 bits % { % discriminator ::= '00000000' % }, % % format_mss_replicate_1 ::= discriminator, % 8 bits % mss, % 16 bits % { % discriminator ::= '10000000', % mss ::= irregular (16) % }, } tcp_opt_wscale ::= multiple_formats, { uncompressed_format ::= type, % 8 bits length, % 8 bits wscale, % 8 bits default_methods ::= { type ::= value (8, 3), length ::= value (8, 3), wscale ::= static }, format_wscale_list_item ::= wscale, % 8 bits { wscale ::= irregular (8) }, % format_wscale_replicate_0 ::= discriminator, % 8 bits % { Pelletier, et. al [Page 53] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 % discriminator ::= '00000000' % }, % % format_wscale_replicate_1 ::= discriminator, % 8 bits % wscale, % 8 bits % { % discriminator ::= '10000000', % wscale ::= irregular (8) % } } ts_lsb ::= muliple_packet_formats, { uncompressed_format ::= tsval, format_tsval_15 ::= discriminator, % 1 bit tsval, % 15 bits { discriminator ::= '0', tsval ::= lsb (15, 128) }, format_tsval_22 ::= discriminator, % 2 bits tsval, % 22 bits { discriminator ::= '10', tsval ::= lsb (22, 256) }, format_tsval_30 ::= discriminator, % 2 bits tsval, % 20 bits { discriminator ::= '11', tsval ::= lsb (30, 512) } } tcp_opt_tsopt ::= multiple_formats, { uncompressed_format ::= type, % 8 bits length, % 8 bits tsval, % 32 bits tsecho, % 32 bits default_methods ::= { type ::= value (8, 8), length ::= value (8, 10), }, format_tsopt_list_item ::= tsval, % 32 bits Pelletier, et. al [Page 54] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tsecho, % 32 bits { tsval ::= irregular (32), tsopt ::= irregular (32) }, % format_tsopt_replicate ::= tsval, % 32 bits % tsecho, % 32 bits % { % tsval ::= irregular (32), % tsopt ::= irregular (32) % }, format_tsopt_irregular ::= tsval, % 16, 24 or 32 bits tsecho, % 16, 24 or 32 bits { tsval ::= ts_lsb, tsecho ::= ts_lsb } } sack_sdvl ::= multiple_formats, { uncompressed_format ::= base, % 32 bits sack_field, % 32 bits default_methods ::= { sack_field ::= inferred_offset { base_field ::= base, encoding_method ::= static } }, format_lsb_15 ::= discriminator, % 1 bit sack_field, % 15 bits { discriminator ::= '0', sack_field.encoding_method ::= lsb (15, -1) }, format_lsb_22 ::= discriminator, % 2 bits sack_field, % 22 bits { discriminator ::= '10', sack_field.encoding_method ::= lsb (22, -1) }, format_lsb_30 ::= discriminator, % 2 bits sack_field, % 30 bits Pelletier, et. al [Page 55] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 { discriminator ::= '11', sack_field.encoding_method ::= lsb (30, -1) } } tcp_opt_sack_block_1 ::= multiple_formats, { uncompressed_format ::= block_1_start, % 32 bits block_1_end, % 32 bits format_0 ::= block_1_start, % 16, 24 or 32 bits block_1_end, % 16, 24 or 32 bits { block_1_start ::= sack_sdvl { base ::= tcpip.ack_number, sack_field ::= block_1_start }, block_1_end ::= sack_sdvl { base ::= block_1_start, sack_field ::= block_1_end }, } } tcp_opt_sack_block_2 ::= multiple_formats, { uncompressed_format ::= block_2_start, % 32 bits block_2_end, % 32 bits format_0 ::= block_2_start, % 16, 24 or 32 bits block_2_end, % 16, 24 or 32 bits { block_2_start ::= sack_sdvl { base ::= block_1_end, sack_field ::= block_2_start }, block_2_end ::= sack_sdvl { base ::= block_2_start, sack_field ::= block_2_end }, } } tcp_opt_sack_block_3 ::= multiple_formats, Pelletier, et. al [Page 56] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 { uncompressed_format ::= block_3_start, % 32 bits block_3_end, % 32 bits format_0 ::= block_3_start, % 16, 24 or 32 bits block_3_end, % 16, 24 or 32 bits { block_3_start ::= sack_sdvl { base ::= block_2_end, sack_field ::= block_3_start }, block_3_end ::= sack_sdvl { base ::= block_3_start, sack_field ::= block_3_end } } } tcp_opt_sack_block_4 ::= multiple_formats, { uncompressed_format ::= block_4_start, % 32 bits block_4_end, % 32 bits format_0 ::= block_4_start, % 16, 24 or 32 bits block_4_end, % 16, 24 or 32 bits { block_4_start ::= sack_sdvl { base ::= block_3_end, sack_field ::= block_4_start }, block_4_end ::= sack_sdvl { base ::= block_4_start, sack_field ::= block_4_end } } } tcp_opt_sack ::= multiple_formats, { uncompressed_format ::= type, % 8 bits length, % 8 bits blocks, % n bits default_methods ::= { Pelletier, et. al [Page 57] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 type ::= value (8, 5), length ::= irregular (8) }, format_sack_list_item ::= length, % 8 bits blocks, % n bits { length ::= irregular (8), blocks ::= alt (length) { % % length no blocks % 10 1 % 18 2 % 26 3 % 34 4 % guard ::= select (10) { blocks ::= { sack_block_1 } } guard ::= select (18) { blocks ::= { sack_block_1, sack_block_2 } } guard ::= select (26) { blocks ::= { sack_block_1, sack_block_2, sack_block_3 } } guard ::= select (34) { blocks ::= { sack_block_1, sack_block_2, sack_block_3, Pelletier, et. al [Page 58] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 sack_block_4 } } } % format_sack_replicate ::= same_as (sack_list_item), format_sack_irregular ::= same_as (sack_list_item) } % % 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, store everything after the EOL option as % uncompressible. % tcp_opt_eol ::= multiple_formats, { uncompressed_format ::= type, % 8 bits default_methods ::= { type ::= value (8, 0), padding_size ::= static, padding ::= static }, format_eol_list_item ::= padding_size, % 8 bits padding, % n bits { padding_size ::= control_field { base_field ::= expression (), compressed_method ::= irregular (8) % 8 bits for alignment } padding ::= uncompressible { field_width ::= same_as (padding_size) } }, % format_eol_replicate ::= same_as (eol_list_item), } tcp_opt_nop ::= multiple_formats, { uncompressed_format ::= type, % 8 bits default_methods ::= { Pelletier, et. al [Page 59] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 type ::= value (8, 1) }, format_nop_list_item ::= { }, % format_nop_replicate ::= same_as (nop_list_item) } tcp_opt_sack_permitted ::= multiple_formats, { uncompressed_format ::= type, % 8 bits length, % 8 bits default_methods ::= { type ::= value (8, 1) length ::= value (8, 2) }, format_sack_permitted_list_item ::= { }, % format_sack_permitted_replicate::=same_as(sack_permitted_list_item) } tcp_opt_generic ::= multiple_formats, { uncompressed_format ::= type, % 8 bits length_msb, % 1 bit length_lsb, % 7 bits contents, % n bits default_methods ::= { type ::= static, % % lengths are always < 128 % (i.e. the msb is always 0) % length_msb ::= value (1, 0) length ::= static, contents ::= uncompressible { field_length ::= length_lsb.uncomp_value * 8 - 16 } Pelletier, et. al [Page 60] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 option_static ::= control_field, { base_value ::= choice (2), compressed_method ::= static, } } format_generic_list_item ::= type, % 8 bits option_static.compressed_method, % 1 bit length_lsb, % 7 bits contents, % n bits { type ::= irregular (8), option_static.compressed_method ::= irregular (1), length_lsb ::= irregular (7), } % format_generic_replicate_0 ::= discriminator, % 8 bits % { % discriminator ::= '00000000', % contents ::= static % }, % format_generic_replicate_1 ::= discriminator, % 8 bits % type, % 8 bits % option_static.compressed_method, % 1 bit % length_lsb, % 7 bits % contents, % n bits % { % discriminator ::= '10000000', % type ::= irregular (8), % option_static.compressed_method ::= irregular (1), % length_lsb ::= irregular (7) % }, format_generic_irregular ::= { generic ::= multiple_formats, { uncompressed_format ::= length_lsb, % 7 bits contents, % n bits contents ::= alt (option_stable.base_value) { guard ::= select (1) { length_lsb ::= static, contents ::= static Pelletier, et. al [Page 61] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 } guard ::= select (0) { % % if option is not stable, still % allow for it to be elided... % ... may avoid fall-back to IR-DYN % opt_static ::= discriminator, % 8 bits { discriminator ::= '00000000', contents ::= static } opt_changing ::= discriminator, % 1 bit length_lsb, % 7 bits contents, % n bits { discriminator ::= '1', length_lsb ::= irregular (7), contents ::= uncompressible { field_length ::= length_lsb.uncomp_value * 8 - 16 } } } } } } } 6.6.6. TCP/IP CO Packets Pelletier, et. al [Page 62] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 % used in place of the "dynamic chain" for the % "inner" IP header and the TCP header crc3 ::= same_as (crc (3, 0x06, 0x03)) crc7 ::= same_as (crc (7, 0x79, 0x7f)) tcpip ::= multiple_formats, { uncompressed_format_v4 ::= version, % 4 bits hdr_length, % 4 bits tos, % 6 bits ecn_flags, % 2 bits length, % 16 bits ip_id, % 16 bits rf, % 1 bit df, % 1 bit mf, % 1 bit offset, % 13 bits ttl, % 8 bits protocol, % 8 bits checksum, % 16 bits src_addr, % 32 bits dst_addr, % 32 bits src_port, % 16 bits dst_port, % 16 bits rsf_flags, % 3 bits psh_flag, % 1 bit urg_flag, % 1 bit ack_flag, % 1 bit data_offset, % 4 bits tcp_ecn, % 2 bits res_flags, % 4 bits urg_ptr, % 16 bits window, % 16 bits tcp_checksum, % 16 bits seq_number, % 32 bits ack_number, % 32 bits options, % n bits uncompressed_format_v6 ::= version, % 4 bits traffic_class, % 6 bits ecn_flags, % 2 bits flow_label, % 20 bits payload_length, % 16 bits next_header, % 8 bits hop_limit, % 8 bits src_addr, % 128 bits dst_addr, % 128 bits src_port, % 16 bits dst_port, % 16 bits rsf_flags, % 3 bits Pelletier, et. al [Page 63] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 psh_flag, % 1 bit urg_flag, % 1 bit ack_flag, % 1 bit data_offset, % 4 bits tcp_ecn, % 2 bits res_flags, % 4 bits urg_ptr, % 16 bits window, % 16 bits tcp_checksum, % 16 bits seq_number, % 32 bits ack_number, % 32 bits options, % n bits uncompressed_format_v4.tos ::= uncompressed_format_v6.traffic_class, uncompressed_format_v4.ttl ::= uncompressed_format_v6.hop_limit, uncompressed_format_v4.length ::= uncompressed_format_v6.payload_length, default_methods ::= { ip_id ::= alt (ip_id.behavior) { guard ::= select (0) { ip_id ::= nbo (16), { nbo_flag ::= irregular (1), nbo_value ::= inferred_offset (16) { base_field ::= msn, offset ::= static } } } guard ::= select (2) { ip_id ::= irregular (16) } guard ::= select (3) { ip_id ::= value (16, 0) } }, ecn_and_reserved ::= control_field, { base_field ::= group Pelletier, et. al [Page 64] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 { field_list ::= ecn_flags, tcp_ecn, res_flags, } compressed_method ::= alt (ecn_and_reserved_used) { guard ::= select (0) { ecn_and_reserved ::= value (8, 0) } guard ::= select (1) { ecn_and_reserved ::= irregular (8) } } }, version ::= static, hdr_length ::= static, tos ::= static, length ::= inferred_length, rf ::= value (1, 0), df ::= static, mf ::= static, offset ::= value (13, 0), ttl ::= static, protocol ::= value (8, 6), checksum ::= inferred_ip_v4_header_checksum, src_addr ::= static, dst_addr ::= static, src_port ::= static, dst_port ::= static, rsf_flags ::= static, psh_flag ::= irregular (1), urg_flag ::= static, ack_flag ::= value (1, 1), data_offset ::= value (4, 5), tcp_ecn ::= static, res_flags ::= static, urg_ptr ::= static, window ::= static, seq_number ::= static, ack_number ::= static, options ::= static, flow_label ::= static }, format_co ::= alt (ip_id.behavior) Pelletier, et. al [Page 65] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 { guard ::= select (0) { format_co ::= co_ip_sequential } guard ::= select (2) { format_co ::= co_ip_random } guard ::= select (3) { format_co ::= co_ip_random % (or zero) } format_co_common ::= { co_format_common ::= { discriminator, % 4 bits msn, % 4 bits psh_flag, % 1 bits header_crc, % 7 bits ack_flag, % 1 bits ip_id.behavior, % 2 bit df, % 1 bits format, % 1 bits ecn_and_reserved_used, % 1 bits urg_flag, % 1 bits padding, % 2 bits seq_number.discriminator, % 1 bits window.discriminator, % 1 bits ack_number.discriminator, % 1 bits urg_ptr.discriminator, % 1 bits tos.discriminator, % 1 bits ttl.discriminator, % 1 bits rsf_flags.discriminator, % 1 bits ecn_flags.discriminator, % 1 bits seq_number, % 0 or 32 bits window, % 0 or 16 bits ecn_and_reserved, % 0 or 8 bits ack_number, % 0 or 32 bits ip_id, % 0 or 16 bits tos, % 0 or 8 bits urg_ptr, % 0 or 16 bits ttl, % 0 or 8 bits rsf_flags, % 0 or 8 bits ecn_flags, % 0 or 8 bits { discriminator ::= '111', Pelletier, et. al [Page 66] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 msn ::= irregular(4), psh_flag ::= irregular(1), header_crc ::= crc7, ack_flag ::= irregular(1), ip_id.behavior ::= irregular(2), df ::= irregular(1), format ::= irregular(1), ecn_and_reserved_used ::= irregular(1), urg_flag ::= irregular(1), padding ::= value(2, 0), seq_number.discriminator ::= irregular(1), window.discriminator ::= irregular(1), ack_number.discriminator ::= irregular(1), urg_ptr.discriminator ::= irregular(1), tos.discriminator ::= irregular(1), ttl.discriminator ::= irregular(1), rsf_flags.discriminator ::= irregular(1), ecn_flags.discriminator ::= irregular(1), seq_number ::= multiple_formats, { uncompressed_format ::= seq_number, % 32 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit seq_number, % 0 bit { discriminator ::= '0', seq_number ::= static }, co_format_1 ::= discriminator, % 1 bit seq_number, % 32 bits { discriminator ::= '1', seq_number ::= irregular(32) } }, window ::= multiple_formats, { uncompressed_format ::= window, % 16 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit window, % 0 bit { discriminator ::= '0', window ::= static }, co_format_1 ::= discriminator, % 1 bit window, % 16 bits { discriminator ::= '1', window ::= irregular(16) } }, Pelletier, et. al [Page 67] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ecn_and_reserved ::= multiple_formats, { uncompressed_format ::= ecn_and_reserved, % 8 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit ecn_and_reserved, % 0 bit { discriminator ::= '0', ecn_and_reserved ::= static }, co_format_1 ::= discriminator, % 1 bit ecn_and_reserved,% 8 bits { discriminator ::= '1', ecn_and_reserved ::= irregular(8) } }, ack_number ::= multiple_formats, { uncompressed_format ::= ack_number, % 32 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit ack_number, % 0 bit { discriminator ::= '0', ack_number ::= static }, co_format_1 ::= discriminator, % 1 bit ack_number, % 32 bits { discriminator ::= '1', ack_number ::= irregular(32) } }, ip_id ::= multiple_formats, { uncompressed_format ::= ip_id, % 16 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit ip_id, % 0 bit { discriminator ::= '0', ip_id ::= static }, co_format_1 ::= discriminator, % 1 bit ip_id, % 16 bits { discriminator ::= '1', ip_id ::= irregular(16) } }, tos ::= multiple_formats, { uncompressed_format ::= tos, % 6 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit tos, % 0 bit { discriminator ::= '0', tos ::= static }, co_format_1 ::= discriminator, % 1 bit Pelletier, et. al [Page 68] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tos, % 6 bits { discriminator ::= '1', tos ::= irregular(6) reserved ::= value (2, 0) } }, urg_ptr ::= multiple_formats, { uncompressed_format ::= urg_ptr, % 16 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit urg_ptr, % 0 bit { discriminator ::= '0', urg_ptr ::= static }, co_format_1 ::= discriminator, % 1 bit urg_ptr, % 16 bits { discriminator ::= '1', urg_ptr ::= irregular(16) } }, ttl ::= multiple_formats, { uncompressed_format ::= ttl, % 8 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit ttl, % 0 bit { discriminator ::= '0', ttl ::= static }, co_format_1 ::= discriminator, % 1 bit ttl, % 8 bits { discriminator ::= '1', ttl ::= irregular(8) } }, rsf_flags ::= multiple_formats, { uncompressed_format ::= rsf_flags, % 3 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit rsf_flags, % 0 bit { discriminator ::= '0', rsf_flags ::= static }, co_format_1 ::= discriminator, % 1 bit rsf_flags, % 3 bits { discriminator ::= '1', rsf_flags ::= irregular(3) reserved ::= value (5, 0) } }, ecn_flags ::= multiple_formats, { Pelletier, et. al [Page 69] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 uncompressed_format ::= ecn_flags, % 2 bits co_format_count ::= constant(2), co_format_0 ::= discriminator, % 1 bit ecn_flags, % 0 bit { discriminator ::= '0', ecn_flags ::= static }, co_format_1 ::= discriminator, % 1 bit ecn_flags, % 2 bits { discriminator ::= '1', ecn_flags ::= irregular(2) reserved ::= value (6, 0) } }, } } } co_ip_sequential ::= { format_co_0 ::= discriminator, % 3 bits psh_flag, % 1 bits ack_number, % 2 bits rsf_flags, % 2 bits tcp_checksum, % 16 bits msn, % 3 bits header_crc, % 3 bits seq_number.scaled, % 10 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '101', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= msn), ack_number ::= lsb (2, 1), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= index (3, [0, 1, 2, 4]), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (10, 511) }, format_co_1 ::= discriminator, % 3 bits ip_id.nbo_flag, % 1 bits seq_number, % 12 bits Pelletier, et. al [Page 70] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tcp_checksum, % 16 bits psh_flag, % 1 bits ecn_and_reserved_used, % 1 bits msn, % 3 bits header_crc, % 3 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '110', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_flag ::= irregular (1), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), seq_number ::= lsb (12, 1023), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), ecn_and_reserved_used ::= irregular (1) } , format_co_2 ::= discriminator, % 4 bits seq_number, % 12 bits ttl, % 8 bits tcp_checksum, % 16 bits ip_id.nbo_flag, % 1 bit psh_flag, % 1 bit msn, % 3 bits header_crc, % 3 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '0001', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_flag ::= irregular (1), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ttl ::= irregular (8), Pelletier, et. al [Page 71] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 seq_number ::= lsb (12, 1023), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16) } , format_co_3 ::= discriminator, % 5 bits msn, % 3 bits ip_id.nbo_value.offset, % 8 bits tcp_checksum, % 16 bits psh_flag, % 1 bit header_crc, % 3 bits seq_number, % 12 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '00111', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ip_id.nbo_value.offset ::= lsb (8, 0), seq_number ::= lsb (12, 1023), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16) } , format_co_4 ::= discriminator, % 6 bits psh_flag, % 1 bit header_crc, % 3 bits ack_number, % 14 bits tcp_checksum, % 16 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '000011', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, Pelletier, et. al [Page 72] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ack_number ::= lsb (14, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_5 ::= discriminator, % 5 bits msn, % 3 bits ip_id.nbo_value.offset, % 16 bits tcp_checksum, % 16 bits psh_flag, % 1 bit header_crc, % 3 bits seq_number, % 12 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '00101', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ip_id.nbo_value.offset ::= irregular (16), seq_number ::= lsb (12, 1023), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16) } , format_co_6 ::= discriminator, % 3 bits psh_flag, % 1 bit seq_number, % 12 bits tcp_checksum, % 16 bits ecn_and_reserved_used, % 1 bit msn, % 3 bits header_crc, % 3 bits tos, % 6 bits ip_id.nbo_value.offset, % 11 bits ecn_and_reserved, % 0/ 8 bits Pelletier, et. al [Page 73] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 { discriminator ::= '100', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, tos ::= irregular (6), ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ip_id.nbo_value.offset ::= lsb (11, 1), seq_number ::= lsb (12, 1023), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), ecn_and_reserved_used ::= irregular (1) } , format_co_7 ::= discriminator, % 2 bits psh_flag, % 1 bit msn, % 3 bits header_crc, % 3 bits ttl, % 8 bits ip_id.nbo_value.offset, % 11 bits seq_number, % 12 bits tcp_checksum, % 16 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '01', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ip_id.nbo_value.offset ::= lsb (11, 1), ttl ::= irregular (8), seq_number ::= lsb (12, 1023), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16) } , Pelletier, et. al [Page 74] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 format_co_8 ::= discriminator, % 7 bits psh_flag, % 1 bits tcp_checksum, % 16 bits ecn_and_reserved_used, % 1 bit header_crc, % 3 bits msn, % 4 bits ip_id.nbo_value.offset, % 11 bits seq_number, % 13 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '0000101', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ip_id.nbo_value.offset ::= lsb (11, 1), seq_number ::= lsb (13, 2047), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), ecn_and_reserved_used ::= irregular (1) } , format_co_9 ::= discriminator, % 7 bits psh_flag, % 1 bit ttl, % 8 bits tcp_checksum, % 16 bits msn, % 3 bits header_crc, % 3 bits seq_number.scaled, % 12 bits ack_number, % 14 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '0011011', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), Pelletier, et. al [Page 75] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ttl ::= irregular (8), ack_number ::= lsb (14, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_10 ::= discriminator, % 7 bits psh_flag, % 1 bit ttl, % 8 bits tcp_checksum, % 16 bits header_crc, % 3 bits seq_number, % 13 bits msn, % 4 bits tos, % 6 bits ip_id.nbo_value.offset, % 6 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '0011001', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, tos ::= irregular (6), ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ip_id.nbo_value.offset ::= lsb (6, 0), ttl ::= irregular (8), seq_number ::= lsb (13, 2047), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16) } , format_co_11 ::= discriminator, % 6 bits ip_id.nbo_flag, % 1 bit psh_flag, % 1 bit tcp_checksum, % 16 bits ecn_and_reserved_used, % 1 bit header_crc, % 3 bits msn, % 4 bits tos, % 6 bits seq_number.scaled, % 12 bits Pelletier, et. al [Page 76] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ack_number, % 14 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '000001', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, tos ::= irregular (6), ip_id ::= nbo(16), ip_id.nbo_flag ::= irregular (1), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ack_number ::= lsb (14, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), ecn_and_reserved_used ::= irregular (1), seq_number.scaled ::= lsb (12, 1) }, format_co_12 ::= discriminator, % 5 bits header_crc, % 3 bits window, % 16 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ack_number, % 15 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '00100', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ack_number ::= lsb (15, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), window ::= irregular (16), Pelletier, et. al [Page 77] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_13 ::= discriminator, % 8 bits ttl, % 8 bits tcp_checksum, % 16 bits psh_flag, % 1 bit header_crc, % 3 bits msn, % 4 bits tos, % 6 bits ip_id.nbo_value.offset, % 12 bits seq_number, % 14 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '00001000', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, tos ::= irregular (6), ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ip_id.nbo_value.offset ::= lsb (12, 1), ttl ::= irregular (8), seq_number ::= lsb (14, 2047), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16) } , format_co_14 ::= discriminator, % 7 bits urg_flag, % 1 bit tcp_checksum, % 16 bits urg_ptr, % 16 bits psh_flag, % 1 bit header_crc, % 3 bits msn, % 4 bits ip_id.nbo_value.offset, % 11 bits seq_number, % 13 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '0011000', msn ::= control_field, { base_field ::= counter(16), Pelletier, et. al [Page 78] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ip_id.nbo_value.offset ::= lsb (11, 1), seq_number ::= lsb (13, 2047), urg_flag ::= irregular (1), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), urg_ptr ::= irregular (16) } , format_co_15 ::= discriminator, % 6 bits psh_flag, % 1 bit header_crc, % 3 bits ack_number, % 14 bits ttl, % 8 bits window, % 16 bits tcp_checksum, % 16 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '000000', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ttl ::= irregular (8), ack_number ::= lsb (14, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), window ::= irregular (16), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_16 ::= discriminator, % 7 bits psh_flag, % 1 bit window, % 16 bits Pelletier, et. al [Page 79] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tcp_checksum, % 16 bits ecn_and_reserved_used, % 1 bit header_crc, % 3 bits msn, % 4 bits tos, % 6 bits seq_number.scaled, % 12 bits ack_number, % 14 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '0011010', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, tos ::= irregular (6), ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), ack_number ::= lsb (14, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), window ::= irregular (16), tcp_checksum ::= irregular (16), ecn_and_reserved_used ::= irregular (1), seq_number.scaled ::= lsb (12, 1) }, format_co_17 ::= discriminator, % 8 bits ack_number, % 32 bits tcp_checksum, % 16 bits psh_flag, % 1 bit header_crc, % 3 bits msn, % 4 bits ip_id.nbo_value.offset, % 11 bits seq_number, % 13 bits ecn_and_reserved, % 0/ 8 bits { discriminator ::= '00001001', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ip_id ::= nbo(16), ip_id.nbo_value ::= inferred_offset (16), ip_id.nbo_value.base_field ::= same_as (msn), Pelletier, et. al [Page 80] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ip_id.nbo_value.offset ::= lsb (11, 1), seq_number ::= lsb (13, 2047), ack_number ::= irregular (32), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16) } , } co_ip_random ::= { format_co_0 ::= discriminator, % 2 bits psh_flag, % 1 bit seq_number, % 13 bits tcp_checksum, % 16 bits ecn_and_reserved_used, % 1 bit header_crc, % 3 bits msn, % 4 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/ 16 bits { discriminator ::= '01', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 1500), seq_number ::= lsb (13, 2047), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), ecn_and_reserved_used ::= irregular (1) } , format_co_1 ::= discriminator, % 3 bits psh_flag, % 1 bits ack_number, % 2 bits rsf_flags, % 2 bits tcp_checksum, % 16 bits msn, % 3 bits header_crc, % 3 bits seq_number.scaled, % 10 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { Pelletier, et. al [Page 81] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 discriminator ::= '101', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 40), ack_number ::= lsb (2, 1), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= index (3, [0, 1, 2, 4]), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (10, 511) }, format_co_2 ::= discriminator, % 3 bits seq_number, % 13 bits ttl, % 8 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ecn_and_reserved_used, % 1 bit msn, % 3 bits header_crc, % 3 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '110', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 1500), ttl ::= irregular (8), seq_number ::= lsb (13, 2047), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), ecn_and_reserved_used ::= irregular (1) }, format_co_3 ::= discriminator, % 5 bits header_crc, % 3 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ack_number, % 15 bits Pelletier, et. al [Page 82] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '00000', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 52), ack_number ::= lsb (15, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_4 ::= discriminator, % 3 bits seq_number, % 13 bits tcp_checksum, % 16 bits urg_ptr, % 16 bits urg_flag, % 1 bit psh_flag, % 1 bit msn, % 3 bits header_crc, % 3 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '100', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 1500), seq_number ::= lsb (13, 2047), urg_flag ::= irregular (1), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), urg_ptr ::= irregular (16) } , format_co_5 ::= discriminator, % 5 bits Pelletier, et. al [Page 83] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 header_crc, % 3 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ack_number, % 15 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '00011', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 40), ack_number ::= lsb (15, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_6 ::= discriminator, % 5 bits header_crc, % 3 bits ttl, % 8 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ack_number, % 15 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '00101', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 52), ttl ::= irregular (8), ack_number ::= lsb (15, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), Pelletier, et. al [Page 84] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_7 ::= discriminator, % 5 bits header_crc, % 3 bits ttl, % 8 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ack_number, % 15 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '00111', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 40), ttl ::= irregular (8), ack_number ::= lsb (15, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_8 ::= discriminator, % 5 bits header_crc, % 3 bits window, % 16 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ack_number, % 15 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '00001', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, Pelletier, et. al [Page 85] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 ecn_flags ::= value (2, 52), ack_number ::= lsb (15, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), window ::= irregular (16), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_9 ::= discriminator, % 5 bits msn, % 3 bits ack_number, % 32 bits tcp_checksum, % 16 bits psh_flag, % 1 bit header_crc, % 3 bits seq_number, % 12 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '00100', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (3, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 1500), seq_number ::= lsb (12, 1023), ack_number ::= irregular (32), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), tcp_checksum ::= irregular (16) } , format_co_10 ::= discriminator, % 5 bits header_crc, % 3 bits window, % 16 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ack_number, % 15 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '00010', msn ::= control_field, Pelletier, et. al [Page 86] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 40), ack_number ::= lsb (15, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), window ::= irregular (16), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, format_co_11 ::= discriminator, % 5 bits header_crc, % 3 bits ttl, % 8 bits window, % 16 bits tcp_checksum, % 16 bits psh_flag, % 1 bit ack_number, % 15 bits msn, % 4 bits seq_number.scaled, % 12 bits ecn_and_reserved, % 0/ 8 bits ip_id, % 0/16 bits { discriminator ::= '00110', msn ::= control_field, { base_field ::= counter(16), compressed_method ::= lsb (4, -1) }, header_crc ::= crc3, ecn_flags ::= value (2, 40), ttl ::= irregular (8), ack_number ::= lsb (15, 0), urg_flag ::= value (1, 0), ack_flag ::= value (1, 1), psh_flag ::= irregular (1), rsf_flags ::= value (3, 0), window ::= irregular (16), tcp_checksum ::= irregular (16), seq_number.scaled ::= lsb (12, 1) }, } } 6.6.7. Static Chain Pelletier, et. al [Page 87] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tcpip_static_chain ::= chain { chain_items ::= ipv6.ipv6_static, ipv4.ipv4_static, mine.mine_static, gre.gre_static, ah.ah_static, esp.esp_static, hop_opt.hop_opt_static, dest_opt.dest_opt_static, route_opt.route_opt_static, tcp.tcp_static chain_start ::= IPPROTO_IP, chain_end ::= IPPROTO_TCP } 6.6.8. Dynamic Chain tcpip_dynamic_chain ::= chain { chain_items ::= ipv6.ipv6_dynamic, ipv4.ipv4_dynamic, mine.mine_dynamic, gre.gre_dynamic, ah.ah_dynamic, esp.esp_dynamic, hop_opt.hop_opt_dynamic, dest_opt.dest_opt_dynamic, route_opt.route_opt_dynamic, tcp.tcp_dynamic chain_start ::= IPPROTO_IP, chain_end ::= IPPROTO_TCP } 6.6.9. Irregular Chain tcpip_irregular_chain ::= chain { chain_items ::= ipv6.ipv6_irregular, ipv4.ipv4_irregular, mine.mine_irregular, gre.gre_irregular, ah.ah_irregular, esp.esp_irregular, hop_opt.hop_opt_irregular, dest_opt.dest_opt_irregular, route_opt.route_opt_irregular, tcp.tcp_irregular chain_start ::= IPPROTO_IP, chain_end ::= IPPROTO_TCP } 6.6.10. Replication Chain Pelletier, et. al [Page 88] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 tcpip_replicate_chain ::= chain { chain_items ::= ipv6.ipv6_replicate, ipv4.ipv4_replicate_0, mine.mine_replicate_0, gre.gre_replicate_0, ah.ah_replicate_0, esp.esp_replicate_0, hop_opt.hop_opt_replicate_0, dest_opt.dest_opt_replicate_0, route_opt.route_opt_replicate_0, tcp.tcp_replicate_0, ipv4.ipv4_replicate_1, mine.mine_replicate_1, gre.gre_replicate_1, ah.ah_replicate_1, esp.esp_replicate_1, hop_opt.hop_opt_replicate_1, dest_opt.dest_opt_replicate_1, route_opt.route_opt_replicate_1, tcp.tcp_replicate_1 chain_start ::= IPPROTO_IP, chain_end ::= IPPROTO_TCP } 6.7. Feedback Formats and Options 6.7.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 [2]. All feedback formats carry a field labeled SN. The SN field contains LSBs of the Master Sequence Number (MSN) described in section 6.2. 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. 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. Pelletier, et. al [Page 89] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 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 parseability) MSN: The lsb-encoded master sequence number. Feedback options: A variable number of feedback options, see section 6.7.2. Options may appear in any order. 6.7.2. Feedback Options ROHC-TCP uses the same feedback options as the options defined in section 5.7.6 of [2], with the following exceptions: 1) The MSN replaces RTP SN in the feedback information. 2) The CLOCK option ([2], section 5.7.6.6) is not used. 3) The JITTER option ([2], section 5.7.6.7) is not used. 6.7.3. 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. 7. Security Consideration Pelletier, et. al [Page 90] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 Because encryption eliminates the redundancy that header compression schemes try to exploit, there is some inducement to forego encryption of headers in order to enable operation over low-bandwidth links. However, for those cases where encryption of data (and not headers) is sufficient, TCP does specify an alternative encryption method in which only the TCP payload is encrypted and the headers are left in the clear. That would still allow header compression to be applied. 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. 8. 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 9. Acknowledgments Pelletier, et. al [Page 91] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 The authors would like to thank Qian Zhang and Hong Bin Liao for their work with early versions of this specification. Thanks also to Fredrik Lindstroem for reviewing the packet formats, as well as to Carsten Bormann and Robert Finking for valuable input. 10. Authors' Addresses Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 29 43 Fax: +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 29 61 Fax: +46 920 996 21 EMail: lars-erik.jonsson@ericsson.com Mark A West Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Phone: +44 1794 833311 Email: mark.a.west@roke.co.uk Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Phone: +44 1794 833681 Email: richard.price@roke.co.uk Kristofer Sandlund Pelletier, et. al [Page 92] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 Effnet AB Stationsgatan 69 S-972 34 Lulea Sweden Phone: +46 920 609 17 Fax: +46 920 609 27 EMail: kristofer.sandlund@effnet.com 11. References 11.1. Normative references [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] 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. [3] Pelletier, G., "Robust Header Compression (ROHC): Context Replication for ROHC profiles", Internet Draft (work in progress), , July 2004. [4] R. Price, R. Finking and G. Pelletier, "Formal Notation for Robust Header Compression (ROHC-FN)", Internet Draft (work in progress), , July 2004. [5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [7] S. Bradner, "The Internet Standards Process - Revision 3", RFC 2026, October 1996. [8] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 11.2. Informative References Pelletier, et. al [Page 93] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 [10] Jonsson, L-E., "Requirements on ROHC IP/TCP header compression", Internet Draft (work in progress), , June 2004. [11] West, M. and S. McCann, "TCP/IP Field Behavior", Internet Draft (work in progress), , July 2004. [12] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A compression profile for IP", RFC 3843, June 2003. [13] Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths", LBL, ISI, October 1988. [14] Jacobson, V.,"Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [15] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [16] Braden, R. "T/TCP -- TCP Extensions for Transactions Functional Specification", ISI, July 1994. [17] Connolly, T., et al, "An Extension to TCP: Partial Order Service", University of Delaware, November 1994. [18] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [19] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", NOAO, January 1997. [20] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [21] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999. [22] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. [23] Ramakrishnan, K., Floyd and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [24] Jacobson, V., "Fast Retransmit", Message to the end2end-interest mailing list, April 1990. Copyright Statement Pelletier, et. al [Page 94] INTERNET-DRAFT ROHC Profile for TCP/IP July 16, 2004 Copyright (C) The Internet Society (2004). 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. 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. This Internet-Draft expires January 16, 2005. Pelletier, et. al [Page 95]