ROHC WG Yousuf Saifullah INTERNET-DRAFT Khiem Le Date: October 2002 Zhigang Liu Expires: April 2002 Nokia Research Center ROHC-TCP Early Compression 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 to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies Early Compression Enabler for ROHC-TCP to increase compression gain. The enabler provides a generic platform to implement an early compression mechanism. An early compression mechanism is an out-of-band mechanism that populates the ROHC-TCP decompression context with some of the header fields before the ROHC- TCP initialization step. ROHC-TCP does not need to carry those fields, thus early compression provides compression from the very first TCP packet and increases the compression gain. It is especially useful for short-lived TCP connections. The document describes the working of Early Compression Enabler as part of ROHC-TCP. It also specifies protocol changes for the ROHC-TCP protocol. It does not Saifullah, Le, Liu [Page i] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 specify any particular early compression mechanism. Saifullah, Le, Liu [Page ii] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 1. Introduction The purpose of ROHC schemes is to provide bandwidth efficient header compression for the IP based protocols, which are also resilient to link errors. The fundamentals, framework and protocols for ROHC are described in [1]. ROHC is being extended to provide header compression for TCP/IP [2]. This work is also called ROHC-TCP. This draft proposes a scheme, called Early Compression Enabler, that can enable compression from the very first TCP packet for ROHC-TCP. The ROHC compression schemes require transfer of full header from the compressor to the decompressor to build the context at the decompressor. They transfer full header in the ROHC Initialization and Refresh (IR) packets. The compressor does not start compression until it is confident that the decompressor has built the context. The transfer of full header may continue for more than one packet. A short-lived TCP transaction could conclude before the compressor is assured about the context in the decompressor. Therefore, a scheme is desired that can start compression with the first TCP packet. Early compression provides compression from first TCP packet by reducing the number of TCP/IP header fields exchanged in the IR packets. The idea behind Early Compression is that some of the header fields, called early fields, may already be present on the decompressor side before starting the TCP connection. The early fields could be present at the decompressor side as part of channel setup or configuration procedure. As the decompressor side already has such fields so there is no need for the compressor to send them as part of the IR packets. In addition to the compression gain for the short-lived TCP transaction, early compression provides other advantages. It reduces the amount of signaling transferred as part of ROHC protocol, thus providing an additional improvement in bandwidth efficiency even for the long-lived TCP connections. Some bandwidth limited link layers perform further segmentation of a TCP data packet to transfer them using the allowed link frame size. Early Compression reduces the size of the IR packets, which results into smaller number of frames. This decreases the link transmission time and link errors for a data packet, hence helps in faster transition of ROHC-TCP to the more efficient compression and decompression states. The Early Compression Enabler enhancements are introduced as a new ROHC profile, conforming to the framework defined in [1]. They are applicable to all modes of operation in ROHC. It reduces the context storage at the compressor and decompressor, since a smaller storage is required to maintain a reduced number of header fields. It complements all the existing optimizations considered for ROHC-TCP. Saifullah, Le, Liu [Page 1] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 The enabler can be used for providing context replication [2]. The scope of this document is to specify the enhancements for ROHC- TCP protocol to enable Early Compression. The specified enhancements will be used by an early compression mechanism. There could be multiple mechanisms and they are not described in this document. However, for information and to show applicability of the enabler an example early compression mechanism is described in [3]. 2. Terminology This draft uses terminologies from [1] and [2]. The following contains only new terminologies introduced by this draft. Early Compression Mechanism An out-of-band mechanism that populates certain header fields to the decompressor side for Early Compression. An out-of-band mechanism can be any mechanism other than the current TCP connection. It could be an old TCP connection. This mechanism is not part of the ROHC-TCP protocol. Early Compression Enabler The enhancements in the ROHC-TCP protocol to enable an early compression mechanism are called Early Compression Enabler. Early Compression Early Compression provides header compression starting with the IR packets. It uses an Early Compression Mechanism to populate some of the header fields to the decompressor side, before TCP connection. It enables the mechanism in ROHC-TCP using Early Compression Enabler. Early Fields The header fields that are transferred using an early compression mechanism are called the Early Fields. They are not sent in the IR packets during the ROHC-TCP initialization. Early Compression/Decompression Entity Early Compression recovers the early fields from an entity on the compressor side called Early Compression Entity and from an entity on the decompressor side called Early Decompression Entity. Saifullah, Le, Liu [Page 2] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 3. Early Compression Enabler Description The working of Early Compression Enabler is illustrated in figure 1. The figure has a ROHC-TCP compressor and a decompressor as defined in [1]. It also has two functional entities used by an early compression mechanism. The entity on the ROHC-TCP compressor side is called Early Compression Entity and the entity on the ROHC-TCP decompressor side is called Early Decompression Entity. The figure assumes that a, b, c, and d are the TCP/IP header fields, with a and b as early fields. The functionalities of the entities are dependent on the early compression mechanism and is outside of the scope of this document. Early Decompression Early Compression Entity Entity +-----------+ +-----------+ | | | | | | | | | | | | | | | | | (a,b) | | (a,b) | +-----------+ +-----------+ | | | | |Transfer early fields Identify early fields| | | | | | ROHC-TCP ROHC-TCP | | Deompressor Compressor | | +------------+ +------------+ | -->| | IR carries (c,d) | |<-- | |<--------------------| | | (a,b,c,d) | | (c,d) | +------------+ +------------+ Figure 1: Early Compression Enabler The early compression entity exchanges the early fields with the early decompression entity. The early fields could be STATIC or CHANGING, as defined in [1]. A CHANGING early field SHOULD change occasionally, e.g. Traffic Class in IPv6. A TCP option or an IP extension header can also be an early field. A procedure for handling change in an early field is also discussed in section 3.5. The early fields could vary depending on the underlying early compression mechanism. This document proposes a generic mechanism for any number of early fields. Saifullah, Le, Liu [Page 3] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 The ROHC-TCP Compressor MUST be informed about the early fields. This could be done by using an early compression mechanism before the ROHC-TCP initialization step. Once the ROHC-TCP compressor knows the early fields, it MAY enable the early compression. The compressor MAY store a reduced compression context from the header fields by excluding the early fields. If the compressor enables the early compression, it MUST send early compression indication to the ROHC- TCP decompressor by using a new profile type in the IR packets. It also MUST send the reduced context to the decompressor as part of the profile specific information. When the decompressor receives early compression enabler profile, it MUST build the complete decompression context by using the early fields and the IR packet. The ROHC decompressor uses this context to decompress the data packets. 3.1. Assumptions Early Compression Enabler assumes the following characteristics for the early compression mechanisms and entities: * An early compression entity can provide varying number of early fields to the ROHC-TCP compressor. As the number is varying the entity MUST provide proper identification with every early field. * The ROHC-TCP compressor MUST receive the complete TCP/IP header during the TCP connection. * An early compression mechanism MUST transfer the early fields before ROHC-TCP initialization for a TCP connection. * The early decompression entity MUST transfer the early fields to the ROHC-TCP decompressor with identification of the fields. If an optional field is transferred (e.g. TCP option or an IP extension header), then the early decompression entity MUST also inform the correct position of the optional field to maintain transparency. 3.2. CRC Coverage for IR packet A CRC over the original header is the primary mechanism used by ROHC to detect incorrect decompression. The CRC field in the IR packet is profile specific. For early compression, the ROHC-TCP compressor MUST compute CRC over the original header without the exclusion of early fields. In other words, CRC covers IR packet header fields up to the profile field and the header fields as they appear in the original packet. This provides a mechanism for the ROHC-TCP decompressor to identify any corruption in the IR packet, including the early fields. Saifullah, Le, Liu [Page 4] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 3.3. Retrieving Early Fields The ROHC-TCP decompressor MAY retrieve early fields from the early decompression entity by using a procedure specific to the early decompression mechanism. For example, the retrieval procedure may only require an internal data look up by using a compression channel identifier and context identifier known to both the ROHC-TCP decompressor and the early decompression entity. This case does not require any modification in the ROHC-TCP protocol. It is also possible that the ROHC-TCP decompressor does not have any linkage with the early decompression entity prior to the IR packets. For example, if the early compression/decompression entities maintain early fields in a table format, and need index to locate the proper early fields from each other. In this case, the ROHC-TCP decompressor MAY need an identifier to retrieve the relevant early fields from the early decompression entity. The early field identifier associates an early field, or a set of early fields, between early compressor and decompressor entities. The early compression entity transfers the early field identifier to the ROHC- TCP decompressor via ROHC-TCP compressor. The profile specific information in the IR packet MAY be modified to include this optional identifier. The early field identifier is optional for early compression. It is only needed when there is no linkage between the ROHC-TCP decompressor and the early decompression entity prior to the IR packets. The use of early field identifier to retrieve the corresponding early fields is mechanism specific and is not described in this document. 3.4. Providing Context Replication with Early Compression Enabler Early compression initializes a new context from early fields and the IR packet. Similarly, context replication initializes a new context from a base context and the IR-REPLICATE packet. For the details on context replication, refer to [2]. A base context can be visualized as a set of early fields, where the out-of-band mechanism was a previous TCP connection. Therefore, early compression enabler MAY also be used to provide context replication. The context replication needs an identifier for the base context. The early field identifier, discussed in section 3.3, is used for such an identifier. Using the early compression enabler for the context replication alleviates the need for making any specific changes in ROHC-TCP for the context replication. Saifullah, Le, Liu [Page 5] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 3.5. Handling Changes in Early Fields Once ROHC-TCP compressor is confident that the decompressor has built the complete context, the compressor stops differentiating early fields from the other header fields. Any change in an early field is communicated to the ROHC-TCP decompressor in the same way as in the regular TCP/IP profile, i.e. by using an update packet (e.g. IR-DYN) that can carry the change information. If an early field is changed before the compressor has gained the confidence, the compressor abandons the early compression profile and starts using the regular TCP/IP profile. This scenario is least likely to happen, since the early fields are either STATIC or change occasionally. 3.6. Handling Early Compression Failure The ROHC-TCP decompressor may fail CRC check on the received IR packet with early compression enabler profile. In this case, it may send STATIC-NACK back to the compressor according to [1]. It is possible that an early field is corrupted and is causing CRC failure. ROHC-TCP may like to abandon early compression and start with full header using regular TCP/IP compression profile. But, first it needs to recognize that an early field is behind the failure. For this purpose, the ROHC-TCP compressor MAY also send a CRC calculated only on the IR packet and not including the early fields. If the full header CRC fails, the ROHC-TCP decompressor checks the IR CRC. If it passes then the problem is in an early field. The ROHC-TCP decompressor MAY send a new NACK to the ROHC-TCP compressor. The NACK is profile specific and is called Early Compression NACK. It contains information indicating that the failure is because of the early compression mechanism. 3.7. U-Mode Considerations If the early compression mechanism is unreliable, then early fields may not be transferred correctly. The ROHC-TCP decompressor may be able to identify the problem with the help of CRC. But for U-mode, it can not inform the compressor to start regular TCP/IP compression. There are two options for solving the above problem. One option is that U-mode MAY use only a reliable early compression mechanism to transfer early fields. This would put an extra limitation on the early compression mechanism. Second option is that the U-mode MAY refresh IR packets with full TCP/IP header including early fields. The decompression context MUST overwrite the already present early Saifullah, Le, Liu [Page 6] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 fields with the early fields sent in the IR packet. 4. ROHC Framework Changes There is no impact on ROHC Framework. 5. ROHC-TCP Protocol Changes This section specifies ROHC-TCP protocol changes using [1] as the reference. 5.1. Feedback for Early Compression Failure Feedback carries information from the decompressor to the compressor. Early compression enabler MAY send Early Compression NACK that indicates corruption in the early fields to the compressor (section 3.6). The NACK is sent using the existing ROHC feedback. As the NACK is profile specific, so the NACK indication is part of the profile specific information. More specifically, the NACK MUST use one octet format FEEDBACK-1 in the feedback field with a value 0xFF. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | profile specific info = 0xFF | 1 octet +---+---+---+---+---+---+---+---+ 5.2. IR Packet for Early Compression This section defines profile specific fields in the ROHC-IR packet for early compression enabler. IR has the following structure: Saifullah, Le, Liu [Page 7] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 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 | x | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / profile specific information / variable length | | +---+---+---+---+---+---+---+---+ Bit x: It is a profile specific information. For TCP/IP Early Compression, x= 1 indicates presence of early compression optional fields before static/dynamic chains in the profile specific information. Whereas, x= 0 indicates absence of any early compression optional fields. Profile: It contains profile type for TCP/IP Early Compression Enabler. CRC: It is calculated on all the fields in the IR packet upto the Profile and the original TCP/IP header. Profile Specific Information: If bit x= 0, Profile Specific Information contains only static and dynamic chains of header fields excluding early fields. If bit x= 1, Profile Specific Information contains the following structure: Saifullah, Le, Liu [Page 8] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 +---+---+---+---+---+---+---+---+ |RCF| Option Type | 1 octet +---+---+---+---+---+---+---+---+ | | / Option Specific Information / variable length depending on | | Option Type +---+---+---+---+---+---+---+---+ | | / profile specific information / variable length | | +---+---+---+---+---+---+---+---+ The above structure provides a way for carrying the optional fields for early compression, refer to sections 3.3 and 3.4. RCF: It indicates presence of the reduced header CRC flag as the first octet in the option specific information field. Option Type: It indicates the type of option specific information carried in the header. The following values of Option Type are proposed: Option Type= 0 indicates Context Replication Option Type= 1 indicates Early Field Identifier Option Type= 2-127 are reserved Option Specific Information: It MAY carry CRC and the parameters specific to an option type. For Option Type= 0: It SHOULD contain identifier for the base context. The identifier for base context has not been specified in [2], and this field will be defined after the identifier is known. For Option Type= 1: It MUST contain one octet for the early field identifier. The identifier locates the early fields for a TCP connection. 5.2.1. ROHC-TCP Initial Compressor Processing The following steps is a summary of the initial compressor processing for enabling early compression: Saifullah, Le, Liu [Page 9] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 1) If an early field option need to be sent, set bit x of packet type to 1 and put the relevant option type and option specific information fields; otherwise, set bit x to 0. 2) Send header fields other than the early fields in the IR packet in the profile specific information. 3) If one-octet feedback data (FEEDBACK-1) is received and is equal to 0xFF, discard early compression. May start sending IR packets with regular TCP/IP compression profile and contents. 4) If in U-mode and there is no information about the reliability of the early compression mechanism for transferring the early fields, send refreshes for IR with full header. 5) If notified for a change/removal of a CHANGING early field, add the field in the compression context and send the changed field using the existing ROHC-TCP protocol. 5.2.2. ROHC-TCP Decompressor Processing The following steps is a summary of the decompressor processing for an IR packet after it recognizes "Early Compression Enabler" profile: 1) If bit x is set, extract early compression options parameters and may use those parameters to retrieve early fields. Otherwise, retrieve the early fields without any help from ROHC-TCP protocol. 2) Extract the rest of the header fields from the profile specific information field. 3) Perform the CRC check. If the check fails, discard the IR- packet and may send feedback with feedback data=0xFF. 4) If an IR packet is received with the full header for refresh, overwrite the early fields in the decompression context. 5) If an IR-DYN or any other protocol allowed packet is received with an early field(s), overwrite the early field(s) in the decompression context. 5.3. Operation in U-Mode In U-mode, the ROHC-TCP compressor may save the early fields as part of the compression context and send the full header in IR Saifullah, Le, Liu [Page 10] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 refreshes. This is only required if the underlying early compression mechanism is unreliable in transferring early fields to the decompressor side. If the ROHC-TCP compressor knows that the early compression mechanism is reliable, there is no change in U-mode. 6. Security Considerations The enhancements for Early Compression Enabler defined in this document do not create any new security breaches for ROHC-TCP. 7. IANA Considerations A ROHC profile identifier must be reserved by the IANA for "Early Compression Enabler for TCP/IP" defined in this document. Saifullah, Le, Liu [Page 11] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 8. References [1] C. Bormann (ed.), et al., "Robust Header Compression (ROHC)", RFC 3095, July 2001 [2] Qian Zhang, et al., TCP/IP Header Compression for ROHC (ROHC-TCP), draft-ietf-rohc-tcp-02.txt, (work in progress) July 2002 [3] Yousuf Saifullah, Marc Greis, Khiem Le, Zhigang Liu, Early Compression in GPRS Networks, draft-saifullah- rohc-early-comp-in-GPRS-00.txt, (work in progress) Oct 2002 Saifullah, Le, Liu [Page 12] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 9. Authors' Addresses Yousuf Saifullah Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-6966 E-mail: yousuf.saifullah@nokia.com Khiem Le Nokia Corporation 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972-894-4882 E-Mail: khiem.le@nokia.com Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972-894-5935 E-Mail: zhigang.c.liu@nokia.com Saifullah, Le, Liu [Page 13] INTERNET-DRAFT ROHC-TCP Early Compression October 2002 Table of Contents Status of This Memo . . . . . . . . . . . . . . . . . . . . . i Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . i 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 1 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Early Compression Enabler Description . . . . . . . . . . . 3 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 4 3.2. CRC Coverage for IR Packet . . . . . . . . . . . . . . 4 3.3. Retrieving Early Fields . . . . . . . . . . . . . . . 5 3.4. Context Replication with Early Compression Enabler . . 5 3.5. Handling Changes in Early Fields . . . . . . . . . . . 6 3.6. Handling Early Compression Failure . . . . . . . . . . 6 3.7. U-Mode Considerations . . . . . . . . . . . . . . . . 6 4. ROHC Framework Changes . . . . . . . . . . . . . . . . . . 7 5. ROHC-TCP Protocol Changes . . . . . . . . . . . . . . . . . 7 5.1. Feedback for Early Compression Failure . . . . . . . . 7 5.2. IR Packet for Early Compression . . . . . . . . . . . 7 5.2.1. ROHC-TCP Initial Compressor Processing . . . . . 9 5.2.2. ROHC-TCP Decompressor Processing . . . . . . . . 10 5.3. Operation in Unidirectional Mode . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13 Saifullah, Le, Liu [Page xiv]