Network Working Group Lars-Erik Jonsson
INTERNET-DRAFT Ericsson
Expires: February 2001 August 15, 2001A new Request for Comments is now available in online RFC libraries.
RFC 3243
Title: RObust Header Compression (ROHC):
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
Author(s): L-E. Jonsson
Status: Informational
Date: April 2002
Mailbox: lars-erik.jonsson@ericsson.com
Pages: 6
Characters: 12451
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-rohc-rtp-0-byte-requirements-02.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3243.txt
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 ROHC WG. 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 over implemented, 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 document 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 product of the packets during normal
operation, and this is the purpose Robust Header Compression Working
Group 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 IETF.
This memo provides information for
applications matching the link layer characteristics, Internet community. It does
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 specify an Internet standard of that link. There are no
assumptions that only packet streams complying with that pattern will
occur, but optimal efficiency can any kind. Distribution of course not be provided when this
memo is not the case.
for 0-byte ROHC RTP
To make 0-byte header compression feasible, it unlimited.
This announcement is assumed that lower
layers can provide the necessary functionality needed sent 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 IETF list 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 RFC-DIST list.
Requests 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 added 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 or deleted from the
"Genericity" and IPSEC requirements that IETF distribution list
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 sent to the extent that it is not
allowed IETF-REQUEST@IETF.ORG. Requests 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
added to or deleted from the typical
characteristics of 0-byte compression, by requiring a traffic pattern
that suites the link it is implemented over to RFC-DIST distribution list should
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 sent to non-0-byte RTP compression and not have any impact RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details 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 obtaining RFCs via FTP 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 EMAIL may be compressed down to 0-byte.
3.3. Performance issues
All the performance requirements of [RTP-REQ] also applies obtained by sending
an EMAIL message to 0-byte
RTP header compression, rfc-info@RFC-EDITOR.ORG with the following additions and exceptions:
- Performance/Spectral Efficiency: message body
help: ways_to_get_rfcs. 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 example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests 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 special distribution 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 addressed 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 either 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
author 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
header compression", RFC 3096, July 2001.
[ROHC] Bormann, C., et. al., "Robust Header Compression
(ROHC)", the RFC 3095, July 2001.
[LLA] Jonsson, L-E. and G. Pelletier, "A Link-Layer Assisted
ROHC Profile for IP/UDP/RTP", Internet Draft, work in
progress, August 2001.
<draft-ietf-rohc-rtp-lla-00.txt>
7. Author's address
Lars-Erik Jonsson Tel: +46 (920) 20 21 07
Ericsson Erisoft AB Fax: +46 (920) 20 20 99
Box 920
SE-971 28 Lulea
Sweden E-mail: lars-erik.jonsson@ericsson.com
for 0-byte ROHC RTP
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 question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted 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 RFC itself, all RFCs are for the purpose of
developing Internet standards in which case the procedures
unlimited distribution.echo
Submissions for
copyrights defined in the Internet Standards process must Requests for Comments should be
followed, or as required sent 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.
This Internet-Draft expires February 15, 2001.
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.