Network Working Group Krister Svanbro, Ericsson
INTERNET-DRAFT Sweden
Expires: November 2000 May 23, 2000
Lower Layer Guidelines for Robust Header Compression
<draft-ietf-rohc-lower-layer-guidelines-00.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 describes lower layer guidelines for robust header
compression (HC). The purpose of this document is to support the
incorporation of robust header compression algorithms, as specified
in the ROHC working group, into different systems such as those
specified by 3GPP, 3GPP2, ETSI, etc. This document treats general
guidelines as well as guidelines specific for cellular systems.
Svanbro [Page 1]
INTERNET-DRAFT Lower Layer Guidelines for Robust HC May 23, 2000
TABLE OF CONTENTS
1. Introduction..................................................3
2. Terminology...................................................3
3. Guidelines for robust RTP/UDP/IP header compression...........3
3.1 General guidelines..........................................3
3.1.1 Error detection on (compressed) headers.............3
3.1.2 Indication of erroneous headers.....................4
3.1.3 Inferred header field information...................4
3.1.4 Handling of header size variation...................4
3.1.5 Negotiation of header compression parameters........5
3.1.6 Demultiplexing of flows onto logically
separated channels..................................5
3.1.7 Packet type identification...........................5
3.2 Cellular system specific guidelines.........................5
3.2.1 Handover procedures..................................6
4. Guidelines for Robust TCP/IP Header Compression...............7
5. Author's addresses............................................7
6. References....................................................7
Svanbro [Page 2]
INTERNET-DRAFT Lower Layer Guidelines for Robust HC May 23, 2000
1. Introduction
Almost all header compression algorithms [RFC1144, RFC2507, RFC2508]
rely on some functionality from underlying link layer. Headers
(compressed or not) are expected to be delivered without any residual
bit errors, IP length fields are inferred from link layer length
fields and packet type identification may be separated from the
header compression scheme and instead done at underlying link layer.
[RFC2509], for example, elaborates on how to incorporate IP header
compression [RFC2507] in PPP [RFC1661].
It is important to be aware of such assumptions on required
functionality from underlying layers when incorporating a header
compression scheme into a system. The functionality required by a
specific header compression scheme from lower layers may also be
needed if incorporation of a header compression scheme is to be
prepared without knowing the exact details of the final scheme.
This document describes lower layer guidelines for robust header
compression as being specified by the ROHC working group. These
guidelines should simplify incorporation of the robust header
compression algorithms into cellular system like those standardized
by 3GPP, 3GPP2, ETSI, etc, and also into specific link layer
protocols such as PPP. The document should also enable preparation of
this incorporation without requiring detailed knowledge about the
final header compression scheme. Relevant standardization groups
standardizing link layers should, aided by this document, include
required functionality in "their" link layers to support robust
header compression.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
3. Guidelines for robust RTP/UDP/IP header compression
This chapter treats guidelines for robust RTP/UPD/IP header
compression.
3.1 General guidelines
3.1.1 Error detection on (compressed) headers
All current header compression schemes [RFC1144, RFC2507, RFC2508]
rely on lower layers to detect errors in (compressed) headers. The
link layer underlying header compression MUST provide error detection
to the de-compressor if the compressed header do not have an internal
error detection. Headers passed up to the header decompressor should
have a residual bit error rate (undetected bit error rate) very close
Svanbro [Page 3]
INTERNET-DRAFT Lower Layer Guidelines for Robust HC May 23, 2000
to zero. (Further work is needed to find a numerical value or
interval on the required residual bit error rate.)
3.1.2 Indication of erroneous headers
It is RECOMMENDED that erroneous headers are passed up to the
decompressor, but in that case an indication that the header has
errors MUST be included to the decompressor together with erroneous
headers.
3.1.3 Inferred header field information
Some fields of the RTP/UDP/IP headers may be classified as inferred,
that is their values are to be inferred from other values or from an
underlying link layer. An underlying link layer MUST therefore
provide the header decompressor with the following information:
Packet Length (IPv4)
Information about the received packet (with the compressed header)
length MUST be provided by the link layer.
Payload Length (IPv6)
Information about the received packet (with the compressed header)
length MUST be provided by the link layer.
Length (UDP)
This field is redundant with the Packet Length (IPv4) or the
Payload Length (IPv6) field. Hence, the value of this field MUST in
some way be provided to the decompressor.
In summary, all of the fields above relate to the length of the
packet the compressed header is included in. All three fields may
thus be inferred by the decompressor if one packet length value is
signaled from the link layer to the decompressor on a per packet
basis. This packet length value should be the length of the received
packet including the (compressed) header.
3.1.4 Handling of header size variations
It is desirable for many cellular link layer technologies that bit
rate variations are minimized. However, there will always be some
variation in compressed header sizes since there is a trade-off
between header size variations and compression efficiency, and also
due to events in the header flow and on the channel. The link layer
MUST in some manner support varying header sizes from 40 bytes (full
RTP/UDP/IPv4 header) or 60 bytes (full RTP/UDP/IPv6) down to 1 byte
for the minimal compressed header. It is likely that the small
compressed headers are dominating the flow of headers, and that the
Svanbro [Page 4]
INTERNET-DRAFT Lower Layer Guidelines for Robust HC May 23, 2000
largest headers are sent rarely, e.g. only a few times in the
initialization phase of the header compression scheme.
(Further work is needed to gain more accurate numbers on header size
distributions; the number of different header sizes and the
distribution among these sizes in typical cases.)
3.1.5 Negotiation of header compression parameters
The ROHC header compression scheme will have some parameters that
needs to be set at an initial setup phase. For instance, the header
compression profile to use may have to be determined [ROCCO].
Compressor and decompressor capabilities may also be negotiated.
Hence, the link layer supporting robust header compression MUST
include mechanisms for negotiating header compression parameters such
as, header compression profiles, compressor and decompressor
capabilities.
It also RECOMMENDED that the link layer have mechanisms that support
re-negotiations of such parameters.
3.1.6 Demultiplexing of flows onto logically separated channels
In some cellular technologies there are a demultiplexing of flows
onto radio bearers suitable to the particular flows, i.e., onto
logically separated channels. For instance, real-time flows such as
voice and video may be carried on logically separated bearers. It is
RECOMMENDED that this kind of demultiplexing is done in the link
layer technology supporting robust header compression. By doing so,
the need for context identification in the header compression scheme
is reduced. If there is a one to one mapping between flow and logical
channel, there is no need at all for context identification at the
header compression level.
3.1.7 Packet type identification
Header compression schemes like [RFC2507, RFC2508] have relied on the
underlying link layer to identify different kinds of headers. This
kind of mechanism is not necessary for robust RTP/UDP/IP header
compression. The packet type identification will be incorporated in
the header compression scheme and there is thus, no need for such a
mechanism in the link layer.
3.2 Cellular system specific guidelines
An important group of link layer technologies where robust header
compression will be needed are future cellular systems, which may
have a very large number of users in some years. The need for header
compression is large in these kinds of systems to achieve spectrum
efficiency. Hence, it is important that future cellular systems can
efficiently incorporate the robust header compression scheme.
Svanbro [Page 5]
INTERNET-DRAFT Lower Layer Guidelines for Robust HC May 23, 2000
3.2.1 Handover procedures
One cellular specific property that may affect header compression is
mobility and thus, handover (i.e., change of serving base station or
radio network controller).
The main characteristics of handovers relevant for robust header
compression are: the length of the longest packet loss event due to
handover (i.e. the number of consecutive packet losses); relocation
of header compression context when necessary.
Depending on the location of the header compressor/decompressor in
the radio access network and the type of handover, handover may or
may not cause disruptions or packet loss events in the (compressed)
header flow relevant for the header compression scheme. For instance,
if soft handover is used and if the header compressor/decompressor
resides above the combining point for soft handover, there will be no
extra packet losses visible to the decompressor due to handover. In
hard handovers, where packet loss events due to handover is
introduced, the length of the longest consecutive packet loss is most
relevant and should thus, be minimized.
Handover SHOULD NOT cause significant long events of consecutive
packet loss. Significant in this context relates to the kind of loss
tolerable for the carried real-time application.
If hard handovers are performed, which may cause significant long
events of consecutive packet loss, it is RECOMMENDED that the radio
access network notifies the compressor that such a handover is
occurring.
The cellular system supporting robust header compression MAY also
have internal mechanisms for transferring the header compression
context between nodes where contexts may reside, at or before
handover.
If the cellular system does not have any internal mechanism for
transferring header compression context between nodes, the transfer
of context may be done by the header compression scheme. The header
compression scheme may perform a new header compression
initialization, e.g. by sending "full" headers. This will, however,
introduce an increase in the average header size dependent on how
often a transfer of context is needed.
In this latter case, the lower layers MUST indicate to the header
compressor that a handover has occurred, so that it knows when to
perform the initialization.
Svanbro [Page 6]
INTERNET-DRAFT Lower Layer Guidelines for Robust HC May 23, 2000
4. Guidelines for Robust TCP/IP Header Compression
This chapter treats guidelines for robust TCP/IP header compression.
To be written.
5. Author's Addresses
Krister Svanbro Tel: +46 920 20 20 77
Ericsson Research Mobile: +46 70 621 69 42
Lulea, Sweden EMail: krister.svanbro@ericsson.com
6. References
[RFC1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP
Header Compression", RFC 2507, February 1999.
[RFC2508] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February
1999.
[RFC2509] Mattias Engan, Steven Cassner, "IP Header Compression
over PPP", RFC2509, February 1999
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[ROCCO] Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, Krister
Svanbro, "RObust Checksum-based header COmpression
ROCCO)", Internet-Draft (work in progress), May 2000.
<draft-ietf-rohc-rtp-rocco-00.txt>
This Internet-Draft expires in November 2000.
Svanbro [Page 7]
