Network Working Group L-E. Jonsson
Request for Comments: 4163 Ericsson
Category: Informational August 2005
RObust Header Compression (ROHC):
Requirements on TCP/IP Header Compression
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document contains requirements on the TCP/IP header compression
scheme (profile) to be developed by the RObust Header Compression
(ROHC) Working Group. The document discusses the scope of TCP
compression, performance considerations, assumptions about the
surrounding environment, as well as Intellectual Property Rights
concerns. The structure of this document is inherited from RFC 3096,
which defines IP/UDP/RTP requirements for ROHC.
Table of Contents
1. Introduction ....................................................2
2. Header Compression Requirements .................................2
2.1. Impact on Internet Infrastructure ..........................2
2.2. Supported Headers and Kinds of TCP Streams .................3
2.3. Performance Issues .........................................4
2.4. Requirements Related to Link Layer Characteristics .........6
2.5. Intellectual Property Rights (IPR) .........................7
3. Security Consideration ..........................................7
4. IANA Considerations .............................................7
5. Acknowledgements ................................................7
6. Informative References ..........................................7
Jonsson Informational [Page 1]RFC 4163 Requirements on ROHC TCP/IP August 20051. Introduction
The goal of the ROHC WG is to develop header compression schemes that
perform well over links with high error rates and long link roundtrip
times. The schemes must perform well for cellular links that use
technologies such as Wideband Code Division Multiple Access (W-CDMA),
Enhanced Data rates for GSM Evolution (EDGE), and CDMA2000. However,
the schemes should also be applicable to other link technologies with
high loss and long roundtrip times.
The main objective for ROHC has been robust compression of IP/UDP/RTP
[5], but the WG is also chartered to develop new header compression
solutions for IP/TCP [1], [2]. Because TCP traffic, in contrast to
RTP, has usually been sent over reliable links, existing schemes for
TCP, [3] and [4], have not experienced the same robustness problems
as RTP compression. However, there are still many scenarios where
TCP header compression will be implemented over less reliable links
[11], [12], making robustness an important objective for the new TCP
compression scheme. Other, equally important, objectives for ROHC
TCP compression are: improved compression efficiency, enhanced
capabilities for compression of header fields including TCP options,
and finally incorporation of TCP compression into the ROHC framework
[6].
2. Header Compression Requirements
The following requirements have, more or less arbitrarily, been
divided into five groups. The first group deals with requirements
concerning the impact of a header compression scheme on the rest of
the Internet infrastructure. The second group defines what kind of
headers must be compressed efficiently. The third and fourth groups
concern performance requirements and capability requirements that
stem from the properties of link technologies where ROHC TCP is
expected to be used. Finally, the fifth section discusses
Intellectual Property Rights related to ROHC TCP compression.
2.1. Impact on Internet Infrastructure
1. Transparency: When a header is compressed and then decompressed,
the resulting header must be semantically identical to the
original header. If this cannot be achieved, the packet
containing the erroneous header must be discarded.
Justification: The header compression process must not produce
headers that might cause problems for any current or future part
of the Internet infrastructure.
Jonsson Informational [Page 2]RFC 4163 Requirements on ROHC TCP/IP August 2005
Note: The ROHC WG has not found a case where "semantically