< draft-ietf-rohc-rtp-0-byte-requirements-01.txt		draft-ietf-rohc-rtp-0-byte-requirements-02.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group Lars-Erik Jonsson		RFC 3243
	INTERNET-DRAFT Ericsson
	Expires: February 2001 August 15, 2001
	Requirements and Assumptions for ROHC 0-byte IP/UDP/RTP Compression
	<draft-ietf-rohc-rtp-0-byte-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 cite them other than as "work in progress".
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/lid-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 the 0-byte IP/UDP/RTP header
	compression scheme to be developed by the ROHC WG. It also includes
	the basic assumptions for the typical link layers 0-byte compression
	may be implemented over and assumptions about its usage in general.
	for 0-byte ROHC RTP
	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, 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.
	ROHC RTP has become a very efficient, robust and capable compression
	scheme, able to compress the IP/UDP/RTP headers down to a total size
	of one octet only. This makes ROHC RTP an excellent solution for the
	future cellular environments with new air interfaces, such as WCDMA,
	making even speech services possible over IP with an insignificantly
	lower spectrum efficiency than with existing circuit switched
	solutions.
	However, all-IP cellular networks will be built also with already
	existing air interfaces such as GSM and IS-95, which are less
	flexible with radio bearers optimized for specific frame sizes
	matching the speech codecs used. This means that not a single octet
	of header can be added without using the next higher fixed packet
	size of the link and that is obviously very costly. In the long run,
	this should of course be solved with new more flexible air
	interfaces, but until then it would be desirable if an efficiency
	comparable to the circuit switched case could be achieved also for
	the already deployed speech codecs when used over the existing air
	interfaces. To achieve that, it must be possible to completely
	eliminate the headers for a majority of the packets during normal
	operation, and this is the purpose of 0-byte header compression. All
	functionality normally provided by the 1-otet header must then be
	provided by some other means, typically by utilizing functionality
	from the lower layer. It is important to remember that the purpose of
	0-byte header compression is to provide optimal efficiency for
	applications matching the link layer characteristics, not efficiency
	in general.
	As a starting point for these requirements, the well established
	requirements base developed in the ROHC WG has been used. From that,
	the requirements have evolved through inputs from the 3GPP2 community
	and from discussions within the WG.
	2. Assumptions for the applicability of 0-byte RTP header compression
	The purpose of 0-byte header compression is to provide optimal usage
	of certain links when the traffic pattern of a packet stream
	completely matches the characteristics of that link. There are no
	assumptions that only packet streams complying with that pattern will
	occur, but optimal efficiency can of course not be provided when this
	is not the case.
	for 0-byte ROHC RTP
	To make 0-byte header compression feasible, it is assumed that lower
	layers can provide the necessary functionality needed to replace the
	1-octet headers and fulfil the requirements defined in section three.
	An example is the synchronized nature of most cellular links, which
	can provide sequencing and timing information and make packet loss
	detection possible.
	3. Requirements on 0-byte RTP header compression
	Since 0-byte header compression for ROHC IP/UDP/RTP is a variant of
	regular ROHC RTP compression [ROHC], these requirements are described
	as deltas to those defined in the regular RTP requirements [RTP-REQ].
	For simplicity, this section is also separated into the same three
	subsections as the requirements in [RTP-REQ], where the first deals
	with header compression impacts on the rest of the Internet
	infrastructure, the second concerns the headers to be compressed and
	the third covers efficiency and link technology related issues.
	3.1. Impact on Internet infrastructure
	The meaning of header compression is in no way changed by the
	introduction of 0-byte header compression. No additional impact on
	the Internet infrastructure is thus allowed. The "Transparency" and
	"Ubiquity" requirements of [RTP-REQ, section 2.1] therefore also
	apply to 0-byte RTP compression without any modifications.
	3.2. Supported headers and kinds of RTP streams
	The 0-byte RTP compression scheme have in general the same
	requirements on supported headers and RTP streams as regular ROHC RTP
	[RTP-REQ, section 2.2]. However, there are some aspects regarding the
	"Genericity" and IPSEC requirements that should be noted.
	The "Genericity" requirement of [RTP-REQ] states that compression of
	headers of arbitrary RTP streams must be supported, and this is also
	true for the 0-byte compression scheme to the extent that it is not
	allowed to assume certain RTP behavior. However, as also stated in
	[RTP-REQ], this does not preclude optimizations for certain media
	types where the traffic pattern is known. For 0-byte RTP, this means
	that the scheme must be able to handle arbitrary RTP streams to
	fulfil the requirements of section 3.1. However, due to the typical
	characteristics of 0-byte compression, by requiring a traffic pattern
	that suites the link it is implemented over to be able to compress
	down to 0-byte headers, it becomes optimized for applications with
	link-suited traffic patterns. For traffic that do not comply with the
	link properties, the scheme must automatically and immediately fall
	for 0-byte ROHC RTP
	back to non-0-byte RTP compression and not have any impact on the
	packet stream.
	Regarding IPSEC, it should be noted that 0-byte compression can not
	be achieved if parts of the original headers are encrypted or carry
	randomly changing fields. IPSEC and 0-byte RTP header compression
	therefore does not go well together. If IPSEC is used and prevents 0-
	byte compression, the scheme must fall back to a less efficient
	compression that can handle all present header fields. Of course,
	this applies not only to IPSEC but to all cases where headers can not
	be compressed down to 0-byte.
	3.3. Performance issues
	All the performance requirements of [RTP-REQ] also applies to 0-byte
	RTP header compression, with the following additions and exceptions:
	- Performance/Spectral Efficiency: For packet streams with traffic
	patterns that matches the characteristics of the link 0-byte
	header compression is implemented over, the performance should be
	such that 0-byte header packets are generated for most of the
	time during normal operation. 0-byte headers would then replace
	most of the 1-octet headers used by regular ROHC RTP [ROHC].
	Justification: Spectrum efficiency is a primary goal. Studies
	have shown that for certain applications and link technologies,
	even a single octet of header may result in a significant
	decrease in spectrum efficiency compared to existing circuit
	switched solutions.
	- Header Compression Coexistence: The scheme must fit into the ROHC
	framework together with other ROHC profiles.
	Justification: Implementation simplicity is an important issue
	and the 0-byte RTP compression scheme should therefore have as
	much as possible in common with the regular IP/UDP/RTP profile.
	- Unidirectional links: It is of less importance that the 0-byte
	header compression scheme must be able to work also over
	unidirectional links.
	Justification. 0-byte header compression is targeting links that
	typically are bi-directional.
	for 0-byte ROHC RTP
	4. IANA Considerations
	A protocol which meets these requirements, e.g., [LLA], will require
	the IANA to assign various numbers. This document by itself, however,
	does not require any IANA involvement.
	5. Security Considerations
	A protocol specified to meet these requirements, e.g., [LLA], may
	have a number of security aspects to consider. This document by
	itself, however, does not add any security risks.
	6. References
	[RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP		Title: RObust Header Compression (ROHC):
	header compression", RFC 3096, July 2001.		Requirements and Assumptions for 0-byte IP/UDP/RTP
			Compression
			Author(s): L-E. Jonsson
			Status: Informational
			Date: April 2002
			Mailbox: lars-erik.jonsson@ericsson.com
			Pages: 6
			Characters: 12451
			Updates/Obsoletes/SeeAlso: None
	[ROHC] Bormann, C., et. al., "Robust Header Compression		I-D Tag: draft-ietf-rohc-rtp-0-byte-requirements-02.txt
	(ROHC)", RFC 3095, July 2001.
	[LLA] Jonsson, L-E. and G. Pelletier, "A Link-Layer Assisted		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3243.txt
	ROHC Profile for IP/UDP/RTP", Internet Draft, work in
	progress, August 2001.
	<draft-ietf-rohc-rtp-lla-00.txt>
	7. Author's address		This document contains requirements for the 0-byte IP/UDP/RTP
			(Internet Protocol/User Datagram Protocol/Real-Time Transport
			Protocol) header compression scheme to be developed by the Robust
			Header Compression (ROHC) Working Group. It also includes the basic
			assumptions for the typical link layers over which 0-byte compression
			may be implemented, and assumptions about its usage in general.
	Lars-Erik Jonsson Tel: +46 (920) 20 21 07		This document is a product of the Robust Header Compression Working
	Ericsson Erisoft AB Fax: +46 (920) 20 20 99		Group of the IETF.
	Box 920
	SE-971 28 Lulea
	Sweden E-mail: lars-erik.jonsson@ericsson.com
	for 0-byte ROHC RTP
	Full copyright statement		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Copyright (C) The Internet Society (2001). All Rights Reserved.		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.
	This document and translations of it may be copied and furnished to		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	others, and derivative works that comment on or otherwise explain it		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	or assist in its implementation may be prepared, copied, published		help: ways_to_get_rfcs. For example:
	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		To: rfc-info@RFC-EDITOR.ORG
	revoked by the Internet Society or its successors or assigns.		Subject: getting rfcs
	This document and the information contained herein is provided on an		help: ways_to_get_rfcs
	"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.
	This Internet-Draft expires February 15, 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. 13 change blocks.
	237 lines changed or deleted		36 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/