One document matched: draft-ietf-rohc-rtp-requirements-01.txt

Differences from draft-ietf-rohc-rtp-requirements-00.txt

         Requirements for IP/UDP/RTP robust header compression
               <draft-ietf-rohc-rtp-requirements-01.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a submission of the IETF ROHC WG. Comments should be
   directed to its mailing list, rohc@cdt.luth.se.


Abstract


   This document gives draft requirements for robust IP/UDP/RTP header
   compression to be developed by the ROHC WG. It is based on the
   charter, the 3GPP document "3GPP TR 23.922", version 1.0.0 of october
   1999 [TR], as well as contributions from 3G.IP.









Degermark (Ed)                                                  [Page 1]




INTERNET-DRAFT     Requirements for IP/UDP/RTP ROHC         May 20, 2000


0.  History and Change Log

   May 20, 2000 - draft-ietf-rohc-rtp-requirements-01.txt

      added "robust" to the title of the document.

      2.1.2 Mobile-IP: Added requirement for compression of Home Address
      option.

      2.3.3 Cellular handover: Added note to requirement stating that
      handover procedure will not be prescribed as the procedure will be
      highly system-dependent. However, it must be possible to run ROHC
      such that handover is an efficient operation.

      2.3.7 Packet misordering: Added note to explain why only moderate
      misordering needs to be handled efficiently.

      2.3.10 Delay. New requirement.


   March 29, 2000 - draft-ietf-rohc-rtp-requirements-00.txt

      Initial version of this document. Distributed over the ROHC WG
      mailing list prior to 47th IETF in Adelaide.



























Degermark (Ed)                                                  [Page 2]




INTERNET-DRAFT     Requirements for IP/UDP/RTP ROHC         May 20, 2000


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 roundtrip
   times. The schemes must perform well for cellular links build 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 roundtrip 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.







Degermark (Ed)                                                  [Page 3]




INTERNET-DRAFT     Requirements for IP/UDP/RTP ROHC         May 20, 2000


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


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 error 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. Notes: 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 of packets subsequent to packets damaged by the link,
   even if those subsequent packets are not damaged.

   Justification: Error propagation reduces spectral efficiency and
   reduces voice quality. CRTP suffers severely from error propagation.




Degermark (Ed)                                                  [Page 4]




INTERNET-DRAFT     Requirements for IP/UDP/RTP ROHC         May 20, 2000


   3. Cellular handover: Cellular handover must be supported. The header
   compression scheme should not cause packet loss after handover.

   Justification: Handover can be a frequent operation in cellular
   systems. Failure to handle it well can adversely impact spectrum
   efficiency and voice quality.

   Note: "Supported" does not imply that a handover procedure will be
   prescribed by the ROHC specification. Handover is a highly system-
   dependent operation as is handover frequency and characteristics of
   loss events related to handover. "Supported" does imply that there
   must be a way to run ROHC that deals well with handover in target
   systems. The specification shall outline possible handover schemes
   and pitfalls. The specification will outline what parts of the
   context is to be transfered, as well as conditions for using
   transfered context, to aid developers of handover implementations
   that transfer context between compressors or decompressors.

   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.

   7. Packet Misordering: The scheme must tolerate moderate misordering
   in the packet stream reaching the compressor. No misordering is
   expected on the link between compressor and decompressor.

   Justification: Misordering happens regularly in the Internet.

   Note: Since the Internet is engineered to run TCP reasonably well,
   excessive misordering will not be common, and need not be handled
   efficiently. Moderate misordering (up to 2-3 packets) should be
   handled efficiently.

   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 header size fluctuation: It should be possible to
   restrict the number of different header sizes used by the scheme.




Degermark (Ed)                                                  [Page 5]




INTERNET-DRAFT     Requirements for IP/UDP/RTP ROHC         May 20, 2000


   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.

   10. Delay: The scheme should not delay packets.

   Justification: RTP packets carrying data for interactive voice or
   video have a limited end-to-end delay budget. ROHC should not
   noticeably add to the end-to-end delay.

   Note: This requirement is intended to prevent schemes that achieve
   robustness at the expense of delay, for example schemes that require
   that packet i+x, x>0, is received before packet 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.

3.  Editor's address

     Mikael Degermark                    Tel (May-July): +46 70 833-8933
     Dept. of Computer Science                      Tel: +1 520 621-3489
     University of Arizona                          Fax: +1 520 621-4246
     P.O. Box 210077
     Tucson, AZ 85721-0077
     USA                                     EMail: micke@cs.arizona.edu

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

   [RFC-768]   J. Postel, User Datagram Protocol, RFC 761, August 1980.

   [RFC-791]   J. Postel, Internet Protocol, RFC 791, September 1981.

   [RFC-1144]  V. Jacobson, Compressing TCP/IP Headers for Low-Speed
               Serial Links, RFC 1144, February 1990.

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



Degermark (Ed)                                                  [Page 6]




INTERNET-DRAFT     Requirements for IP/UDP/RTP ROHC         May 20, 2000


               for Low-Speed Serial Links, RFC 2508.


This draft expires November 20, 2000.















































Degermark (Ed)                                                  [Page 7]