rfc3096.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页

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]