draft-ietf-rohc-rtp-requirements-03.txt   draft-ietf-rohc-rtp-requirements-04.txt 
Network Working Group Mikael Degermark (editor) /University of Arizona Network Working Group Mikael Degermark (editor) /University of Arizona
INTERNET-DRAFT USA INTERNET-DRAFT USA
Expires: May 17, 2001 Nov 17, 2000 Expires: Jun 21, 2001 Dec 21, 2000
Requirements for robust IP/UDP/RTP header compression Requirements for robust IP/UDP/RTP header compression
<draft-ietf-rohc-rtp-requirements-03.txt> <draft-ietf-rohc-rtp-requirements-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@cdt.luth.se. directed to its mailing list, rohc@cdt.luth.se.
Abstract Abstract
This document contains requirements for robust IP/UDP/RTP header This document contains requirements for robust IP/UDP/RTP header
compression to be developed by the ROHC WG. It is based on the ROHC compression to be developed by the ROHC WG. It is based on the ROHC
charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", charter, discussions in the WG, the 3GPP document "3GPP TR 23.922",
version 1.0.0 of october 1999 [TR], as well as contributions from version 1.0.0 of October 1999 [TR], as well as contributions from
3G.IP. 3G.IP.
0. History and Change Log 0. History and Change Log
Nov 1, 2000 - draft-ietf-rohc-rtp-requirements-03.txt Nov 1, 2000 - draft-ietf-rohc-rtp-requirements-03.txt
Changed "packet" to "header" on several places. Changed "packet" to "header" on several places.
June 7, 2000 - draft-ietf-rohc-rtp-requirements-02.txt June 7, 2000 - draft-ietf-rohc-rtp-requirements-02.txt
skipping to change at page 4, line 8 skipping to change at page 4, line 8
2.3.10 Delay. New requirement. 2.3.10 Delay. New requirement.
March 29, 2000 - draft-ietf-rohc-rtp-requirements-00.txt March 29, 2000 - draft-ietf-rohc-rtp-requirements-00.txt
Initial version of this document. Distributed over the ROHC WG Initial version of this document. Distributed over the ROHC WG
mailing list prior to 47th IETF in Adelaide. mailing list prior to 47th IETF in Adelaide.
1. Introduction 1. Introduction
The goal of the ROHC WG is to develop header compression schemes that 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 perform well over links with high error rates and long link round
times. The schemes must perform well for cellular links build using trip times. The schemes must perform well for cellular links build
technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes using technologies such as WCDMA, EDGE, and CDMA-2000. However, the
should also be applicable to other future link technologies with high schemes should also be applicable to other future link technologies
loss and long roundtrip times. with high loss and long round trip times.
The following requirements have, more or less arbitrarily, been The following requirements have, more or less arbitrarily, been
divided into three groups. The first group deals with requirements divided into three groups. The first group deals with requirements
concerning the impact of an header compression scheme on the rest of concerning the impact of an header compression scheme on the rest of
the Internet infrastructure. The second group concerns what kind of the Internet infrastructure. The second group concerns what kind of
headers that must be compressed efficiently. The final group concerns headers that must be compressed efficiently. The final group concerns
efficiency requirements and requirements which stem from the efficiency requirements and requirements which stem from the
properties of the anticipated link technologies. properties of the anticipated link technologies.
2. Header compression requirements 2. Header compression requirements
skipping to change at page 6, line 6 skipping to change at page 6, line 6
2.3 Efficiency 2.3 Efficiency
1. Performance/Spectral Efficiency: Must provide low relative 1. Performance/Spectral Efficiency: Must provide low relative
overhead under expected operating conditions; compression efficiency overhead under expected operating conditions; compression efficiency
should be better than for RFC2508 under equivalent operating should be better than for RFC2508 under equivalent operating
conditions. The error rate should only marginally increase the conditions. The error rate should only marginally increase the
overhead under expected operating conditions. overhead under expected operating conditions.
Justification: Spectrum efficiency is a primary goal. RFC2508 does Justification: Spectrum efficiency is a primary goal. RFC2508 does
not perform well enough. Notes: the relative overhead is the average not perform well enough.
header overhead relative to the payload. Any auxiliary (e.g., control
or feedback) channels used by the scheme should be taken into account Note: The relative overhead is the average header overhead relative
when calculating the header overhead. 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 2. Error propagation: Error propagation due to header compression
should be kept at an absolute minimum. Error propagation is defined should be kept at an absolute minimum. Error propagation is defined
as the loss or damage of headers subsequent to headers lost or 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 by the link, even if those subsequent headers are not lost or
damaged. damaged.
Justification: Error propagation reduces spectral efficiency and Justification: Error propagation reduces spectral efficiency and
reduces quality. CRTP suffers severely from error propagation. reduces quality. CRTP suffers severely from error propagation.
Note: There are at least two kinds of error propagation; loss Note: There are at least two kinds of error propagation; loss
propagation, where a lost header causes subsequent headers to be lost propagation, where an error causes subsequent headers to be lost, and
or damaged, and damage propagation, where a damaged header causes damage propagation, where an error causes subsequent headers to be
subsequent headers to be lost or damaged. damaged.
3a. Handover loss events: Loss events of lenght 150 ms should be 3a. Handover loss events: There must be a way to run ROHC where loss
handled efficiently and without additional packet loss being events of length 150 milliseconds are handled efficiently and where
introduced by ROHC. loss or damage propagation is not introduced by ROHC during such
events.
Justification: Such loss events can be introduced by handover Justification: Such loss events can be introduced by handover
operations in the (radio) network between compressor and operations in a (radio) network between compressor and decompressor.
decompressor. Handover operations can be frequent in cellular Handover operations can be frequent in cellular systems. Failure to
systems. Failure to handle handover well can adversely impact handle handover well can adversely impact spectrum efficiency and
spectrum efficiency and quality. quality.
3b. Handover context recreation: There must be a way to run ROHC 3b. Handover context recreation: There must be a way to run ROHC
that deals well with events where the route of an RTP conversation that deals well with events where the route of an RTP conversation
changes such that either the compressor or the decompressor of the changes such that either the compressor or the decompressor of the
conversation is relocated to another node, where the context needs to conversation is relocated to another node, where the context needs to
be recreated. ROHC must not create erroneous headers during such be recreated. ROHC must not introduce erroneous headers during such
events. events, and should not introduce packet loss during such events.
Justification: Such events can be frequent in cellular systems where Justification: Such events can be frequent in cellular systems where
the compressor/decompressor on the network side is close to the radio the compressor/decompressor on the network side is close to the radio
base stations. base stations.
Note: In order to aid developers of context recreation schemes where Note: In order to aid developers of context recreation schemes where
context is transfered to the new node, the specification shall context is transfered to the new node, the specification shall
outline what parts of the context is to be transfered, as well as outline what parts of the context is to be transfered, as well as
conditions for its use. Procedures for context recreation (and conditions for its use. Procedures for context recreation (and
discard) without such context transfer will also be provided. discard) without such context transfer will also be provided.
skipping to change at page 9, line 11 skipping to change at page 9, line 14
[RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980. [RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980.
[RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981. [RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981.
[RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed [RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed
Serial Links, RFC 1144, February 1990. Serial Links, RFC 1144, February 1990.
[CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers [CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links, RFC 2508. for Low-Speed Serial Links, RFC 2508.
This draft expires May 17, 2001. This draft expires June 21, 2001.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/