Network Working Group|
Request for Comments: 3096
M. Degermark, Editor|
University of Arizona
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 (2001). All Rights Reserved.
This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP.
The goal of the ROHC WG is to develop header compression schemes that perform well over links with high error rates and long link round trip times. The schemes must perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes should also be applicable to other future link technologies with high loss and long round trip times.
The following requirements have, more or less arbitrarily, been divided into three groups. The first group deals with requirements concerning the impact of an header compression scheme on the rest of the Internet infrastructure. The second group concerns what kind of headers that must be compressed efficiently. The final group concerns efficiency requirements and requirements which stem from the properties of the anticipated link technologies.
Several current standardization efforts in the cellular arena aim at supporting voice over IP and other real-time services over IP, e.g., GERAN (specified by the ETSI SMG2 standards group), and UTRAN
(specified by the 3GPP standards organization). It is critical for these standardization efforts that a suitable header compression scheme is developed before completion of the Release 2000 standards. Therefore, it is imperative that the ROHC WG keeps its schedule.
Justification: The header compression process must not produce headers that might cause problems for any current or future part of the Internet infrastructure.
Justification: Ease of deployment.
Note: The ROHC WG may recommend changes that would increase the
compression efficiency for the RTP streams emitted by
implementations. However, ROHC cannot rely on such recommendations being followed.
Justification: IPv4 and IPv6 will both be around during the foreseeable future.
Justification: It is very likely that Mobile IP will be used by cellular devices.
Justification: There must be a generic scheme which can compress reasonably well for any payload type and traffic pattern. This does not preclude optimizations for certain media types where the traffic pattern is known, e.g., for low-bandwidth voice and low-bandwidth video.
Note: This applies to the RTP stream before as well as after it has passed through an internet.
Note: It is of course not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header.
Justification: Spectrum efficiency is a primary goal. RFC 2508 does not perform well enough.
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: Error propagation reduces spectral efficiency and reduces quality. CRTP suffers severely from error propagation.
Note: There are at least two kinds of error propagation; loss propagation, where an error causes subsequent headers to be lost, and damage propagation, where an error causes subsequent headers to be damaged.
3a. Handover loss events: There must be a way to run ROHC where loss events of length 150 milliseconds are handled efficiently and where loss or damage propagation is not introduced by ROHC during such events.
Justification: Such loss events can be introduced by handover operations in a (radio) network between compressor and decompressor. Handover operations can be frequent in cellular systems. Failure to handle handover well can adversely impact spectrum efficiency and quality.
3b. Handover context recreation: There must be a way to run ROHC that deals well with events where the route of an RTP conversation changes such that either the compressor or the decompressor of the conversation is relocated to another node, where the context needs to be recreated. ROHC must not introduce erroneous headers during such events, and should not introduce packet loss during such events.
Justification: Such events can be frequent in cellular systems where the compressor/decompressor on the network side is close to the radio base stations.
Note: In order to aid developers of context recreation schemes where context is transfered to the new node, the specification shall outline what parts of the context is to be transfered, as well as conditions for its use. Procedures for context recreation (and discard) without such context transfer will also be provided.
Justification: Such paths will occur.
Note: loss on previous links will cause irregularities in the RTP stream reaching the compressor. Such irregularities should only marginally affect performance.
7a. Packet Misordering: The scheme should be able to compress when there are misordered packets in the RTP stream reaching the compressor. No misordering is expected on the link between compressor and decompressor.
Justification: Misordering happens regularly in the Internet. However, since the Internet is engineered to run TCP reasonably well, excessive misordering will not be common and need not be handled with optimum efficiently.
7b. Moderate Packet Misordering: The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor.
Note: This kind of reordering is common.
Justification: Some radio technologies support only a limited number of frame sizes efficiently.
Note: Somewhat degraded performance is to be expected when such restrictions are applied.
Note: This implies that a list of "good" frame sizes must be made available and that ROHC may pick a suitable header format to utilize available space as well as possible.
Justification: RTP packets carrying data for interactive voice or video have a limited end-to-end delay budget.
Note: This requirement is intended to prevent schemes that achieve
robustness at the expense of delay, for example schemes that require
that header i+x, x>0, is received before header i can be
Note: Together with 2.3.5, this requirement implies that ROHC will not noticeably add to the jitter of the RTP stream, other than what is caused by variations in header size.
Note: This requirement does not prevent a queue from forming upstream a bottleneck link. Nor does it prevent a compressor from utilizing information from more than one header in such a queue.
Justification: Some target links have a residual error rate, i.e, rate of undetected errors, of this magnitude.
Note: In the presence of residual bit-errors, ROHC will need error detection mechanisms to prevent damage propagation. These mechanisms will catch some residual errors, but those not caught might cause damage propagation. This requirement states that the reduction of the damage rate due to the error detection mechanisms must not be less than the increase in error rate due to damage propagation.
A protocol which meets these requirements, e.g., [ROHC], will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.
A protocol specified to meet these requirements, e.g., [ROHC], 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.
Dept. of Computer Science
University of Arizona
Phone: (May-July): +46 70 833-8933
Phone: +1 520 621-3489
Fax: +1 520 621-4246 EMail: firstname.lastname@example.org
[TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership Project; Technical Specification Group Services and Systems Aspects; Architecture for an All IP network. [TS] TS 22.101 version 3.6.0: Service Principles
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [OHC] Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC 3095, June 2001.
Copyright © The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Funding for the RFC Editor function is currently provided by the Internet Society.