Network Working Group Richard Price, Siemens/Roke Manor INTERNET-DRAFT Mark A West, Siemens/Roke Manor Expires: November 2003 May 28, 2003 TCP/IP Compressed Packet Formats Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/1id-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 its mailing list, rohc@ietf.org. Abstract This document proposes a set of compressed packet formats for the ROHC-TCP compression profile [ROHC-TCP]. The ROHC-TCP profile 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. Price et al. [Page 1] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 Table of contents 1. Introduction..................................................2 2. Terminology...................................................3 3. Discussion and open issues....................................3 4. Packet formats described using ROHC-FN........................14 5. Security considerations.......................................19 6. Authors' addresses............................................19 7. References....................................................19 Appendix A: Packet formats described using box notation...........20 1. Introduction The ROHC-TCP compression profile [ROHC-TCP] describes a header compression scheme for TCP/IP that is robust against packet loss and which offers enhanced capabilities, in particular for the compression of header fields including TCP options. ROHC-TCP is offered as a profile for the ROHC framework [RFC-3095], compliant with the requirements on ROHC TCP/IP header compression [TCP-REQ]. An important missing piece of the current ROHC-TCP profile is a set of compressed packet formats, which can be used to encode the information contained in a TCP/IP header into a more compact form. This document proposes a set of packet formats for ROHC-TCP, designed to offer a suitable balance between compression efficiency, robustness, future-proofing and implementation complexity. Section 3 of the draft contains a discussion of the various design decisions taken when generating the TCP/IP packet formats. The topics which may benefit from further discussion are marked as "open issues" - the authors would welcome additional feedback and suggestions on any of these topics. Section 4 gives the normative description of the proposed set of TCP/IP packet formats, using the Formal Notation for Robust Header Compression [ROHC-FN]. The ROHC-FN description of the packet formats specifies all of the information needed to compress and decompress a header relative to the context. In particular, it 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. Appendix A provides an informative description of the fields present in each compressed packet, using the traditional RFC "box notation". The packet format diagrams can be derived automatically from the ROHC-FN description via a suitable tool (note however that the converse is not possible as the box notation defines the fields present in each compressed header, but does not explain how to map them to the corresponding uncompressed headers). Price et al. [Page 2] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 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 [RFC-2119]. An explanation of the terminology used in this document can be found in [ROHC-TCP]. 3. Discussion and open issues The following sections discuss the various design decisions taken when generating the TCP/IP packet formats. The topics which may benefit from further discussion are marked as "open issues" - additional feedback and suggestions on any of these would be gratefully received. 3.1. IPv4 This section covers the fields found in an IPv4 header. Open issue: Currently we only handle a single IPv4 header - how many nested IPv4 headers do we need to handle in the final profile? Also, how many IPv4 headers do we need to actually compress (as opposed to merely passing through transparently)? 3.1.1. IP Version For IPv4, the IP Version is a 4-bit field that always takes the value 4. Hence it can be encoded using the "value(4,4)" encoding method, requiring no bits in the compressed header. Open issue: In RFC 3095, the IP Version field is transmitted in full in the IR packet. However, since the field can only take two possible values (4 or 6), why not compress it down to a single bit? 3.1.2. IP Header Length As long as no options are present in the IP header, the header length must always take the value 5. Consequently it can be encoded as "value(4,5)", and no bits are required in the compressed header. 3.1.3. IP Type of Service As per [TCP-BEH], the IP TOS field is divided into a 6-bit DSCP (DiffServ Codepoint) field followed by a pair of ECN flags. The DSCP field is currently encoded as "static" in the CO packets and as "irregular(6)" in the IR(-DYN) packets (i.e. it is transmitted in full). Price et al. [Page 3] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 Open issue: How should the DSCP field be handled in the IR-REPLICATE packets? It is likely that replicable flows will share the same DSCP, but this is not 100% guaranteed. Therefore, would it be sensible to offer two possible encodings for the DSCP field ("static" and "irregular") in the IR-REPLICATE packet? The behavior of the ECN flags is linked to the behavior of the ECN flags in the TCP header. See Section 3.3.5 for a description of how these flags are encoded. 3.1.4. IP Packet Length The IP Packet Length is a 16-bit field whose value can be inferred from the total size of the uncompressed packet. Therefore, we encode the field using the "inferred_size" encoding method and send no bits in the compressed header. 3.1.5. IP-ID The IP-ID is currently compressed in two steps. Firstly, the Master Sequence Number (MSN) is subtracted from the uncompressed IP-ID. Secondly, the resulting offset bits are compressed using a choice of encoding method: in the CO packets the offset can be encoded as "static" or as "lsb(8,0)", but in the IR(-DYN) packets it is transmitted in full. For the purpose of calculating the discriminator bits, the "static" encoding method is expected to be used in 90% of the CO packets, and the "lsb(8,0)" encoding method is expected to be used in 10% of the CO packets. Open issue: Should we take into account the Network Byte Order (NBO) when deriving the IP-ID offset from the MSN? Open issue: Should we generate two different sets of packet formats, one for a sequential IP-ID and one for a random IP-ID, as per RFC 3095? Open issue: In the Linux TCP stack, the IP-ID seems to be set to 0 in the SYN, SYN-ACK and FIN packets. Is it worth taking this behavior into account? Open issue: Can we replicate the IP-ID from a base context? 3.1.6. IP Reserved Flag As per [RFC-3095], the IP Reserved Flag is assumed to always take the value 0. Thus, it can be encoded as "value(1,0)", and no bits are required in any of the compressed headers. Price et al. [Page 4] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 Open issue: In [TCP-BEH], it is suggested that assuming the IP Reserved Flag is always 0 may be too restrictive. For future proofing, is it worth including a packet format where this flag can take a non-zero value? 3.1.7. IP Don't Fragment Flag As per [TCP-BEH], the IP Don't Fragment Flag is expected to generally remain constant for the duration of a flow. In the CO packets, we currently offer a choice of two encoding methods: "static" and "irregular(1)". In the IR(-DYN) packets the flag is always sent in full. When calculating the discriminator bits, the "static" encoding is expected to be used in 99% of the CO packets. Open issue: Is there any need to have the CO packet that sends the Don't Fragment Flag explicitly? 3.1.8. IP More Fragments Flag As per [RFC-3095], the IP More Fragments Flag is assumed to always take the value 0. Thus, it can be encoded as "value(1,0)", and no bits are required in any of the compressed headers. 3.1.9. IP Fragment Offset As per [RFC-3095], the IP Fragment Offset is assumed to always take the value 0. Thus, it can be encoded as "value(13,0)", and no bits are required in any of the compressed headers. 3.1.10. IP Time To Live The IP Time To Live field is expected to generally remain constant for the duration of a flow. In the CO packets, we currently offer a choice of two encoding methods: "static" and "irregular(8)". In the IR(-DYN) packets the flag is always sent in full. When calculating the discriminator bits, the "static" encoding is expected to be used in 99% of the CO packets. Open issue: Should the IR-REPLICATE packet allow the TTL field to be replicated? Open issue: The TTL field will often take one of a small set of well- known values (e.g. 32 and 64) corresponding to the default values of common IP stacks. Is it worth providing special handling for these values in the IR packet? Price et al. [Page 5] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 3.1.11. IP Protocol The value of the IP Protocol field can be derived from the type of header that follows in the extension header chain. Consequently, it does not need to be transmitted in the compressed packets. Note: We propose a more complex encoding for the extension header chain and the TCP options than used in [RFC-3095]. See Section 3.4 for further details. 3.1.12. IP Checksum The IP Checksum can be reconstructed at the decompressor, and thus does not need to be transmitted in the compressed packets. 3.1.13. IP Source and Destination Addresses The IP Source and Destination Addresses are part of the definition of a flow. Consequently they are transmitted in full in the IR packets, but are assumed to be "static" in the IR-DYN and the CO packets. 3.2. IPv6 The only field in the IPv6 header that does not have an equivalent in the IPv4 header is the Flow Label, which is expected to remain constant for the duration of a flow. Consequently, the proposed set of CO packets for IPv4 is also capable of encoding the information contained in an IPv6 header. Note however that a number of fields in the IPv4 header (IP-ID, DF flag etc.) have no direct equivalents in the IPv6 header, and so a number of the CO packets are redundant when compressing IPv6. Open issue: Is it worth having a separate (simpler) set of packet formats to handle IPv6? 3.3. TCP This section discusses the fields contained in a basic TCP header. The TCP options are covered separately in Section 3.4. 3.3.1. TCP Source and Destination Ports The TCP Source and Destination Ports are part of the definition of a flow. Consequently they are transmitted in full in the IR packets, but are assumed to be "static" in the IR-DYN and the CO packets. Price et al. [Page 6] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 3.3.2. TCP Sequence Number and Acknowledgement Number The behavior of the TCP Sequence Number and Acknowledgement Number are closely related, so from a compression point-of-view it is useful to consider these fields together. The proposed set of packet formats currently handles six distinct behaviors patterns for the Sequence and Ack Numbers, listed below: Behavior: Seq Number Encoding: Ack Number Encoding: Likelihood: 0 static static 48% 1 lsb(11,256) lsb(11,256) 20% 2 static lsb(14,4096) 15% 3 lsb(14,4096) static 15% 4 static lsb(18,65536) 1% 5 lsb(18,65536) static 1% In the IR(-DYN) packets, both fields are currently transmitted in full. Open issue: The Sequence and Ack Numbers exhibit more structured behavior than is currently taken into account in the packet formats. For example, in a bulk data transfer the Sequence and Ack Numbers will often increase by a fixed value for each successive packet (barring retransmissions). Is it worth offering a more complex encoding of the Sequence and Ack Numbers to take this behavior into account? 3.3.3. TCP Data Offset The TCP Data Offset is a 4-bit field that can be used to determine the end of the TCP options and the beginning of the payload data. Since we explicitly encode the list of options that are included in the TCP header, the Data Offset field can be inferred from this information and does not need to be transmitted in the compressed header. See Section 3.4 for a discussion on how to compress the TCP options. 3.3.4. TCP Reserved Bits In current TCP stacks the TCP Reserved Bits are always set to 0. However, in future TCP stacks a use for the Reserved Bits may be found (and hence one or more of the bits may take a non-zero value). For the proposed set of packet formats, we compromise by encoding the Reserved Bits as "static" in the CO packets, but sending them in full in the IR(-DYN) packets. Price et al. [Page 7] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 Open issue: How much future proofing is needed for the TCP Reserved Bits? Is it worth allowing them to be set to non-zero values? Open issue: An example of a proposed use for the TCP Reserved Bits is to provide a Nonce Sum (NS) of the ECT codepoints in the IP header. If the NS bit is used then it is expected to change randomly in successive packets, which can currently only be handled by sending IR(-DYN) packets. Should we handle this behavior more efficiently by providing extra CO packet formats? 3.3.5. TCP ECN Flags The ECN flags from the IP and TCP headers have related behavior, so for maximum efficiency it is proposed to compress them together. The overall behavior of the ECN flags is expected to fall into one of two categories, depending on whether the TCP/IP stack has adopted the ECN mechanism or not. If ECN is not used then all of the flags will be set to zero and do not need to be sent in the compressed packets. When Explicit Congestion Notification is used then, for simplicity, the proposed set of packet formats simply transmits the four ECN flags in full. When generating the discriminator bits, the ECN flags are expected to be unused in 99% of the CO packets. Open issue: The choice of whether or not to use ECN is likely to remain constant for the duration of a flow, so better efficiency can be obtained by offering two distinct sets of packet formats (one designed to handle the case where ECN is used and the other for handling the case where it is not). Is this efficiency gain worth the extra complexity of having multiple sets of packet formats? Open issue: Even when a stack employs ECN, the behavior displayed by the four ECN flags is clearly non-random. Is there any value in exploiting this additional redundancy to improve the overall compression ratio? 3.3.6. TCP URG Flag The TCP URG Flag is currently compressed together with the TCP Urgent Pointer, as described in Section 3.3.12. 3.3.7. TCP ACK Flag The TCP ACK Flag is known to be set to 1 in all packets except for the initial SYN. Consequently, it is encoded as "value(1,1)" in the CO packets, but is transmitted in full in the IR(-DYN) packets. Price et al. [Page 8] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 3.3.8. TCP PSH Flag The behavior of the TCP PSH Flag is heavily dependent on the implementation of the TCP stack (for a given flow the PSH Flag may be biased towards 0, biased towards 1, or may randomly change between the two values). Consequently, it is proposed to carry the PSH Flag explicitly in all compressed packets. Open issue: Is there any value in attempting to compress the PSH Flag? 3.3.9. TCP RST, SYN and FIN Flags The RST, SYN and FIN flags have related behaviour, so it is proposed to compress them together as a single field. The CO packets can currently handle three behavior patterns for the RST, SYN and FIN flags, which are illustrated below: Behavior: RST Flag: SYN Flag: FIN Flag: Likelihood: 0 0 0 0 90% 1 1 0 0 5% 2 0 0 1 5% In the IR(-DYN) packets the flags are sent in full (in particular, this allows us to handle the initial SYN and SYN-ACK packets where the SYN Flag is set to 1). 3.3.10. TCP Window The TCP Window is expected to either remain constant between successive packets, or to oscillate between 0 and the receiver's window limit for the connection. Consequently, in the CO packets the TCP Window can be encoded as "static" or as "lsb(15,4096)". Note: We initially proposed to encode the TCP Window using 13 LSBs, but increased this when we discovered that two spare bits were available in the corresponding packet format. In future versions of the packet formats, these extra bits may be put to a different use. When calculating the discriminator bits, the TCP Window is expected to remain constant for 70% of the packets in a flow. In the IR(-DYN) packets the TCP Window is sent in full. Open issue: We currently assume that the TCP Window remains constant more often than not. Is this assumption reasonable? Price et al. [Page 9] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 3.3.11. TCP Checksum In order to avoid breaking end-to-end error protection, the TCP Checksum is carried in full in all compressed packets. 3.3.12. TCP Urgent Pointer The URG Flag and the Urgent Pointer have related behavior, so we propose to compress them together. If the URG Flag is set to 0 then the Urgent Pointer is ignored by the receiving endpoint, and can be set to an arbitrary value. However, in the current CO packets it is assumed that the Urgent Pointer is encoded as "static" (i.e. it remains constant relative to the previous header). Open issue: It is assumed that if the URG Flag is zero then the Urgent Pointer will remain constant between successive headers. Are there any TCP stacks for which this assumption is false? For example, could the Urgent Pointer be reset to 0 after the urgent data? In the IR(-DYN) packets, both the URG Flag and the Urgent Pointer are carried in full. Note that if the URG Flag is set to 1 then an IR(-DYN) packet must be sent, as there are currently no CO packets that can carry an URG Flag of 1. Open issue: Will the URG Flag be set often enough to warrant its own packet format (currently we assume that the answer is "no")? 3.4. TCP Options From a compression perspective, perhaps the most difficult part of the TCP/IP header is the list of TCP options. The list of options often displays complex behavior, which is difficult to compress using the techniques previously applied to RTP, UDP and IP headers. One problem with the list of TCP options is that, unlike e.g. the IP extension header chain, we typically get quite a large number of TCP options in a given packet - and moreover, the precise set of options will often be different for the initial SYN packet than for the main body of the flow. Using the insert/remove scheme from [RFC-3095], a minimum of 2-3 bytes must be sent to re-establish the options list whenever it changes (even when context replication is used to preserve the indices assigned to each list item). Our alternative proposal for handling this is to determine the set of possible TCP options in advance, and then to only transmit a set of flags indicating which of the options are present in the uncompressed Price et al. [Page 10] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 packet, and the order in which they occur. Together with any compressed data needed by the individual options, this is enough information for the complete list of options to be reconstructed at the decompressor. In the proposed IR packet it currently costs 1 byte to send the flags indicating whether or not each option is present in the header, and 3 bytes to send the flags indicating the order in which the options occur. However, it is expected that the order of the TCP options will not change for a particular TCP stack, so this 3-byte field can be replicated between different flows. It is therefore expected that only the 1-byte presence flags will need to be sent to initialize the TCP options in a new flow. Open issue: It may be possible to further improve the compression ratio of the TCP options by providing special handling for the SYN packets (e.g. by storing the list of options separately for the SYN packets than for the rest of the flow). Is it worth the extra effort to save an additional byte in the first few packets of the flow? Open issue: Is it worth including flags in the CO packets, to handle options that appear and disappear within the same flow (e.g. SACK)? The following sections discuss how each of the individual TCP options is compressed. 3.4.1. End of Option List The End of Option List option consists of a 1-byte "Kind" field that takes the value 0. Consequently, it can be encoded as "value(8,0)", and no bits need to be sent in the compressed header. 3.4.2. No Operation The No Operation option consists of a 1-byte "Kind" field that takes the value 1. Consequently, it can be encoded as "value(8,1)", and no bits need to be sent in the compressed header. 3.4.3. SACK The TCP SACK option consists of a 1-byte Kind field and a 1-byte Length field, followed by one or more 8-byte SACK block structures each acknowledging a block of data. The current set of packet formats does not attempt particularly aggressive compression of the SACK option. The Kind field is encoded as "value(8,5)", and hence does not need to be sent in the compressed header - however the SACK blocks themselves are always sent uncompressed. Price et al. [Page 11] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 Open issue: Will the SACK option occur often enough to warrant more aggressive compression than just sending the SACK blocks uncompressed? 3.4.4. Timestamp The TCP Timestamp option consists of a 1-byte Kind field and a 1-byte Length field, followed by a 4-byte Timestamp Value (TSval) field and a 4-byte Timestamp Echo Reply (TSecr) field. In the CO packets, the two timestamp fields are currently compressed using self-describing variable-length values encoding (see Section 4.5.6 of [RFC-3095]). In the IR(-DYN) packets the fields are sent in full. Open issue: Is it possible to get more aggressive compression of the timestamp fields, e.g. by using some form of scaled timestamp encoding? Open issue: Is it worth linking the compression of the Timestamp option to the value carried in the ACK Flag? When the ACK Flag is zero, the TSecr field is not valid and therefore must be set to 0 (potentially saving 4 bytes in the compressed header). 3.4.5. Maximum Segment Size TBD - currently we encode this as a generic TCP option, but in future it is proposed to handle the MSS via specialized packet formats. 3.4.6. Window Scale TBD - currently we encode this as a generic TCP option, but in future it is proposed to handle the WSopt via specialized packet formats. 3.4.7. SACK Permitted TBD - currently we encode this as a generic TCP option, but in future it is proposed to have special handling for the SACK Permitted option (note that no additional packet formats will be required, as the option can always be compressed down to 0 bits). 3.4.8. Generic TCP Options Any TCP option that is not handled explicitly by the packet formats can be encoded as a "genetic TCP option". In this case, the Kind and Length fields are transmitted in full in the IR(-DYN) packets so that the decompressor can store the Kind and Length of the new option. In the CO packets the Kind and Length are assumed to be "static" relative to the context. Price et al. [Page 12] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 If present, any remaining fields in a generic TCP option are always transmitted in full. Open issue: Are there any TCP options currently encoded as generic options, but which would benefit from specialized packet formats? Open issue: Are there any generic TCP options that would benefit from a more aggressive encoding of the option data? For example, are there any cases where the option data remains static between successive headers? 3.5. IP Extension Headers TBD. Open issue: Are there any IP extension headers that need to be encoded differently for TCP/IP than for UDP/IP? Are there any improvements that would be worth making relative to the encodings used in [RFC-3095]? 3.6. Control fields This section discusses the control fields that must be transmitted in the compressed TCP/IP packet formats. Note that a control field contains information that is not present in the original uncompressed header, but which may be useful for the decompressor (examples include a CRC to verify that the header has been successfully decompressed). 3.6.1. Master Sequence Number The Master Sequence Number (MSN) is a control field created by the compressor. It currently has the following two functions: 1. Differentiating between packets when sending feedback data. 2. Inferring the value of incrementing fields such as the IP-ID. Currently we send 2 LSBs of the MSN in each CO packet, and send the 16-bit MSN in full in the IR(-DYN) packets. Open issue: Is it necessary/useful to send the MSN in every CO packet? Open issue: Can we encode the MSN more aggressively in the IR(-DYN) packets by taking into account the fact that it will be biased towards 0? Price et al. [Page 13] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 3.6.2. Header CRC From a robustness perspective, it is useful for the compressed packets to contain a CRC calculated over the original uncompressed header. The decompressor can use this CRC to verify that it has successfully reconstructed the uncompressed header, guarding against errors in either the compressed packet or the context that may cause the decompression process to fail. The current set of packet formats provides a 3-bit header CRC in every packet (including both the CO packets and the IR(-DYN) packets). Open issue: Does a 3-bit CRC provide enough robustness for the expected link error conditions? Open issue: Would it be useful to provide additional CRC protection in the packet formats that contain a large amount of context-updating information? 3.6.3. Padding Due to the restrictions imposed by the link layer, it is necessary for all of the compressed packet formats to be aligned to a whole number of bytes. However, in some of the proposed packet formats, a number of spare bits are left over after encoding all of the information needed by the decompressor. These bits are currently marked as "padding" - set to 0 by the compressor and ignored by the decompressor. Open issue: What should we do with the spare bits in the compressed header formats? Possible choices include - using the bits to carry more LSBs of a field such as the MSN, using the bits to carry additional CRC protection, or reserving the bits for use in future versions of the profile. 4. Packet formats described using ROHC-FN The following section describes the proposed set of TCP/IP packet formats using the Formal Notation for Robust Header Compression [ROHC-FN]. See [ROHC-FN] for an explanation of the Formal Notation itself, and the encoding methods used to compress each of the fields in the TCP/IP header. tcp_ip_formats ::= ordinary_huffman(tcp_ip_header) tcp_ip_header ::= create_msn ip_header tcp_header master_seq_number Price et al. [Page 14] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 header_crc ip_header ::= inferred_ip_checksum inferred_size(16,-16) ip_version ip_header_length ip_tos ip_length ip_id ip_reserved ip_dont_fragment ip_more_fragments ip_offset ip_time_to_live ip_protocol ip_checksum ip_source_address ip_dest_address tcp_header ::= tcp_checksum tcp_source_port tcp_dest_port tcp_seq_number tcp_ack_number tcp_data_offset tcp_reserved tcp_ip_ecn_fields tcp_urg tcp_ack_flag tcp_psh_flag tcp_rsf_flags tcp_window tcp_urg_fields tcp_options ip_version ::= value(4,4) ip_header_length ::= value(4,5) ip_tos ::= static // irregular(6) label(2,ecn) ip_length ::= skip(16) ip_id ::= inferred_offset(16,msn) static 90% / lsb(8,0) 10% // irregular(16) ip_reserved ::= value(1,0) ip_dont_fragment ::= static 99% / irregular(1) 1% Price et al. [Page 15] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 ip_more_fragments ::= value(1,0) ip_offset ::= value(13,0) ip_time_to_live ::= static 99% / irregular(8) 1% ip_protocol ::= value(8,6) ip_checksum ::= skip(16) ip_source_address ::= static // irregular(32) ip_dest_address ::= static // irregular(32) tcp_source_port ::= static // irregular(16) tcp_dest_port ::= static // irregular(16) tcp_seq_number ::= (static change(behav,nil,0) 48%) / (lsb(11,256) change(behav,nil,1)) 20% / (static change(behav,nil,2)) 15% / (lsb(14,4096) change(behav,nil,3)) 15% / (static change(behav,nil,4)) 1% / (lsb(18,65536) change(behav,nil,5)) 1% // (irregular(32) change(behav,nil,6)) tcp_ack_number ::= (static change(behav,0,nil)) / (lsb(11,256) change(behav,1,nil)) / (lsb(14,4096) change(behav,2,nil)) / (static change(behav,3,nil)) / (lsb(18,65536) change(behav,4,nil)) / (static change(behav,5,nil)) / (irregular(32) change(behav,6,nil)) tcp_data_offset ::= label(4,data_offset) tcp_reserved ::= static // irregular(4) tcp_ip_ecn_fields ::= ecn_unused 99% / ecn_used 1% ecn_unused ::= next_field(ecn) value(2,0) value(2,0) ecn_used ::= next_field(ecn) ip_ecn_bits tcp_ecn_bits ip_ecn_bits ::= irregular(2) tcp_ecn_bits ::= irregular(2) Price et al. [Page 16] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 tcp_urg ::= label(1,urg_flag) tcp_ack_flag ::= value(1,1) // irregular(1) tcp_psh_flag ::= irregular(1) tcp_rsf_flags ::= value(3,0) 90% / value(3,4) 5% / value(3,1) 5% // irregular(3) tcp_window ::= static 70% / lsb(15,4096) 30% // irregular(16) skip(16) tcp_checksum ::= map(temp,nil,val(remaining_data)) map(remaining_data,val(temp),val(temp) - 128) irregular(16) map(remaining_data,val(temp) - 144,val(temp)) map(temp,val(remaining_data),nil) tcp_urg_fields ::= next_field(urg_flag) urgf_zero // urgf_one urgf_zero ::= value(1,0) static urgf_one ::= tcp_urg_flag tcp_urg_pointer tcp_urg_flag ::= irregular(1) tcp_urg_pointer ::= irregular(16) tcp_options ::= list(data_offset,1,32,-160, [optional(tcp_sack), optional(tcp_timestamp), optional(tcp_end), optional(tcp_no_operation), optional(tcp_no_operation), optional(tcp_generic), optional(tcp_generic), optional(tcp_generic)]) tcp_options_order tcp_options_presence tcp_options_order ::= next_field(order) static // irregular(24) tcp_options_presence ::= next_field(presence) Price et al. [Page 17] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 static // irregular(8) tcp_end ::= value(8,0) tcp_no_operation ::= value(8,1) tcp_sack ::= tcp_sack_kind tcp_sack_len tcp_sack_block tcp_sack_kind ::= value(8,5) tcp_sack_len ::= label(8,tcp_sack_length) tcp_sack_block ::= uncompressible(tcp_sack_length,8,-16) tcp_sack_length tcp_sack_length ::= next_field(tcp_sack_length) static // irregular(8) tcp_timestamp ::= tcp_ts_kind tcp_ts_length tcp_ts_value tcp_ts_echo_reply tcp_ts_kind ::= value(8,8) tcp_ts_length ::= value(8,10) tcp_ts_value ::= self_describing_values(8,7) // irregular(32) tcp_ts_echo_reply ::= self_describing_values(8,7) // irregular(32) tcp_generic ::= tcp_generic_kind tcp_generic_len tcp_generic_option tcp_generic_kind ::= static // irregular(8) tcp_generic_len ::= label(8,tcp_generic_length) tcp_generic_option ::= uncompressible(tcp_generic_length,8,-16) tcp_generic_length tcp_generic_length ::= next_field(tcp_generic_length) static // irregular(8) master_seq_number ::= next_field(msn) lsb(2,0) // irregular(16) Price et al. [Page 18] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 header_crc ::= map(current_field,nil,0) irregular(3) 5. Security considerations This draft describes a set of packet formats for ROHC-TCP [ROHC-TCP]. Consequently the security considerations for this draft match those of ROHC-TCP. 6. Authors' addresses Richard Price Tel: +44 1794 833681 Email: richard.price@roke.co.uk Mark A West Tel: +44 1794 833311 Email: mark.a.west@roke.co.uk Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom 7. References 7.1. Normative references [ROHC-FN] "Formal Notation for Robust Header Compression (ROHC-FN)", R. Price et al., (work in progress), March 2003 [RFC-2026] "The Internet Standards Process - Revision 3", S. Bradner, Internet Engineering Task Force, October 1996 [RFC-2119] "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, Internet Engineering Task Force, March 1997 7.2. Informative references [ROHC-TCP] "RObust Header Compression (ROHC): TCP/IP Profile (ROHC- TCP)", G. Pelletier et al., (work in progress), May 2003 [TCP-BEH] "TCP/IP Field Behavior", M. West and S. McCann, (work in progress), March 2003 [TCP-REQ] "Requirements on ROHC IP/TCP header compression", L-E. Jonsson, (work in progress), October 2002. Price et al. [Page 19] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 [RFC-3095] "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", C. Bormann et al., Internet Engineering Task Force, July 2001. Appendix A: Packet formats described using box notation This appendix provides an informative description of the fields in each compressed packet, using the traditional RFC "box notation". Note that the appendix does not provide the mapping between the uncompressed and compressed versions of each field (this can be found in Section 4). Key: "|" indicates the beginning/end of a field. ":" indicates that a field is split over multiple octets. Abbreviations: A = TCP_ACK_FLAG MSN = MASTER_SEQ_NUMBER I = IP_DONT_FRAGMENT TEB = TCP_ECN_BITS M = MASTER_SEQ_NUMBER TRF = TCP_RSF_FLAGS P = PADDING U = TCP_URG_FLAG T = TCP_PSH_FLAG HC = HEADER_CRC IEB = IP_ECN_BITS Packet 0: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 0 | HC | MSN | T | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 1: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 1 0 | HC | MSN | +---+---+---+---+---+---+---+---+ | TCP_WINDOW : +---+---+---+---+---+---+---+---+ Price et al. [Page 20] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 +---+---+---+---+---+---+---+---+ : | T | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 2: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 1 1 | HC | MSN | +---+---+---+---+---+---+---+---+ | T | TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | P | +---+---+---+---+---+---+---+---+ Packet 3: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 0 0 | HC | M : +---+---+---+---+---+---+---+---+ : | T | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 4: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 0 1 | HC | M : +---+---+---+---+---+---+---+---+ : | T | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER | +---+---+---+---+---+---+---+---+ Price et al. [Page 21] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 5: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 0 0 | HC | +---+---+---+---+---+---+---+---+ | MSN | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | T | TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 6: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 0 1 | HC | +---+---+---+---+---+---+---+---+ | MSN | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | T | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Price et al. [Page 22] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 Packet 7: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 1 0 | HC | +---+---+---+---+---+---+---+---+ | MSN | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | T | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 8: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 1 1 | HC | +---+---+---+---+---+---+---+---+ | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 9: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 0 0 | HC : +---+---+---+---+---+---+---+---+ : | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Price et al. [Page 23] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 Packet 10: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 0 1 | HC : +---+---+---+---+---+---+---+---+ : | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 11: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 1 0 | HC : +---+---+---+---+---+---+---+---+ : | MSN | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | T | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 12: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 1 1 | HC : +---+---+---+---+---+---+---+---+ : | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | IP_ID : +---+---+---+---+---+---+---+---+ Price et al. [Page 24] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 13: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 0 0 | : +---+---+---+---+---+---+---+---+ : HC | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 14: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 0 1 | : +---+---+---+---+---+---+---+---+ : HC | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 15: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 1 0 | : +---+---+---+---+---+---+---+---+ : HC | MSN | : +---+---+---+---+---+---+---+---+ Price et al. [Page 25] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | T | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 16: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 1 1 | : +---+---+---+---+---+---+---+---+ : HC | MSN | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | T | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 17: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 0 0 | : +---+---+---+---+---+---+---+---+ : HC | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER | +---+---+---+---+---+---+---+---+ | TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Price et al. [Page 26] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 Packet 18: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 0 1 | : +---+---+---+---+---+---+---+---+ : HC | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER | +---+---+---+---+---+---+---+---+ | TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ Packet 19: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 0 | : +---+---+---+---+---+---+---+---+ : HC | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | P | +---+---+---+---+---+---+---+---+ Packet 20: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 0 | +---+---+---+---+---+---+---+---+ | HC | MSN | T | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ Price et al. [Page 27] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 21: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ | HC | MSN | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | T | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER | +---+---+---+---+---+---+---+---+ | TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM : +---+---+---+---+---+---+---+---+ : | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ IR-DYN Packet: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 0 | 0 | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : MASTER_SEQ_NUMBER | +---+---+---+---+---+---+---+---+ | TCP_OPTIONS_PRESENCE | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_OPTIONS_ORDER : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_URG_POINTER | +---+---+---+---+---+---+---+---+ Price et al. [Page 28] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 +---+---+---+---+---+---+---+---+ | U | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | TRF | T | A | HC : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : IP_ID : +---+---+---+---+---+---+---+---+ : | IP_TOS | I | +---+---+---+---+---+---+---+---+ | TEB | IEB | TCP_RESERVED | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ IR Packet: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 | : +---+---+---+---+---+---+---+---+ : HC | : +---+---+---+---+---+---+---+---+ : MASTER_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : | TCP_OPTIONS_PRESENCE : +---+---+---+---+---+---+---+---+ Price et al. [Page 29] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_OPTIONS_ORDER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : | : +---+---+---+---+---+---+---+---+ : TCP_URG_POINTER : +---+---+---+---+---+---+---+---+ : | U | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW : +---+---+---+---+---+---+---+---+ : | TRF | T | A | +---+---+---+---+---+---+---+---+ | TEB | IEB | TCP_RESERVED | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : IP_DEST_ADDRESS : +---+---+---+---+---+---+---+---+ Price et al. [Page 30] INTERNET-DRAFT TCP/IP Compressed Packet Formats May 28, 2003 +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : IP_SOURCE_ADDRESS : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ | I | : +---+---+---+---+---+---+---+---+ : IP_ID : +---+---+---+---+---+---+---+---+ : | IP_TOS | P | +---+---+---+---+---+---+---+---+ Price et al. [Page 31]