< draft-ietf-rohc-rtp-requirements-04.txt		draft-ietf-rohc-rtp-requirements-05.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group Mikael Degermark (editor) /University of Arizona		RFC 3096
	INTERNET-DRAFT USA
	Expires: Jun 21, 2001 Dec 21, 2000
	Requirements for robust IP/UDP/RTP header compression
	<draft-ietf-rohc-rtp-requirements-04.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 contains requirements for robust IP/UDP/RTP header
	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",
	version 1.0.0 of October 1999 [TR], as well as contributions from
	3G.IP.
	0. History and Change Log
	Nov 1, 2000 - draft-ietf-rohc-rtp-requirements-03.txt
	Changed "packet" to "header" on several places.
	June 7, 2000 - draft-ietf-rohc-rtp-requirements-02.txt
	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 - 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.
	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 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 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
	(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.
	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
	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.
	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 RFC2508 under equivalent operating
	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.
	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.
	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.
	Justification: Misordering happens regularly in the Internet.
	However, since the Internet is engineered to run TCP reasonably well,
	excessive misordering will not be common and need not be handled with
	optimum efficiently.
	7b. Moderate Packet Misordering: The scheme should efficiently handle
	moderate misordering (2-3 packets) in the packet stream reaching the
	compressor.
	Note: This kind of reordering is common.
	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 frame size fluctuation: It should be possible to
	restrict the number of different frame sizes used by the scheme.
	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.
	Note: This implies that a list of "good" frame sizes must be made
	available and that ROHC may pick a suitable header format to utilize
	available space as well as possible.
	10. Delay: ROHC should not noticeably add to the end-to-end delay.
	Justification: RTP packets carrying data for interactive voice or
	video have a limited end-to-end delay budget.
	Note: This requirement is intended to prevent schemes that achieve
	robustness at the expense of delay, for example schemes that require
	that header i+x, x>0, is received before header 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.
	11. Residual errors: For a residual bit-error rate of at most 1e-5,
	the ROHC scheme must not increase the error rate.
	Justification: Some target links have a residual error rate, i.e,
	rate of undetected errors, of this magnitude.
	Note: In the presence of residual bit-errors, ROHC will need error
	detection mechanisms to prevent damage propagation. These mechanisms
	will catch some residual errors, but those not caught might cause
	damage propagation. This requirement states that the reduction of
	the damage rate due to the error detection mechanisms must not be
	less than the increase in error rate due to damage propagation.
	3. Editor's address		Title: Requirements for robust IP/UDP/RTP header
			compression
			Author(s): M. Degermark, Editor
			Status: Informational
			Date: July 2001
			Mailbox: micke@cs.arizona.edu
			Pages: 8
			Characters: 15018
			Updates/Obsoletes/SeeAlso: None
	Mikael Degermark Tel (May-July): +46 70 833-8933		I-D Tag: draft-ietf-rohc-rtp-requirements-05.txt
	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		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3096.txt
	[TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership		This document is a product of the Robust Header Compression Working
	Project; Technical Specification Group Services and		Group of the IETF.
	Systems Aspects; Architecture for an All IP network.
	[TS] TS 22.101 version 3.6.0: Service Principles		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	[RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980.		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	[RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981.		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	[RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed		To: rfc-info@RFC-EDITOR.ORG
	Serial Links, RFC 1144, February 1990.		Subject: getting rfcs
	[CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers		help: ways_to_get_rfcs
	for Low-Speed Serial Links, RFC 2508.
	This draft expires June 21, 2001.		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 12 change blocks.
	333 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/