draft-ietf-rohc-rtp-requirements-04.txt   draft-ietf-rohc-rtp-requirements-05.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: Jun 21, 2001 Dec 21, 2000 Expires: Aug 5, 2001 Feb 5, 2001
Requirements for robust IP/UDP/RTP header compression Requirements for robust IP/UDP/RTP header compression
<draft-ietf-rohc-rtp-requirements-04.txt> <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 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 2, line 6 skipping to change at page 2, line 6
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
Feb 5, 2001 - 05
Nov 1, 2000 - draft-ietf-rohc-rtp-requirements-03.txt 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. Changed "packet" to "header" on several places.
June 7, 2000 - draft-ietf-rohc-rtp-requirements-02.txt June 7, 2000 - 02
Transparency: Added note saying that the ROHC WG has not found an Transparency: Added note saying that the ROHC WG has not found an
instance where semantically identical is not the same as bitwise instance where semantically identical is not the same as bitwise
identical. identical.
Ubiquity: Added note saying that ROHC may recommend changes that Ubiquity: Added note saying that ROHC may recommend changes that
will improve compression efficiency. will improve compression efficiency.
2.2.4 IPSEC: new requirement 2.2.4 IPSEC: new requirement
skipping to change at page 2, line 39 skipping to change at page 2, line 52
Added note to Genericity requirement stating that it applies to an Added note to Genericity requirement stating that it applies to an
RTP stream before as well as after it has passed through IP- RTP stream before as well as after it has passed through IP-
networks. networks.
Added note to Error Propagation requirement that explains the Added note to Error Propagation requirement that explains the
terms "loss propagation" and "damage propagation". terms "loss propagation" and "damage propagation".
2.3.11: Residual bit-error rate: New requirement 2.3.11: Residual bit-error rate: New requirement
May 20, 2000 - draft-ietf-rohc-rtp-requirements-01.txt May 20, 2000 - 01
added "robust" to the title of the document. added "robust" to the title of the document.
2.1.2 Mobile-IP: Added requirement for compression of Home Address 2.1.2 Mobile-IP: Added requirement for compression of Home Address
option. option.
2.3.3 Cellular handover: Added note to requirement stating that 2.3.3 Cellular handover: Added note to requirement stating that
handover procedure will not be prescribed as the procedure will be handover procedure will not be prescribed as the procedure will be
highly system-dependent. However, it must be possible to run ROHC highly system-dependent. However, it must be possible to run ROHC
such that handover is an efficient operation. such that handover is an efficient operation.
2.3.7 Packet misordering: Added note to explain why only moderate 2.3.7 Packet misordering: Added note to explain why only moderate
misordering needs to be handled efficiently. misordering needs to be handled efficiently.
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 - 00
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 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 build
using technologies such as WCDMA, EDGE, and CDMA-2000. However, the using technologies such as WCDMA, EDGE, and CDMA-2000. However, the
skipping to change at page 6, line 38 skipping to change at page 6, line 38
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.
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 3b. Handover context recreation: There must be a way to run ROHC that
that deals well with events where the route of an RTP conversation deals well with events where the route of an RTP conversation changes
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
skipping to change at page 8, line 36 skipping to change at page 8, line 36
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. Editor's address 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 involvment.
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 Tel (May-July): +46 70 833-8933 Mikael Degermark Tel (May-July): +46 70 833-8933
Dept. of Computer Science Tel: +1 520 621-3489 Dept. of Computer Science Tel: +1 520 621-3489
University of Arizona Fax: +1 520 621-4246 University of Arizona Fax: +1 520 621-4246
P.O. Box 210077 P.O. Box 210077
Tucson, AZ 85721-0077 Tucson, AZ 85721-0077
USA EMail: micke@cs.arizona.edu USA EMail: micke@cs.arizona.edu
4. 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 Aspects; Architecture for an All IP network. Systems 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. [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.
skipping to change at page 9, line 14 skipping to change at page 9, line 32
[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 June 21, 2001. [ROHC] C. Bormann (ed), Robust Header Compression (ROHC), draft-
ietf-rohc-rtp-08.txt
This draft expires Aug 5, 2001.
 End of changes. 

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