RFC3096 - Requirements for robust IP/UDP/RTP header compression

Network Working Group M. Degermark, Editor

Request for Comments: 3096 University of Arizona

Category: Informational July 2001

Requirements for robust IP/UDP/RTP 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.

Abstract

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.

1. 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 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.

2. Header compression requirements

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.

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.

2. Ubiquity: Must not require modifications to existing IP (v4 or

v6), UDP, or RTP implementations.

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.

2.2 Supported headers and kinds of RTP streams

1. IPv4 and IPv6: Must support both IPv4 and IPv6.

Justification: IPv4 and IPv6 will both be around during the

foreseeable future.

2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be

compressed efficiently. For IPv4 these include headers of tunneled

packets. For IPv6 these include headers containing the Routing

Header, the Binding Update Destination Option, and the Home Address

option.

Justification: It is very likely that Mobile IP will be used by

cellular devices.

3. Genericity: Must support compression of headers of arbitrary RTP

streams.

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.

4. IPSEC: ROHC should be able to compress headers containing IPSEC

subheaders.

Note: It is of course not possible to compress the encrypted part of

an ESP header, nor the cryptographic data in an AH header.

2.3 Efficiency

1. Performance/Spectral Efficiency: Must provide low relative

overhead under eXPected operating conditions; compression efficiency

should be better than for RFC2508 under equivalent operating

conditions. The error rate should only marginally increase the

overhead under expected operating conditions.

Justification: Spectrum efficiency is a primary goal. RFC2508 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.

2. Error propagation: Error propagation due to header compression

should be kept at an absolute minimum. Error propagation is defined

as the loss or damage of headers subsequent to headers lost or

damaged by the link, even if those subsequent headers are not lost or

damaged.

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.

4. Link delay: Must operate under all expected link delay conditions.

5. Processing delay: The scheme must not contribute significantly to

system delay budget.

6. Multiple links: The scheme must perform well when there are two or

more cellular links in the end-to-end path.

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.

8. Unidirectional links/multicast: Must operate (possibly with less

efficiency) over links where there is no feedback channel or where

there are several receivers.

9. Configurable frame size fluctuation: It should be possible to

restrict the number of different frame sizes used by the scheme.

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.

10. Delay: ROHC should not noticeably add to the end-to-end delay.

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

decompressed.

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.

11. Residual errors: For a residual bit-error rate of at most 1e-5,

the ROHC scheme must not increase the error rate.

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.

3. IANA Considerations

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.

4. Security Considerations

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.

5. Editor's Address

Mikael Degermark

Dept. of Computer Science

University of Arizona

P.O. Box 210077

Tucson, AZ 85721-0077

USA

Phone: (May-July): +46 70 833-8933

Phone: +1 520 621-3489

Fax: +1 520 621-4246

EMail: micke@cs.arizona.edu

6. References

[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, RFC768,

August 1980.

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC791, September

1981.

[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed

Serial Links", RFC1144, February 1990.

[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers

for Low-Speed Serial Links", RFC2508, February 1999.

[OHC] Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC

3095, June 2001.

7. Full Copyright Statement

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.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.