draft-ietf-rohc-rtp-requirements-05.txt   rfc3096.txt 
Network Working Group Mikael Degermark (editor) /University of Arizona
INTERNET-DRAFT USA Network Working Group M. Degermark, Editor
Expires: Aug 5, 2001 Feb 5, 2001 Request for Comments: 3096 University of Arizona
Category: Informational July 2001
Requirements for robust IP/UDP/RTP header compression Requirements for robust IP/UDP/RTP header compression
<draft-ietf-rohc-rtp-requirements-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 Copyright Notice
http://www.ietf.org/shadow.html.
This document is a submission of the IETF ROHC WG. Comments should be Copyright (C) The Internet Society (2001). All Rights Reserved.
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 (Internet
compression to be developed by the ROHC WG. It is based on the ROHC Protocol/User Datagram Protocol/Real-Time Transport Protocol) header
charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", compression to be developed by the ROHC (Robust Header Compression)
version 1.0.0 of October 1999 [TR], as well as contributions from WG. It is based on the ROHC charter, discussions in the WG, the 3GPP
3G.IP. document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as
contributions from 3G.IP.
0. History and Change Log
Feb 5, 2001 - 05
Changes requested by the IESG:
Removal of note to Transparency requirement.
Addition of the sections Security Considerations and IANA
Considerations.
Dec 5, 2000 - 04
Changed the definitions of loss propagation and damage propagation
to coincide with how they are used in draft-ietf-rohc-rtp-XX.txt
Nov 1, 2000 - 03
Changed "packet" to "header" on several places.
June 7, 2000 - 02
Transparency: Added note saying that the ROHC WG has not found an
instance where semantically identical is not the same as bitwise
identical.
Ubiquity: Added note saying that ROHC may recommend changes that
will improve compression efficiency.
2.2.4 IPSEC: new requirement
Performance/Spectral Efficiency: changed "error conditions" to
"operating conditions".
Split Cellular Handover requirement in two: one dealing with loss
events caused by handover, and another dealing with context
recreation after switching compressor or decompressor to a new
node.
Added note to Genericity requirement stating that it applies to an
RTP stream before as well as after it has passed through IP-
networks.
Added note to Error Propagation requirement that explains the
terms "loss propagation" and "damage propagation".
2.3.11: Residual bit-error rate: New requirement
May 20, 2000 - 01
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 - 00
Initial version of this document. Distributed over the ROHC WG
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 round perform well over links with high error rates and long link round
trip times. The schemes must perform well for cellular links build trip times. The schemes must perform well for cellular links built
using technologies such as WCDMA, EDGE, and CDMA-2000. However, the using technologies such as WCDMA, EDGE, and CDMA-2000. However, the
schemes should also be applicable to other future link technologies schemes should also be applicable to other future link technologies
with high loss and long round trip 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
efficiency requirements and requirements which stem from the concerns 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
Several current standardization efforts in the cellular arena aim at Several current standardization efforts in the cellular arena aim at
supporting voice over IP and other real-time services over IP, e.g., supporting voice over IP and other real-time services over IP, e.g.,
GERAN (specified by the ETSI SMG2 standards group), and UTRAN GERAN (specified by the ETSI SMG2 standards group), and UTRAN
(specified by the 3GPP standards organization). It is critical for (specified by the 3GPP standards organization). It is critical for
these standardization efforts that a suitable header compression these standardization efforts that a suitable header compression
scheme is developed before completion of the Release 2000 standards. scheme is developed before completion of the Release 2000 standards.
Therefore, it is imperative that the ROHC WG keeps its schedule. Therefore, it is imperative that the ROHC WG keeps its schedule.
2.1 Impact on Internet infrastructure 2.1 Impact on Internet infrastructure
1. Transparency: When a header is compressed and then decompressed, 1. Transparency: When a header is compressed and then decompressed,
the resulting header must be semantically identical to the original the resulting header must be semantically identical to the original
header. If this cannot be achieved, the packet containing the header. If this cannot be achieved, the packet containing the
erroneous header must be discarded. erroneous header must be discarded.
Justification: The header compression process must not produce Justification: The header compression process must not produce
headers that might cause problems for any current or future part of headers that might cause problems for any current or future part of
the Internet infrastructure. the Internet infrastructure.
Note: The ROHC WG has not found a case where "semantically identical"
is not the same as "bitwise identical".
2. Ubiquity: Must not require modifications to existing IP (v4 or 2. Ubiquity: Must not require modifications to existing IP (v4 or
v6), UDP, or RTP implementations. v6), UDP, or RTP implementations.
Justification: Ease of deployment. Justification: Ease of deployment.
Note: The ROHC WG may recommend changes that would increase the Note: The ROHC WG may recommend changes that would increase the
compression efficiency for the RTP streams emitted by compression efficiency for the RTP streams emitted by
implementations. However, ROHC cannot rely on such recommendations implementations. However, ROHC cannot rely on such recommendations
being followed. being followed.
2.2 Supported headers and kinds of RTP streams 2.2 Supported headers and kinds of RTP streams
1. Ipv4 and Ipv6: Must support both IPv4 and IPv6. 1. IPv4 and IPv6: Must support both IPv4 and IPv6.
Justification: IPv4 and IPv6 will both be around during the Justification: IPv4 and IPv6 will both be around during the
foreseeable future. foreseeable future.
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be 2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be
compressed efficiently. For IPv4 these include headers of tunneled compressed efficiently. For IPv4 these include headers of tunneled
packets. For IPv6 these include headers containing the Routing packets. For IPv6 these include headers containing the Routing
Header, the Binding Update Destination Option, and the Home Address Header, the Binding Update Destination Option, and the Home Address
option. option.
Justification: It is very likely that Mobile IP will be used by Justification: It is very likely that Mobile IP will be used by
cellular devices. cellular devices.
3. Genericity: Must support compression of headers of arbitrary RTP 3. Genericity: Must support compression of headers of arbitrary RTP
streams. streams.
Justification: There must be a generic scheme which can compress Justification: There must be a generic scheme which can compress
reasonably well for any payload type and traffic pattern. This does reasonably well for any payload type and traffic pattern. This does
not preclude optimizations for certain media types where the traffic not preclude optimizations for certain media types where the traffic
pattern is known, e.g., for low-bandwidth voice and low-bandwidth pattern is known, e.g., for low-bandwidth voice and low-bandwidth
video. video.
Note: This applies to the RTP stream before as well as after it has Note: This applies to the RTP stream before as well as after it has
passed through an internet. passed through an internet.
4. IPSEC: ROHC should be able to compress headers containing IPSEC 4. IPSEC: ROHC should be able to compress headers containing IPSEC
subheaders. subheaders.
Note: It is of course not possible to compress the encrypted part of Note: It is of course not possible to compress the encrypted part of
an ESP header, nor the cryptographic data in an AH header. an ESP header, nor the cryptographic data in an AH header.
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 RFC 2508 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. RFC 2508 does
not perform well enough. not perform well enough.
Note: The relative overhead is the average header overhead relative Note: The relative overhead is the average header overhead relative
to the payload. Any auxiliary (e.g., control or feedback) channels to the payload. Any auxiliary (e.g., control or feedback) channels
used by the scheme should be taken into account when calculating the used by the scheme should be taken into account when calculating the
header overhead. 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 an error causes subsequent headers to be lost, and propagation, where an error causes subsequent headers to be lost, and
damage propagation, where an error causes subsequent headers to be damage propagation, where an error causes subsequent headers to be
damaged. damaged.
3a. Handover loss events: There must be a way to run ROHC where loss 3a. Handover loss events: There must be a way to run ROHC where loss
events of length 150 milliseconds are handled efficiently and where events of length 150 milliseconds are handled efficiently and where
loss or damage propagation is not introduced by ROHC during such loss or damage propagation is not introduced by ROHC during such
events. events.
skipping to change at page 6, line 42 skipping to change at page 4, line 20
Justification: Such loss events can be introduced by handover Justification: Such loss events can be introduced by handover
operations in a (radio) network between compressor and decompressor. operations in a (radio) network between compressor and decompressor.
Handover operations can be frequent in cellular systems. Failure to Handover operations can be frequent in cellular systems. Failure to
handle handover well can adversely impact spectrum efficiency and handle handover well can adversely impact spectrum efficiency and
quality. quality.
3b. Handover context recreation: There must be a way to run ROHC that 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 deals well with events where the route of an RTP conversation changes
such that either the compressor or the decompressor of the 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 introduce erroneous headers during such be recreated. ROHC must not introduce erroneous headers during such
events, and should not introduce packet loss 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.
4. Link delay: Must operate under all expected link delay conditions. 4. Link delay: Must operate under all expected link delay conditions.
5. Processing delay: The scheme must not contribute significantly to 5. Processing delay: The scheme must not contribute significantly to
system delay budget. system delay budget.
6. Multiple links: The scheme must perform well when there are two or 6. Multiple links: The scheme must perform well when there are two or
more cellular links in the end-to-end path. more cellular links in the end-to-end path.
Justification: Such paths will occur. Justification: Such paths will occur.
Note: loss on previous links will cause irregularities in the RTP Note: loss on previous links will cause irregularities in the RTP
stream reaching the compressor. Such irregularities should only stream reaching the compressor. Such irregularities should only
marginally affect performance. marginally affect performance.
7a. Packet Misordering: The scheme should be able to compress when 7a. Packet Misordering: The scheme should be able to compress when
there are misordered packets in the RTP stream reaching the there are misordered packets in the RTP stream reaching the
compressor. No misordering is expected on the link between compressor. No misordering is expected on the link between
compressor and decompressor. compressor and decompressor.
Justification: Misordering happens regularly in the Internet. Justification: Misordering happens regularly in the Internet.
However, since the Internet is engineered to run TCP reasonably well, However, since the Internet is engineered to run TCP reasonably well,
excessive misordering will not be common and need not be handled with excessive misordering will not be common and need not be handled with
skipping to change at page 8, line 20 skipping to change at page 5, line 48
Note: This requirement is intended to prevent schemes that achieve Note: This requirement is intended to prevent schemes that achieve
robustness at the expense of delay, for example schemes that require robustness at the expense of delay, for example schemes that require
that header i+x, x>0, is received before header i can be that header i+x, x>0, is received before header i can be
decompressed. decompressed.
Note: Together with 2.3.5, this requirement implies that ROHC will 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 not noticeably add to the jitter of the RTP stream, other than what
is caused by variations in header size. is caused by variations in header size.
Note: This requirement does not prevent a queue from forming upstream Note: This requirement does not prevent a queue from forming upstream
a bottleneck link. Nor does it prevent a compressor from utilizing a bottleneck link. Nor does it prevent a compressor from utilizing
information from more than one header in such a queue. information from more than one header in such a queue.
11. Residual errors: For a residual bit-error rate of at most 1e-5, 11. Residual errors: For a residual bit-error rate of at most 1e-5,
the ROHC scheme must not increase the error rate. the ROHC scheme must not increase the error rate.
Justification: Some target links have a residual error rate, i.e, Justification: Some target links have a residual error rate, i.e,
rate of undetected errors, of this magnitude. rate of undetected errors, of this magnitude.
Note: In the presence of residual bit-errors, ROHC will need error Note: In the presence of residual bit-errors, ROHC will need error
detection mechanisms to prevent damage propagation. These mechanisms detection mechanisms to prevent damage propagation. These mechanisms
will catch some residual errors, but those not caught might cause will catch some residual errors, but those not caught might cause
damage propagation. This requirement states that the reduction of damage propagation. This requirement states that the reduction of
the damage rate due to the error detection mechanisms must not be the damage rate due to the error detection mechanisms must not be
less than the increase in error rate due to damage propagation. less than the increase in error rate due to damage propagation.
3. IANA Considerations 3. IANA Considerations
A protocol which meets these requirements, e.g., [ROHC], will require A protocol which meets these requirements, e.g., [ROHC], will require
the IANA to assign various numbers. This document by itself, however, the IANA to assign various numbers. This document by itself,
does not require any IANA involvment. however, does not require any IANA involvement.
4. Security Considerations 4. Security Considerations
A protocol specified to meet these requirements, e.g., [ROHC], must be A protocol specified to meet these requirements, e.g., [ROHC], must
able to compress packets containing IPSEC headers according to the IPSEC be able to compress packets containing IPSEC headers according to the
requirement, 2.2.4. There may be other security aspects to consider in IPSEC requirement, 2.2.4. There may be other security aspects to
such protocols. This document by itself, however, does not add any consider in such protocols. This document by itself, however, does
security risks. not add any security risks.
5. Editor's address 5. Editor's Address
Mikael Degermark Tel (May-July): +46 70 833-8933 Mikael Degermark
Dept. of Computer Science Tel: +1 520 621-3489 Dept. of Computer Science
University of Arizona Fax: +1 520 621-4246 University of Arizona
P.O. Box 210077 P.O. Box 210077
Tucson, AZ 85721-0077 Tucson, AZ 85721-0077
USA EMail: micke@cs.arizona.edu 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 6. References
[TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership [TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership
Project; Technical Specification Group Services and Project; Technical Specification Group Services and Systems
Systems Aspects; Architecture for an All IP network. Aspects; Architecture for an All IP network.
[TS] TS 22.101 version 3.6.0: Service Principles [TS] TS 22.101 version 3.6.0: Service Principles
[RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980. [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed [RFC1144] Jacobson, V., "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] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links, RFC 2508. for Low-Speed Serial Links", RFC 2508, February 1999.
[ROHC] C. Bormann (ed), Robust Header Compression (ROHC), draft- [OHC] Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC
ietf-rohc-rtp-08.txt 3095, June 2001.
This draft expires Aug 5, 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.
 End of changes. 36 change blocks. 
147 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/