GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3096

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.

Copyright Notice

 Copyright (C) The Internet Society (2001).  All Rights Reserved.

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

Degermark Informational [Page 1] RFC 3096 Requirements for IP/UDP/RTP ROHC July 2001

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

Degermark Informational [Page 2] RFC 3096 Requirements for IP/UDP/RTP ROHC July 2001

 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 RFC 2508 under equivalent operating
 conditions.  The error rate should only marginally increase the
 overhead under expected operating conditions.
 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.
 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.

Degermark Informational [Page 3] RFC 3096 Requirements for IP/UDP/RTP ROHC July 2001

 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.

Degermark Informational [Page 4] RFC 3096 Requirements for IP/UDP/RTP ROHC July 2001

 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.

Degermark Informational [Page 5] RFC 3096 Requirements for IP/UDP/RTP ROHC July 2001

 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

Degermark Informational [Page 6] RFC 3096 Requirements for IP/UDP/RTP ROHC July 2001

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

Degermark Informational [Page 7] RFC 3096 Requirements for IP/UDP/RTP ROHC July 2001

7. Full Copyright Statement

 Copyright (C) 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Degermark Informational [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3096.txt · Last modified: 2001/07/13 17:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki