|
Network Working Group Request for Comments: 4163 Category: Informational |
L-E. Jonsson Ericsson August 2005 RObust Header Compression (ROHC): |
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 © The Internet Society (2005).
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.
1. Introduction
2. Header Compression Requirements
2.1. Impact on Internet Infrastructure
2.2. Supported Headers and Kinds of TCP Streams
2.3. Performance Issues
2.4. Requirements Related to Link Layer Characteristics
2.5. Intellectual Property Rights (IPR)
3. Security Consideration
4. IANA Considerations
5. Acknowledgements
6. Informative References
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].
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.
Justification: The header compression process must not produce headers that might cause problems for any current or future part of the Internet infrastructure.
Note: The ROHC WG has not found a case where "semantically identical" is not the same as "bitwise identical".
Justification: Ease of deployment.
Note: The ROHC WG may recommend changes that would increase the
compression efficiency for the TCP streams emitted by
implementations. However, ROHC cannot assume such
recommendations will be followed.
Note: Several TCP variants are currently in use on the Internet. This requirement implies that the header compression scheme must work efficiently and correctly for all expected TCP variants.
Justification: IPv4 and IPv6 will both be around for the foreseeable future, and Options/Extensions are expected to be more commonly used. ECN is expected to have a breakthrough and be widely deployed, especially in combination with TCP.
Justification: It is very likely that Mobile IP will be used by cellular devices.
Justification: There must be a generic scheme that can compress reasonably well for any TCP traffic pattern. This does not preclude optimizations for certain traffic patterns.
Justification: IPSEC is expected to be used to provide necessary end-to-end security.
Note: It is not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header.
Justification: These bits are expected to be commonly used.
Justification: Because various TCP options are commonly used, applicability of the compression scheme would be significantly reduced if packets with options could not be compressed.
Note: Options that should be compressed are:
- Selective Acknowledgement (SACK), [8], [9]
- Timestamp, [7]
Justification: Spectrum efficiency is a primary goal.
Note: The relative overhead is the average header overhead relative to the payload. Any auxiliary (e.g., control or feedback) channels used by the scheme should be taken into account when calculating the header overhead.
Justification: Even though link layer retransmission in most cases is expected to almost eliminate losses between compressor and decompressor, there are still many scenarios where TCP header compression will be implemented over less reliable links [11], [12]. In such cases, loss propagation due to header compression could affect certain TCP mechanisms that are capable of handling some losses; loss propagation could also have a negative impact on the performance of TCP loss recovery.
Justification: For links carrying TCP traffic, the residual error rate is expected to be insignificant. However, residual errors may still occur, especially in the end-to-end path. Therefore, it is crucial that TCP is not prevented from handling these.
Note: This requirement implies that the TCP checksum must be carried unmodified in all compressed headers.
Note: The error detection mechanism in TCP may be able to detect residual bit errors, but the mechanism is not designed for this purpose, and might actually provide rather weak protection. Therefore, although it is not a requirement of the compression scheme, it should be possible for the decompressor to detect residual errors and discard such packets.
Justification: Many TCP transfers are short-lived. This may lead to a low gain for header compression schemes that, for each new packet stream, requires full headers to be sent initially and allows small compressed headers only after the initialization phase.
Note: This requirement implies that mechanisms for building new contexts that are based on information from previous contexts or for concurrent packet streams to share context information should be considered.
5a. Moderate Packet Misordering: The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor.
Justification: This kind of misordering is common.
5b. Packet Misordering: The scheme must be able to correctly handle packet misordering and preferably compress when misordered packets are in the TCP stream reaching the compressor.
Justification: Misordering happens regularly in the Internet. However, because the Internet is engineered to run TCP reasonably well, excessive misordering will not be common and need not be handled with optimum efficiency.
Justification: There are links that do not provide a feedback channel or where feedback is not desirable for other reasons.
When compression is applied over tunnels, misordering often cannot be completely avoided. The header compression scheme should not prohibit misordering between compressor and decompressor, as it would therefore not be applicable in many tunneling scenarios. However, in the case of tunneling, it is usually possible to get misordering indications. Therefore, the compression scheme does not have to support detection of misordering, but can assume that such information is available from lower layers when misordering occurs.
The ROHC WG must spend effort to achieve a high degree of confidence that there are no known IPR claims that cover the final compression solution for TCP.
Justification: Currently there is no TCP header compression scheme available that can efficiently compress the packet headers of modern TCP, e.g., with SACK, ECN, etc. ROHC is expected to fill this gap by providing a ROHC TCP scheme that is applicable in the wide area Internet, not only over error-prone radio links. It must thus attempt to be as future-proof as possible, and only unencumbered solutions, or solutions where the terms of any IPR are such that there is no hindrance on implementation and deployment, will be acceptable to the Internet at large.
A protocol specified to meet these requirements must be able to compress packets containing IPSEC headers according to the IPSEC requirement, 2.2.4. There may be other security aspects to consider in such protocols. This document by itself, however, does not add any security risks.
A protocol that meets these requirements will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.
This document has evolved through fruitful discussions with and input from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West, Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The document quality was significantly improved thanks to Peter Eriksson, who made a thorough linguistic review.
Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served as committed working group document reviewers.
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[3] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[4] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[5] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[6] 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.
[7] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[8] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[9] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[11] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to- end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[12] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
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
Copyright © The Internet Society (2005).
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.
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.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Funding for the RFC Editor function is currently provided by the Internet Society.