One document matched: draft-jonsson-robust-hc-00.txt
Network Working Group Lars-Erik Jonsson, Ericsson
INTERNET-DRAFT Mikael Degermark, Lulea University
Expires: December 1999 Hans Hannu, Ericsson
Krister Svanbro, Ericsson
Sweden
June 22, 1999
RObust Checksum-based header COmpression (ROCCO)
<draft-jonsson-robust-hc-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 an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
IP/UDP/RTP header compression [CRTP] can generate a large number of
lost packets when used over links with significant error rates,
especially when the round-trip time of the link is large.
This document describes a more robust header compression scheme. The
scheme is adaptable to the characteristics of the link over which it
is used and also to the properties of the packet streams it
compresses. Robustness against link-loss is achieved without
decreasing compression efficiency.
Jonsson, Degermark, Hannu, Svanbro [Page 1]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Table of contents
1. Introduction..................................................4
2. Terminology...................................................6
3. Existing header compression schemes...........................8
4. Desired improvements..........................................9
5. Proposed solution............................................10
5.1. Base header format....................................11
5.2. Data structures.......................................12
5.3. Header compression profiles...........................12
6. Classification of header fields..............................13
7. A proposed header compression profile for IP-telephony flows.14
7.1. Usage scenarios, environment and requirements.........14
7.2. Analysis of change patterns of header fields...........15
7.2.1. IP Identification............................15
7.2.2. IP Type-Of-Service / Traffic Class...........16
7.2.3. IP Time-To-Live / Hop Limit..................17
7.2.4. UDP Checksum.................................17
7.2.5. RTP Marker...................................17
7.2.6. RTP Payload Type.............................17
7.2.7. RTP Sequence Number..........................17
7.2.8. RTP Timestamp................................17
7.2.9. RTP Contributing Sources (CSRC)..............18
7.2.10. Timestamp delta..............................18
7.3. Packet types and code field usage.....................18
7.4. Robust encoding and decoding of delta information.....19
7.4.1. Sequence number changes to handle............19
7.4.2. Compression of sequence number values........20
7.4.3. Decompression of sequence number values......20
7.5. Header formats........................................21
7.5.1. Static information packet, initialization....21
7.5.2. Context update packet........................22
7.5.3. Compressed packet............................24
7.5.4. Context request packet.......................27
8. UDP checksum.................................................28
9. Supporting multiple flows....................................29
10. Link-layer considerations....................................29
11. Preliminary performance results..............................29
11.1. Simulated scenario....................................29
11.2. Input data............................................30
11.3. Influence of pre-HC links.............................30
11.4. Used link layers......................................30
11.5. The cellular link.....................................32
11.6. Compression performance...............................32
11.7. Robustness results....................................34
11.8. CRC strength considerations...........................37
12. Conclusions..................................................37
13. Intellectual property considerations.........................37
14. References...................................................38
15. AuthorsÆ addresses...........................................39
Jonsson, Degermark, Hannu, Svanbro [Page 2]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Appendix A. Detailed classification of header fields............40
A.1. IPv4 header fields....................................40
A.2. IPv6 header fields....................................40
A.3. UDP header fields.....................................41
A.4. RTP header fields.....................................41
A.5. Summary...............................................42
Appendix B. Mapping of ID and AD fields.........................43
Jonsson, Degermark, Hannu, Svanbro [Page 3]
INTERNET-DRAFT Robust Header Compression June 22, 1999
1. Introduction
During the last five years, two communication technologies in
particular have become commonly used by the general public: cellular
telephony and the Internet. Cellular telephony has provided its users
with a revolutionary possibility to always be reachable with
reasonable service quality no matter where they are. However, up to
now the main service provided has been speech. With the Internet, the
conditions have been almost the opposite. While flexibility for all
kinds of usage has been its strength, its focus has been on fixed
connections and large terminals, and the experienced quality of some
services (like Internet telephony) has generally been low.
Today, IP-telephony is gaining momentum due to improved technical
solutions. It seems reasonable to believe that IP in the years to
come will be a commonly used way to carry telephony. Some future
cellular telephony links might also be based on IP and IP-telephony.
Cellular phones may have IP stacks supporting not only audio and
video, but also web browsing, email, gaming, etc.
The scenario we are envisioning might then be the one in Figure 1.1,
where two mobile terminals are communicating with each other. Both
are connected to base stations over cellular links and the base
stations are connected to each other through a wired (or possibly
wireless) network. Instead of two mobile terminals, there could of
course be one mobile and one wired terminal, but the case with two
cellular links is technically more demanding.
Mobile Base Base Mobile
Terminal Station Station Terminal
| ~ ~ ~ \ / \ / ~ ~ ~ ~ |
| | | |
+--+ | | +--+
| | | | | |
| | | | | |
+--+ | | +--+
| |
|=========================|
Cellular Wired Cellular
Link Network Link
Figure 1.1 : Scenario for IP telephony over cellular links
It is obvious that the wired network can be IP-based. With the
cellular links, the situation is less clear. IP could be terminated
in the fixed network, and special solutions be implemented for each
supported service over the cellular link. However, this would limit
Jonsson, Degermark, Hannu, Svanbro [Page 4]
INTERNET-DRAFT Robust Header Compression June 22, 1999
the flexibility of the services supported. If technically and
economically feasible, a solution with pure IP all the way from
terminal to terminal would have certain advantages. However, to make
IP-all-the-way a viable alternative, a number of problems have to be
addressed, especially regarding bandwidth efficiency.
For cellular phone systems, it is of vital importance to use the
scarce radio resources in an efficient way. A sufficient number of
users per cell is crucial, otherwise deployment costs will be
prohibitive [CELL]. The quality of the voice service should also be
as good as in today's cellular systems. It is likely that even with
support for new services, lower quality of the voice service is
acceptable only if costs are significantly reduced.
A problem with IP over cellular links when used for interactive voice
conversations is the large header overhead. Speech data for IP-
telephony will most likely be carried by RTP [RTP]. A packet will
then, in addition to link-layer framing, have an IP [IPv4] header (20
octets), a UDP [UDP] header (8 octets), and an RTP header (12 octets)
for a total of 40 octets. With IPv6 [IPv6], the IP header is 40
octets for a total of 60 octets. The size of the payload depends on
the speech coding and frame sizes used and may be as low as 15-20
octets.
From these numbers, the need for reducing header sizes for efficiency
reasons is obvious. However, cellular links have characteristics that
make header compression as defined in [IPHC,CRTP,PPPHC] perform less
than well. The most important characteristic is the lossy behavior of
cellular links, where a bit-error-rate (BER) as high as 1e-3 must be
accepted to keep the radio resources efficiently utilized [CELL]. In
severe operating situations, the BER can be as high as 1e-2. The
other problematic characteristic is the long round-trip time (RTT) of
the cellular link, which can be as high as 100-200 milliseconds
[CELL]. A viable header compression scheme for cellular links must be
able to handle loss, on the link between the compression and
decompression point as well as loss before the compression point.
Bandwidth is the most costly resource in cellular links. Processing
power is very cheap in comparison. Implementation or computational
simplicity of a header compression scheme is therefore of less
importance than its compression ratio and robustness.
Unless explicitly stated otherwise, the numbers and figures presented
in this document are for IPv4, not IPv6.
Jonsson, Degermark, Hannu, Svanbro [Page 5]
INTERNET-DRAFT Robust Header Compression June 22, 1999
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.
BER
Bit Error Rate (BER) is an inherent characteristic of cellular
links. In this paper we talk about BER generally as a percentage
value but also the error distribution has to be considered. In
our simulations, we refer to a channel with a certain BER and in
that case the distribution is according to a realistic channel.
Cellular Link
Wireless link in a cellular access network.
Compression Efficiency
The performance of a header compression scheme can be described
with two parameters, Compression Efficiency and Robustness. The
Compression Efficiency is a measure of how much the header sizes
are reduced by the compression scheme.
Compression Profile
A Compression Profile is a description of how to compress a
certain kind of flow over a specific link. Compression Profiles
are applied on top of the general compression framework
introduced in this document.
Context
The Context is the state which the compressor uses to compress
and the decompressor uses to decompress a header. The Context is
the uncompressed version of the last header sent (compressor) or
received (decompressor) over the link, except for fields in the
header that is included "as-is" in compressed headers or can be
inferred from, e.g., the size of the link-level frame.
Context repair mechanism
When the context of the decompressor becomes inconsistent with
the compressors context, header decompression will fail.
Therefore one or several context repair mechanisms are needed.
Repair mechanisms might for instance be based on explicit
updating requests from decompressor to compressor, updates sent
by the compressor on a regular basis or methods applied locally
at the decompressor side.
Jonsson, Degermark, Hannu, Svanbro [Page 6]
INTERNET-DRAFT Robust Header Compression June 22, 1999
FER
The Frame Error Rate (FER) considered in this document is mainly
the degree of packet loss introduced between header compressor
and header decompressor. FER is here defined to be identical to
packet loss rate. FER includes frames lost at the link level and
frames lost due to inconsistent context at the decompressor.
Ideal header compression scheme
For comparison, we have defined what we call an ideal header
compression scheme. This scheme performs like CRTP would do if it
is used over completely reliable error-free links with input data
that do not have difficult changes in the header fields. The
header size of the ideal header compression scheme is always two
bytes like the smallest CRTP packets, and packets will never be
lost due to inconsistent context states.
Header Compression CRC
A checksum created by the header compressor and included in each
packet sent. The CRC might cover different values depending on
the packet type it is included in, and the decompressor usage of
it will then also differ. However, its main purpose is to provide
a way to verify a correct header reconstruction.
Pre-HC links
With Pre-HC links we here mean all links passed before the header
compression. In our scenario, it could be one cellular link on
the other end of the path and the wired network between the
cellular access networks.
Robustness
The performance of a header compression scheme can be described
with two parameters, compression efficiency and robustness. The
robustness describes how tolerant the scheme is to packet losses
between compressor and decompressor without introducing
additional errors.
Spectrum efficiency
The radio resources are limited and expensive. Therefore they
must be used efficiently to make the usage economical feasible.
In cellular systems this is achieved by maximizing the number of
users served within each cell, while still keeping the quality of
the services provided on an acceptable level. This implies for an
example that a high BER must be accepted.
Jonsson, Degermark, Hannu, Svanbro [Page 7]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Timestamp delta
The timestamp delta is the difference between the timestamp
values of two consecutive packets.
Wired network
A wired network is here defined as a reliable high-capacity
network which is almost error-free.
3. Existing header compression schemes
The original header compression scheme, CTCP [VJHC], was invented by
Van Jacobson. CTCP compressed the 40 octet IP + TCP header to 4
bytes.
Header compression methods maintains a context, which is essentially
the uncompressed version of the last header sent over the link, at
both compressor and decompressor. Compression and decompression is
done relative to the context. When compressed headers carry
differences from the previous header, each compressed header will
update the context of the decompressor. When a packet is lost between
compressor and decompressor, the context of the decompressor will be
brought out of sync since it is not updated correctly. A header
compression method must have a way to repair the context, i.e., bring
it in sync, after such events.
The CTCP compressor detects transport-level retransmissions and sends
a header that updates the context completely when they occur. This
repair mechanism does not require any explicit signaling between
compressor and decompressor.
CRTP [CRTP, IPHC] by Casner and Jacobson is a header compression
scheme that compresses 40 octet IPv4/UDP/RTP headers to a minimum of
2 octets when no UDP checksum is present. If the UDP checksum is
present, the minimum CRTP header is 4 octets. CRTP cannot use the
same repair mechanism as CTCP since RTP does not retransmit. Instead,
CRTP uses explicit signaling messages from decompressor to
compressor, called CONTEXT_STATE messages, to indicate that the
context is out of sync. The link roundtrip time will thus limit the
speed of this context repair mechanism.
On lossy links with long roundtrip times, such as most cellular
links, CRTP does not perform well. Each lost packet over the link
causes several subsequent packets to be lost since the context is out
of sync during at least one link roundtrip time. This behavior is
documented in [CRTPC]. For voice conversations such long loss events
will degrade the voice quality. Moreover, bandwidth is wasted by the
large headers sent by CRTP when updating the context. [CRTPC] found
that CRTP performed much worse than an ideal header compression
Jonsson, Degermark, Hannu, Svanbro [Page 8]
INTERNET-DRAFT Robust Header Compression June 22, 1999
scheme for a lossy cellular link. It is clear that CRTP alone is not
a viable header compression scheme for cellular links.
To avoid losing headers due to the context being out of sync, CRTP
decompressors can attempt to repair the context locally by using a
mechanism known as TWICE. Each CRTP packet contains a counter which
is incremented by one for each packet sent out by the CRTP
compressor. If the counter increases by more than one, at least one
packet was lost over the link. The decompressor then attempts to
repair the context by guessing how the lost packet(s) would have
updated it. The guess is then verified by decompressing the packet
and checking the UDP checksum - if it succeeds, the repair is deemed
successful and the packet can be forwarded or delivered. TWICE gets
its name from the observation that when the compressed packet stream
is regular, the correct guess is to apply the update in the current
packet twice. [CRTPC] found that even CRTP with TWICE lost around two
times as many packets than the ideal header compression scheme.
TWICE improves CRTP performance significantly. However, there are
several problems with using TWICE:
1) It becomes mandatory to use the UDP checksum:
- the compressed header size increases by 100% to 4 octets.
- most speech codecs developed for cellular links tolerate errors
in the encoded data. Such codecs will not want to enable the UDP
checksum, since they want damaged packets to be delivered.
- errors in the payload will make the UDP checksum fail when the
guess is correct (and might make it succeed when it is wrong).
2) Loss in an RTP stream that occur before the compression point will
make updates in CRTP headers less regular. Simple-minded versions
of TWICE will then perform badly. More sophisticated versions
would need more repair attempts before finding the correct update.
4. Desired improvements
The major problem with CRTP is that it is not sufficiently robust
against packets being damaged between compressor and decompressor. A
viable header compression scheme must be less fragile. This increased
robustness must be obtained without increasing the compressed header
size; a larger header would make IP telephony over cellular links
economically unattractive.
A major cause for CRTP:s bad performance over cellular links is the
long link roundtrip time, during which many packets are lost when the
context is out of sync. That problem can be attacked directly by
finding ways to reduce the link roundtrip time. Future generations of
Jonsson, Degermark, Hannu, Svanbro [Page 9]
INTERNET-DRAFT Robust Header Compression June 22, 1999
cellular technologies may indeed achieve lower link roundtrip times.
However, they will probably always be rather high [CELL]. The
benefits in terms of lower loss and smaller bandwidth demands if the
context can be repaired locally will be present even if the link
roundtrip time is decreased. A reliable way to detect a successful
context repair is then needed.
One might argue that a better way to solve the problem is to improve
the cellular link so that packet loss is less likely to occur. It
would of course be nice if the links were (almost) error free, but
such a system would not be able to support a sufficiently large
number of users per cell and would thus be economically unfeasible
[CELL].
One might also argue that the speech codecs should be able to deal
with the kind of packet loss induced by CRTP, in particular since the
speech codecs probably must be able to deal with packet loss anyway
if the RTP stream crosses the Internet. While the latter is true, the
kind of loss induced by CRTP is difficult to deal with. It is usually
not possible to hide a loss event where well over 100 ms worth of
sound is completely lost. If such loss occurs frequently at both ends
of the path, the speech quality will suffer.
5. Proposed solution
We propose a solution which is heavily geared towards local repair of
the context. What is needed is a reliable way to detect when a repair
attempt has succeeded, plus possibly hints to the decompressor as to
how the fields have changed.
The key element of our header compression scheme is that compressed
headers carry a 10-bit strong checksum computed over the header
before compression. This provides a reliable way to detect whether
decompression and context repair has succeeded. In addition to these
10 bits, the header will contain codes and additional information as
needed for decompression.
A completely general solution cannot achieve compression rates high
enough to make IP telephony over cellular economically feasible. On
the other hand the solution needs to be extendable so that other
kinds of packet streams can also be compressed well. Therefore, we
envision a scheme where the basic framework is supplemented with
compression profiles that provide the exact details on how a
particular packet stream is to be compressed and decompressed. There
can be a number of compression profiles, exactly one is used per
packet stream. The compression profiles allows the basic framework to
be adapted to the properties of the packet stream as well as the
properties of the link.
Jonsson, Degermark, Hannu, Svanbro [Page 10]
INTERNET-DRAFT Robust Header Compression June 22, 1999
5.1. Base header format
There is only one kind of base header in this scheme. Distinguishing
packet streams and packet types is necessary, but some of that
information may be available from the underlying technology, for
example if each packet stream has its own logical channel. To avoid
wasting precious header bits, we decided to leave it to the
compression profile to decide how to distinguish packet types and
packet streams. This allows efficient use of header bits overall when
the link-layer does not carry explicit information on packet types.
The header format is shown below. The only fields defined by the
basic framework are the Header Compression CRC and Code fields. The
semantics of the Code field is determined by the compression profile
used. By inspecting the Code field, the decompressor knows whether
the Extension field is present and its size, and also if the Payload
field is present.
1 1
0 9 0 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - ~ ~ - - + - - ~ ~ - - +
| Header Compr. CRC | Code | Extension | Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - ~ ~ - - + - - ~ ~ - - +
Header Compression CRC 10-bit CRC covering whatever the current
compression profile specifies for the
packet type.
Code 6-bit code whose semantics is defined
by the compression profile. Determines
whether the next two fields are present.
Extension If present, an extended code and/or
values as determined by Code and
compression profile.
Payload If present, the payload of the original
packet.
A compression profile can define headers which do not have a
corresponding original packet. An example would be to send non-
changing fields of a packet stream as a separate packet. Another
example would be to send packets to update the RTP-timestamp field
even when no RTP packets arrive, in order to decrease the increment
in the RTP-timestamp field when a packet does arrive. For such
compressed headers, the compression profile must specify over what
values the Header Compression CRC is computed.
5.2. Data structures
Jonsson, Degermark, Hannu, Svanbro [Page 11]
INTERNET-DRAFT Robust Header Compression June 22, 1999
The compression scheme needs to maintain a context for compression
and decompression of a packet stream. The context must be kept
updated at both compressor and decompressor. The context is
essentially the last decompressed header, which includes all static
header fields plus some fields that change more or less frequently.
If the compression profile used is designed to handle a certain
amount of packet loss on the link, both compressor and decompressor
will typically keep information about earlier packets; packets that
arrived before the current packet. Finally, there may be flow related
information such as the timestamp delta or a list of which CSRC items
that have occurred in the flow.
5.3. Header compression profiles
The details on how a packet stream is to be compressed and
decompressed is determined by a compression profile. Over a link a
number of profiles can be active, but for each logical channel
exactly one profile is active. How to determine what profile to use
for which channel and how that is negotiated between compressor and
decompressor is not specified in this document.
One way to select a profile can be to have a common channel over
which a general-purpose header compression scheme, perhaps CRTP, is
used. When its found that a packet stream is compressible, and the
change pattern of its fields has been observed, it is switched to
another channel where a suitable compression profile is used.
Profiles can be defined to compress one packet stream only, in which
case the link layer must be able to separate packet streams. Profiles
can also be defined for compression of more than one packet stream in
which case the profile must provide a way to distinguish between the
packet streams.
Important parameters to consider when designing a compression profile
are:
- what support there is from the link-layer, such as the number of
packet streams per channels, and if it can indicate packet types.
- the rate and pattern of loss of the channel.
- the rate and pattern of loss before the compression point.
- what kinds of packet streams to compress (IPv6, IPv4, RTP, TCP,
etc).
- the pattern of change of the changing fields.
Jonsson, Degermark, Hannu, Svanbro [Page 12]
INTERNET-DRAFT Robust Header Compression June 22, 1999
When these things have been considered, the specifics of the profile
can be determined. The profile must specify:
- the exact semantics of the Code field, which will include packet
types, packet formats, extensions, etc.
- what the Header Compression CRC covers for all packet types.
- the information needed for compression and decompression, which
will include history information and properties of the packet
stream.
- procedures for compression and decompression.
- how compression is initiated (full headers, or ?).
- description of context repair mechanisms.
Chapter 7 is an example of a compression profile for IP telephony
over cellular links.
6. Classification of header fields
The IP/UDP/RTP header fields can be classified by the way they are
expected to change. First of all, we classify them as:
STATIC These fields are expected to be constant during the
lifetime of the flow.
STATIC-KNOWN These static fields are expected to have well known
values and are therefore not needed to be
communicated at all.
CHANGING These fields are expected to vary in some way,
either randomly, within a limited scope, or change
with constant values.
INFERRED These fields contain values that can be inferred
from other values, for example the size of the frame
carrying the packet, and thus must not be handled at
all by the compression scheme.
All fields of the IP/UDP/RTP headers are classified in appendix A.
Table 6.1 summarizes this for IP/UDP/RTP. The interval for the
CHANGING fields in Table 6.1 reflect the varying size of the CSRC
list of the RTP header.
Jonsson, Degermark, Hannu, Svanbro [Page 13]
INTERNET-DRAFT Robust Header Compression June 22, 1999
+----------------+--------------+--------------+
| Class \ IP ver | IPv4 (octets)| IPv6 (octets)|
+----------------+--------------+--------------+
| STATIC | 16 +3 bits | 42 +6 bits |
| STATIC-KNOWN | 4 +1 bit | 1 +6 bits |
| CHANGING | 13.5(-73.5) | 11.5(-71.5) |
| INFERRED | 6 | 4 |
+----------------+--------------+--------------+
| Total | 40(-100) | 60(-120) |
+----------------+--------------+--------------+
Table 6.1 : size of field classes
The information carried in the STATIC fields have to be transferred
once, and the profile MUST specify a way for doing this. It also
needs to handle the CHANGING fields efficiently for their expected
change patterns. The information in INFERRED and STATIC-KNOWN fields
need not be transmitted at all. The values of INFERRED fields can be
computed from other information known to the decompressor. The values
of STATIC-KNOWN fields are implicitly defined by the compression
profile.
7. A proposed header compression profile for IP-telephony flows
This section is an example showing how the framework outlined in 5
could be instantiated for compressing the headers of an IP telephony
flow. Both IPv4 and IPv6 are covered, so this section actually
defines two profiles: one for IPv4/UDP/RTP packet streams and one for
IPv6/UDP/RTP packet streams.
7.1. Usage scenarios, environment and requirements
This profile is intended for IP-telephony over cellular links with
high error rates. The scheme is designed to successfully handle loss
of at least two consecutive packets over the link, without
introducing any additional loss. The packet streams MUST be separated
such that each packet stream has its own logical channel. The link
layer MUST provide information about the size of each packet sent
over the link. The scheme does not rely on there being a link-layer
checksum.
As a cellular link with similar characteristics is expected at the
other end of the connection, the scheme is also designed to handle
two consecutive lost packet before the compression point without
increasing the size of the compressed header. The profile is also
designed to handle reordering of single packets before the
compression point without increasing the size of compressed headers.
Jonsson, Degermark, Hannu, Svanbro [Page 14]
INTERNET-DRAFT Robust Header Compression June 22, 1999
7.2. Analysis of change patterns of header fields
To design a suitable coding for the CHANGING header fields, their
change patterns need to be analyzed. Table 7.1 summarizes the
expected change patterns of these fields.
+-------------------+--------------+--------------+--------------+
| Field \ Frequency | ~1/pkt | ~1/talkspurt | seldom |
|-------------------+--------------+--------------+--------------+
| IP Identification | X | X | X |
| IP TOS/Tr. Class | | | X |
| IP TTL/Hop Limit | | | X |
| UDP Checksum | X | | X |
| RTP Marker | | X | |
| RTP Payload Type | | | X |
| RTP Seq. Number | | | X |
| RTP Timestamp | | X | X |
| RTP CSRC | | X | X |
| Timestamp Delta | | | X |
+-------------------+--------------+--------------+--------------+
Table 7.1 : Change frequencies of CHANGING header fields
An X in the first column of Table 7.1 indicates random changes in all
or almost all packets. Column two is for rather infrequent changes,
on the order of one per talkspurt, while the third column is for very
infrequent changes. The third column is also used for changes that
are constant and predictable; an example would be the RTP sequence
number which will increment by one for each packet.
Table 7.1 does not consider changes caused by loss or reordering
before the compression point. Such problems are dealt with by the
mechanisms in section 7.4. The following subsections discusses the
various header fields in detail.
7.2.1. IP Identification
The Identification field (IP ID) of the IPv4 header is there to
identify which fragments constitute the same datagram when
reassembling fragmented datagrams. The IPv4 specification does not
specify exactly how this field is to be assigned values, only that
each packet should get an IP ID that is unique for the source-
destination pair and protocol for the time the datagram (or any of
its fragments) could be alive in the network. This means that
assignment of IP ID values can be done in various ways, which we have
separated into three classes.
Jonsson, Degermark, Hannu, Svanbro [Page 15]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Sequential
This assignment policy keeps a separate counter for each outgoing
flow and thus the IP ID value will increment by one for each
packet. When RTP is used on top of UDP and IP, this means that
the IP ID value would follow the RTP sequence number. The change
pattern corresponds to column three of Table 7.1.
Random
Some IP stacks assign IP ID values using a pseudo-random number
generator. There is thus no correlation between the ID values of
subsequent datagrams. Therefore there is no way to predict the IP
ID value for the next datagram. For header compression purposes,
this means that the IP ID field needs to be sent uncompressed
with each datagram, resulting in two extra octets of header. IP
stacks in cellular terminals SHOULD NOT use this IP ID assignment
policy. The change pattern corresponds to column one of Table
7.1.
Sequential jump
This class originates from IP stacks that that do sequential
assignment of IP ID values, and uses the same counter for all
connections. When the sender is involved in more than one
communication simultaneously, the IP ID can increase by more than
one. An RTP mixer might originate packet streams with this
behavior. The IP ID values will be much more predictable and
require less bits to transfer than random values, and the packet-
to-packet increment (determined by the number of active outgoing
flows) will usually be limited. The change pattern is less easily
handled than the purely Sequential pattern. This change pattern
corresponds to column two of Table 7.1.
This profile is designed to handle sequential IP ID fields. Modified
profiles are required if the behavior is different. Designers of
IP stacks for cellular terminals SHOULD use the Sequential policy.
7.2.2. IP Type-Of-Service / Traffic-Class
The TOS (IPv4) or Traffic Class (IPv6) field is expected to be
constant during the lifetime of a packet stream or to change
relatively seldom, corresponding to column three of Table 7.1. If
changes are frequent, a different profile might be advisable.
Jonsson, Degermark, Hannu, Svanbro [Page 16]
INTERNET-DRAFT Robust Header Compression June 22, 1999
7.2.3. IP Time-To-Live / Hop Limit
The TTL (IPv4) or Hop Limit (IPv6) field is expected to be constant
during the lifetime of a packet stream or to change infrequently
between a limited number of values, therefore it corresponds to
column three of table 7.1.
7.2.4. UDP Checksum
The UDP checksum is optional. If disabled, it corresponds to column
three of Table 7.1 because its value is constant (zero). If enabled,
its value depends on the payload which for compression purposes will
be equivalent to it changing randomly with every packet. Therefore it
belongs in column one of Table 7.1.
This profile does not handle UDP checksums, i.e., it assumes that the
UDP checksum is disabled. Chapter 8 discusses ways to define profiles
for packet streams with enabled UDP checksums.
7.2.5. RTP Marker
The marker bit is assumed to be set only in the first packet of a
talkspurt, corresponding to column two of Table 7.1.
7.2.6. RTP Payload Type
Changes of the RTP payload type within a packet stream is expected to
be a rare case. Applications could adapt to congestion by changing
payload type and/or frame sizes, but that is not expected to happen
frequently. This patterns corresponds to column three of Table 7.1.
7.2.7. RTP Sequence Number
The RTP sequence number will be incremented with one for each packet.
This corresponds to column 3 of Table 7.1.
7.2.8. RTP Timestamp
As long as there are no pauses in the audio stream, the RTP timestamp
will be incremented with a constant value, corresponding to the
number of samples in the (constant size) speech frame. It will thus
follow the RTP sequence number. This corresponds to column three of
Table 7.1. When there has been a silent period and a new talkspurt
begins, the timestamp will jump in proportion to the length of the
silent period. Those cases correspond to column two of Table 7.1.
Jonsson, Degermark, Hannu, Svanbro [Page 17]
INTERNET-DRAFT Robust Header Compression June 22, 1999
7.2.9. RTP Contributing Sources (CSRC)
The participants of a session, which are identified by the CSRC
fields, are expected to be almost the same on a packet-to-packet
basis with relatively additions or removals. Therefore the occurrence
in column two of Table 7.1. For two-part conversations where no CSRC
is present the behavior corresponds to column three of Table 7.1.
7.2.10. RTP Timestamp delta
The RTP timestamp will be incremented with a constant value (the
timestamp delta) for each packet received as long as the time per
speech frame is constant. Changes of the timestamp delta is expected
to be rare, and correspond to column three of Table 7.1.
7.3. Packet types and code field usage
The scheme makes use of four different packet types; STATIC,
CONTEXT_UPDATE, COMPRESSED and CONTEXT_REQUEST. Detailed descriptions
of packet formats are given in chapter 7.5.
The Code field is used to distinguish between packet types. Four code
points in the Code field are reserved to identify STATIC,
CONTEXT_UPDATE and CONTEXT_REQUEST packets while all other
combinations are used for COMPRESSED packets. The reserved patterns
are:
STATIC 000000
CONTEXT_UPDATE 000001
CONTEXT_REQUEST 11111-
For other values of the Code field, its format is as shown below.
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| Code | -> | S-Code |X|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
S-Code Sequence code. 5 bits. An encoding of RTP sequence number
changes for the actual and some previous packets.
Its semantics is specified in 7.4.
X E(X)tension bit. X=1 indicates that an extension is
present. X=0 indicates that there is no extension.
Extensions are defined in section 7.5.
Jonsson, Degermark, Hannu, Svanbro [Page 18]
INTERNET-DRAFT Robust Header Compression June 22, 1999
7.4. Robust encoding and decoding of delta information
The analysis in section 7.2 excluded changes due to loss and/or
reordering before the header compression point. Such changes will
have an impact on the regularity of the RTP sequence number, RTP
timestamp value and, for IPv4, the IP ID value. However, as described
in 7.2, both the RTP timestamp and the IP ID value are expected to
follow the RTP sequence number for most packets. The task is then to
communicate RTP sequence number changes in a way that tolerates two
consecutive lost packets on the link between compressor and
decompressor. This chapter describes how to do this by using the 5-
bit S-Code.
7.4.1. Sequence number changes to handle
The source increases the RTP sequence number with one for each packet
sent. However, due to losses and reordering the changes seen by the
compressor will vary. If we consider our scenario in Figure 1.1 where
there are cellular links at both ends of the path, it seems
reasonable to set the same algorithm requirements for loss on the
cellular link at the other end. This implies that two consecutive
packets could be lost. Loss on the wired portion of the path is
assumed to be insignificant in comparison, so the maximal number of
lost packets to be handled efficiently is two also before the header
compression point. An example of possible sequence number changes
seen by the compressor would then be as shown in Figure 7.1.
From sender : 1 2 3 4 5 6 7 8 9 10
Lost on path : X X X X X
Received by HC : 1 4 5 7 10
Sequence delta : - 3 1 2 3
Figure 7.1: possible sequence number changes.
Possible sequence delta value for loss are then: 1, 2 or 3
Packet reordering is uncommon, but should also be handled as long as
it is single reordering (one packet arrives "early"). This requires
one extra possible sequence delta, -1.
The sequence deltas to handle are thus: -1, 1, 2 and 3. When packets
are duplicated in the network, the delta can be 0 (zero). We do not
deal with such deltas because duplicated packets should not be sent
over the cellular link; they should be discarded.
7.4.2. Compression of sequence number values
Jonsson, Degermark, Hannu, Svanbro [Page 19]
INTERNET-DRAFT Robust Header Compression June 22, 1999
The sequence number encoding is based on two values called Individual
Delta (ID) and Accumulated Delta (AD). These two are further encoded
to one value to send in the header, called Encoded Delta (ED). The
values are calculated as follows.
ID: The Individual Delta is the sequence number delta from the
previous packet sent from the compressor. The value can be -1,
1, 2 or 3.
AD: The Accumulated Delta is a sum of the Individual Delta values of
the two previous packets sent from the compressor. The possible
values of AD will then be 0, 1, 2, 3, 4, 5 and 6.
ED: ID and AD are mapped to a single value, ED, as described in
Appendix B. The ED value is then sent in the S-code field of
each COMPRESSED packet.
The purpose of transmitting the encoded delta values is to make it
possible to recover from packet loss between compressor and
decompressor.
7.4.3. Decompression of RTP sequence number values
The decompressor makes attempts to decompress based on assumptions on
the number of lost packets between compressor and decompressor since
the last packet received and successfully decompressed. For each
attempt the header is reconstructed according to the assumed number
of lost packets, and the correctness is verified with the Header
Compression CRC. To reconstruct the header the ID and AD values are
used to calculate the sequence number corresponding to the attempt.
The decompressor needs a short history of previous IDs, ADs and RTP
sequence numbers to do this. The details of the algorithm is
explained in the following:
Let the decompressor keep an imaginary counter of the packets
received and let N be the number of the current packet. S(N) is the
calculated RTP sequence number for packet N. The attempts are made in
the following order:
Attempt 1 - No loss : S(N) = S(N-1) + ID(N)
Attempt 2 - One lost : S(N) = S(N-1) + ID(N) + AD(N) - ID(N-1)
Attempt 3 - Two lost : S(N) = S(N-1) + ID(N) + AD(N)
If attempt 3 fails, more than two previous consecutive packets must
have been lost between compressor and decompressor and the
decompression is not guaranteed to succeed. A decompressor may make
additional repair attempts. A CONTEXT_REQUEST MUST be sent to the
Jonsson, Degermark, Hannu, Svanbro [Page 20]
INTERNET-DRAFT Robust Header Compression June 22, 1999
compressor to request an update to repair the context if the repair
fails.
7.5. Header formats
This section defines the header formats of the four packet types
together with descriptions of when and how to use them.
7.5.1. Static information packet, initialization
The STATIC packet type is a packet containing no payload but only the
header fields that are expected to be constant within the lifetime of
the flow (classified as STATIC in chapter 6). A packet of this kind
MUST be sent once as the first packet from compressor to decompressor
and also when requested by decompressor (see 7.5.4). The packet
format is shown below for IPv6 and IPv4, respectively.
IPv6 (45 octets)
1 1 2 2 3
0 7 8 5 6 3 4 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Compr. CRC |0 0 0 0 0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Label |P|E| * |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S S R C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jonsson, Degermark, Hannu, Svanbro [Page 21]
INTERNET-DRAFT Robust Header Compression June 22, 1999
IPv4 (19 octets)
1 1 2 2 3
0 7 8 5 6 3 4 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Compr. CRC |0 0 0 0 0|0|F|P|E| * |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S S R C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For this packet type, the Header Compression CRC is calculated over
the entire packet, except the Header Compression CRC field, and is
used at the decompressor side to verify the correctness of the
packet. All other fields except the code (000000) and the unused (*)
are the ordinary IP, UDP and RTP fields (F=IPv4 May Fragment, P=RTP
Padding, E=RTP Extension).
Only one STATIC packet is sent at each occasion. If the decompressor
receives compressed headers or updates without having received a
STATIC packet, the decompressor MUST request a STATIC packet.
7.5.2. Context update packet
The CONTEXT_UPDATE packet type has a header containing all changing
header fields in their original, uncompressed form, and carries a
payload just as ordinary COMPRESSED packets. A CONTEXT_UPDATE packet
is sent after the initial STATIC packet to set up the decompressor
context for the first time. In addition, this packet type is used
whenever the decompressor requests a context, and when the header
fields change in a way that cannot be encoded in COMPRESSED packets.
The header format is shown below for IPv6 and IPv4, respectively.
Jonsson, Degermark, Hannu, Svanbro [Page 22]
INTERNET-DRAFT Robust Header Compression June 22, 1999
IPv6 (13 octets + CSRC List of 0-60 octets)
1 1 2 2 3
0 7 8 5 6 3 4 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Compr. CRC |0 0 0 0 0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Class | Hop Limit |M| Payload Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Delta | CSRC | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CSRC List :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 (15 octets + CSRC List of 0-60 octets)
1 1 2 2 3
0 7 8 5 6 3 4 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Compr. CRC |0 0 0 0 0|1| TOS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification | TTL |M| Payload Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Delta | CSRC | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CSRC List :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For this packet type, the Header Compression CRC is calculated over
the original packet header only. All fields except the code (000001)
and the Timestamp Delta are the ordinary IP, UDP and RTP fields. The
Timestamp Delta is the current delta between RTP timestamps in
consecutive RTP packets.
Each time a CONTEXT_UPDATE packet is sent, the two subsequent packets
MUST also be CONTEXT UPDATE packets. This ensures that the update
will succeed even when two consecutive packets are lost.
Jonsson, Degermark, Hannu, Svanbro [Page 23]
INTERNET-DRAFT Robust Header Compression June 22, 1999
7.5.3. Compressed packets
The COMPRESSED packet type is the most commonly used one and is
created to handle ordinary changes as efficiently as possible. When
changes are regular, all information is carried in the base header,
with only the Header Compression CRC and the Sequence Code. The
header of a COMPRESSED packet has the following format.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Compr. CRC | S-Code |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Header Compression CRC is computed over the original packet
header. Neither the S-Code nor the extension bit is included in the
checksum computation.
Less regular changes of the header fields require an extension in
addition to the base header. The extension is of variable size
depending on what information needs to be transmitted. When there is
an extension present in the COMPRESSED packet, it is indicated by the
extension bit being set. The header will then have the format shown
below and will include at least one extra octet of data.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
| Header Compr. CRC | S-Code |1| Type| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
The first three bits of the extension is the Type field which
specifies which kind of extension is present. This profile defines
six extension types. The guiding principle for choosing extension
types is to find the smallest header type that can communicate the
information needed.
The extension can carry an M-field, a TS LSB field, and an Extra
field. The M-field is the RTP marker bit and the TS LSB is the least
significant bits of the timestamp value (the most significant bits
are then expected to be unchanged since previous packets). The Extra
field contains four bits indicating the presence of up to four
additional header fields.
The defined extension types are shown below:
1 2
6 7 8 9 0 1 2 3
- - +-+-+-+-+-+-+-+-+
Type 0 |0 0 0|M| TS LSB|
- - +-+-+-+-+-+-+-+-+
Jonsson, Degermark, Hannu, Svanbro [Page 24]
INTERNET-DRAFT Robust Header Compression June 22, 1999
1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 |0 0 1|M| TS LSB |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2 |0 1 0|M| TS LSB |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2
6 7 8 9 0 1 2 3
- - +-+-+-+-+-+-+-+-+ - -
Type 3 |0 1 1|M| Extra |
- - +-+-+-+-+-+-+-+-+ - -
1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
Type 4 |1 0 0|M| Extra | TS LSB |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
Type 5 |1 0 1|M| Extra | TS LSB |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
The Extra field is a bit mask indicating which additional header
fields are present. The bit mapping of the Extra field is shown below
followed by a description of the various additional fields.
- - +-+-+-+-+ - - - - +-+-+-+-+ - -
| Extra | -> |T H C D|
- - +-+-+-+-+ - - - - +-+-+-+-+ - -
T - Traffic Class / TOS
H - Hop Limit / TTL
C - CSRC
D - Timestamp Delta
Jonsson, Degermark, Hannu, Svanbro [Page 25]
INTERNET-DRAFT Robust Header Compression June 22, 1999
The Traffic Class / TOS field contains the data of the original
header field:
8 bits
- - +-+-+-+-+-+-+-+-+ - -
| TC / TOS |
- - +-+-+-+-+-+-+-+-+ - -
The Hop Limit / TTL field contains the value of the original header
field:
8 bits
- - +-+-+-+-+-+-+-+-+ - -
| HL / TTL |
- - +-+-+-+-+-+-+-+-+ - -
The CSRC field is built up of:
- a counter of the number of CSRC items present (4 bits)
- an unused field (4 bits)
- the CSRC items, 1 to 15 (4-60 octets)
1 octet + 4 to 60 octets
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+
| Count | Unused| CSRC Items |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+
The Timestamp Delta field is a one octet field. We want to
communicate Timestamp Delta values corresponding to 80 ms. Therefore
the Timestamp Delta value communicated is not the actual number of
samples, but instead the number of samples divided by 8. Thus, only
Timestamp Delta values evenly divisible by 8 can be communicated in a
Timestamp Delta field in an extension. On the other hand the maximum
value is 255*8 = 2040 (255 ms at 8000 Hz). Delta values larger than
2040 or delta values not evenly divisible by 8 must be communicated
in a CONTEXT UPDATE packet.
8 bits
- - +-+-+-+-+-+-+-+-+ - -
|Timestamp Delta|
- - +-+-+-+-+-+-+-+-+ - -
The fields present are appended to the extension in order T-H-C-D. An
example where the HL/TTL and the Timestamp Delta fields are present
in a type 3 extension is shown below. When the Timestamp Delta field
is present the RTP Marker will probably also be set, which is the
case in this example.
Jonsson, Degermark, Hannu, Svanbro [Page 26]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Type M Extra
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
|0 1 1|1|0 1 0 1| HL / TTL |Timestamp Delta|
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
When information of any kind is sent in an extension, the
corresponding information has to be sent also in two subsequent
packets (either as Extensions or CONTEXT UPDATES) to satisfy the two-
packet-loss requirement.
7.5.4. Context request packet
The CONTEXT_REQUEST packet is used by the decompressor to request a
context update from the compressor. This is done when the context of
the decompressor is not valid or not in sync and decompression
therefore is impossible. The main reasons for an invalid context at
the decompressor are:
- The context initialization failed.
- The context has been brought out of sync due to errors on the link
and the context repair mechanisms have failed.
To set up the context in the first place, a STATIC packet has to
arrive to the decompressor to install the static parts of the
context. Then a CONTEXT_UPDATE packet is needed to install the
CHANGING parts of the header plus flow related information.
COMPRESSED packets can be handled only after both these packets have
been received successfully.
There are two kinds of CONTEXT_REQUEST packets. The first kind is
used to request a new STATIC packet and is normally sent only if the
first STATIC packet was lost or damaged and other packets arrive. The
format of this STATIC_REQUEST packet is shown below.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STATIC_CONTEXT REQUEST | Header Compr. CRC |1 1 1 1 1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The other kind of CONTEXT_REQUEST requests a CONTEXT_UPDATE packet
and is sent whenever COMPRESSED packets arrives but the decompressor
fails to decompress them. The format of this UPDATE_REQUEST packet is
shown below.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UPDATE_CONTEXT REQUEST | Header Compr. CRC |1 1 1 1 1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jonsson, Degermark, Hannu, Svanbro [Page 27]
INTERNET-DRAFT Robust Header Compression June 22, 1999
8. UDP checksum
The profile described in section 7 does not handle packet streams
with the 16-bit UDP checksum enabled. The main argument for making
this assumption about IP-telephony flows over cellular links is that
speech decoders developed for cellular links usually prefer to have
damaged packets delivered rather than discarded.
If the UDP checksum is enabled its value will not be zero. The packet
stream will then most likely have the UDP checksum enabled in all
packets. A profile should then be used that can transfer the UDP
checksum.
Applications which have enabled the UDP checksum are presumably
interested in its end-to-end semantics and it is therefore important
to maintain its semantics across the link. The interesting property
of the UDP checksum is that it provides a way for the receiver to
determine whether the packet has been damaged on its way through the
network. It is not necessary to maintain the exact value of the UDP
checksum as long as it reliably provides the packet-is-damaged
information to the receiver.
There are at least three ways to define a compression profile that
can handle the UDP checksum:
1. The UDP checksum is included as-is in all packets that carry
payloads. That will obviously provide and maintain packet-is-
damaged information but will increase the header size by two
octets.
2. The UDP checksum can be replaced by a separate checksum which
covers the payload only (this saves bits compared to case 1
only if the separate checksum is smaller than 16 bits).
Together with a bit that indicates whether the UDP checksum
succeeded before compression, it is easy for the decompressor
to construct a UDP checksum that provides and maintains
packet-is-damaged information.
3. The UDP checksum can be substituted with a single bit that
indicates whether it succeeded or failed before compression.
Together with information on whether a link layer checksum
succeeded or not, a UDP checksum that provides and maintains
packet-is-damaged information can be constructed by the
decompressor.
Case 2 should be used only if there is no link layer checksum. If
there is, case 3 should be used instead. Case 3 depends on there
being a checksum in the link layer so that it is possible to
determine if the packet has been damaged.
Jonsson, Degermark, Hannu, Svanbro [Page 28]
INTERNET-DRAFT Robust Header Compression June 22, 1999
The UDP checksum is problematic for applications that send packets
where parts of the payload are insensitive to damage. Such
applications would want a transport layer checksum covering only the
parts of the packet where damage cannot be tolerated, such as the
headers. UDP is not flexible enough for such applications.
9. Supporting multiple flows
The compression profile specified in chapter 7 is intended for
environments where separation of packet streams are handled on other
levels. To support environments where multiple packet streams share a
channel, multiple contexts are needed. Compression profiles for such
environments should thus define packet formats which include context
identifiers (CIDs).
10. Link-layer considerations
The base scheme requires a framing mechanism from the link layer, but
nothing else. Neither packet type indication nor error detection in
the form of checksums are required.
A link layer framing protocol such as PPP in HDLC-like framing [HDLC]
would then not be the best choice, since it provides too much
functionality and uses precious bits to do so. In particular its
error protection policy, where damaged frames are discarded, is not
appropriate and would unnecessarily increase the frame-loss rate.
11. Preliminary performance results
To evaluate the performance of our ROCCO compression profile for IP
telephony, we have simulated three header compression schemes; CRTP
[CRTP], our solution, and the Ideal header compression scheme defined
in chapter 2. Sections 11.1 to 11.5 provides the parameters used in
the simulations. Sections 11.6 and 11.7 show the results.
11.1. Simulated scenario
A source generates RTP packets which are sent over a wired network to
an end-system where the last link is a cellular link. The RTP stream
is being compressed over the last cellular link using one of the
three header compression schemes. The simulated scenario is shown in
Figure 11.1.
Jonsson, Degermark, Hannu, Svanbro [Page 29]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Compression
Source point End-system
_____________ +-------+
/ back channel\ | |
+----+ +---+/ \+----+ |
| |--------->---------| HC|-------->--------|HD | |
+----+ Internet path +---+ Cellular link +----+ |
(loss) | |
+-------+
Figure 11.1 : Simulated scenario.
11.2. Input data
The speech source generates packets with a fixed size, 244 bits,
every 20 ms (12.2 kbps), corresponding to the GSM enhanced full-rate
speech codec. On top of these bits, there is a 12 bit application
CRC, making up a total of 256 bits (32 bytes).
The length of the talk spurts and the silent intervals between them
are both exponentially distributed with an expected length of 1
second. Silence suppression is used, meaning that no data is
transmitted during silent periods.
11.3. Influence of pre-HC links
A worst case scenario is considered. The packet loss rate is
uniformly distributed with a probability of 1 %. First degree
reordering is also uniformly distributed with a probability of 1 %.
No higher reordering degree is considered. The purpose of using high
probabilities is to test the capabilities of the schemes also under
tough conditions. The speech quality would suffer at such error
rates.
11.4. Used link layers
Two link layers are considered in the algorithm evaluation, as in
[CRTPC]. One is PPP in HDLC-like framing [HDLC], which has a 16-bit
CRC covering the entire frame. This implies that all damaged frames
are discarded at the link layer.
The second link layer used is an imaginary framing scheme called
LLPC, Link Layer with Partial Checksum. As the name implies the CRC
does not cover the whole frame. The payload (sound data) is not
covered by the CRC, which fits well with speech coders that can
conceal some damage. The partial checksum will increase the number of
headers seen by the decompressor and hence improve header compression
performance.
Jonsson, Degermark, Hannu, Svanbro [Page 30]
INTERNET-DRAFT Robust Header Compression June 22, 1999
11.4.1 PPP in HDLC-like framing (HDLC)
PPP typically uses HDLC-like framing [HDLC]. With a 16-bit checksum
and compressed Address and Control fields the frames have the
following format.
1 1 2
+----------+----------+-------------+----------+----------+
| Flag | Protocol | Information | FCS | Flag |
| 01111110 | 8 bits | * | 16 bits | 01111110 |
+----------+----------+-------------+----------+----------+
The Flag only occurs once between frames if they are sent back-to-
back, so the amortized framing overhead is 4 octets per frame. The
checksum (FCS) is calculated over the Protocol field and the
Information field (payload), but not the Flags or the checksum
itself.
Any errors anywhere in the frame will cause the FCS to fail. The
frame will then be discarded.
11.4.2 Link-layer with partial checksum (LLPC)
This is an imaginary framing scheme derived from the HDLC-format in
12.3.1 by adding a one-octet Length field.
1 1 1 2
+----------+----------+----------+-------------+---------+----------+
| Flag | Length | Protocol | Information | FCS | Flag |
| 01111110 | 8 bits | 8 bits | * | 16 bits | 01111110 |
+----------+----------+----------+-------------+---------+----------+
The Length field indicates how many octets of the payload that are
covered by the FCS. It can have values from 0 to 255. The FCS covers
the Length and Protocol field plus as many octets in the beginning of
the Information field as indicated by the Length field. The value of
the Length field must not make the FCS extend over the FCS field.
When sending a FULL_HEADER packet, the Length field would have the
value 40, since it should protect the IP, UDP, and RTP headers. When
sending a minimal COMPRESSED_RTP or ROCCO packet, the Length field
would have the value 2. The amortized framing overhead for LLPC is 5
octets per frame.
Any errors in the Flag, Length, Protocol, FCS, or the initial Length
octets of the Information field will cause the FCS to fail. The frame
will then be discarded. Errors in the Information field after the
first Length octets will not affect the FCS and will not cause the
frame to be discarded.
Jonsson, Degermark, Hannu, Svanbro [Page 31]
INTERNET-DRAFT Robust Header Compression June 22, 1999
11.5. The cellular link
The cellular link is a WCDMA channel simulated with the fading model
in [WCDMA]. The reported bit error rates, BER, are the BERs seen by
the link layer and is thus the BER after channel coding.
The back channel used in our simulations never damages the
CONTEXT_REQUEST messages. The RTT is set to 120 ms.
11.6. Compression performance
Figure 11.2 shows the average header size plotted against BERs for
the three header compression schemes using HDLC. For BERs below 1e-4,
both CRTP and ROCCO give an average header size of just over 2
octets, 2.25 for CRTP and 2.15 for ROCCO. The average header size for
CRTP starts to increase when the BER becomes higher than 1e-4 and at
BER 1e-3 it is 3.35 octets. For ROCCO the average header size is
constantly 2.15 octets up to BER 1e-3. For higher BERs it increases
slightly to reach 2.75 octets at BER 1e-2, where CRTP has an average
header size of 5.20 octets.
Figure 11.3 shows the same plots for LLPC. The average header size
for ROCCO remains constant at 2.15 octets up to a BER of 5e-3. CRTP
header size on the other hand starts to increase at BER 3e-4. The
average header size for CRTP is 2.70 octets at BER 1e-3 compared to
2.15 for ROCCO. At BER 1e-2, CRTP have an average header size of 4.20
octets, and ROCCO has 2.25 octets. The difference between CRTP and
ROCCO is mainly that the latter tolerates losing up to 2 packets
before it needs a context update packet, while CRTP needs a context
update for each loss.
Jonsson, Degermark, Hannu, Svanbro [Page 32]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Figure 11.2 : Average header sizes with HDLC
Figure 11.3 : Average header sizes with LLPC framing
Jonsson, Degermark, Hannu, Svanbro [Page 33]
INTERNET-DRAFT Robust Header Compression June 22, 1999
11.7. Robustness results
A packet is regarded as lost if it is not passed up to the
application (speech codec), meaning that a packet with errors in the
payload for LLPC is not regarded as lost, if it is deemed ok by the
header compression scheme.
In Figure 11.4 the FER for HDLC is shown for the three header
compression schemes. At BER 1e-4 we have for CRTP 0.78 % FER, ROCCO
0.18 % and ideal HC gives 0.14 % FER. Increasing the BER to 1e-3,
CRTP gives 16.56 % FER, ROCCO 3.69 % and ideal HC 3.36 % FER.
Figure 11.5 shows the FER for LLPC. ROCCO and ideal HC have a FER of
0.98 % and 0.69 %, respectively, while CRTP has a FER of 5.27 %.
Given the performance of the ideal scheme, it is clear that most of
the CRTP loss is due to context damage. ROCCO is close to the ideal
scheme until the BER is high enough making the link lose more than 2
packets in a row.
Figure 11.4 : Packet loss rate versus BER with HDLC framing
Jonsson, Degermark, Hannu, Svanbro [Page 34]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Figure 11.5 : Packet loss rate versus BER with LLPC framing
Figures 11.6 and 11.7 show the loss pattern for CRTP and ROCCO with
HDLC and LLPC at BER 1e-3. It is evident from these figures that the
majority of loss events with CRTP are such that around 7 consecutive
frames are lost. The link roundtrip time in these simulation were 120
ms and the packet rate 50 packets per second, which means that a
single discarded frame causes 6 additional frames to be lost due to
context damage. For ROCCO almost all loss events include 1 or 2 lost
frames, which means that it does not suffer from context damage.
Jonsson, Degermark, Hannu, Svanbro [Page 35]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Figure 11.6 : Packet loss patterns for CRTP and ROCCO with HDLC
Figure 11.7 : Packet loss patterns for CRTP and ROCCO with LLPC
Jonsson, Degermark, Hannu, Svanbro [Page 36]
INTERNET-DRAFT Robust Header Compression June 22, 1999
11.8. CRC strength considerations
The 10 bits of CRC is used to verify guesses about the original
header. The only header fields which have some bits that are changing
between guesses are the IP identification, RTP sequence number and
RTP timestamp. More than 300,000 different combinations of these
fields have gone through a CRC calculation without letting any
erroneous packets through. That represents about 7 minutes of speech
activity and argues therefore that 10 bits of CRC is enough to verify
the correctness of the guessed header.
12. Conclusions
This document specifies a framework for header compression over lossy
links based on checksums and local repairs: ROCCO. It also defines a
compression profile suited for compression of RTP/UDP/IP headers in
IP telephony flows.
The compression profile is evaluated by simulations over cellular
links with high but not unrealistic error rates. Its performance is
excellent and very close to the performance of an ideal header
compression scheme. Compared to CRTP, the packet loss rate of ROCCO
is around 4-6 times less over links with high error rates. Moreover,
it does not, as does CRTP, introduce loss events involving many
packets.
CRTP on the other hand performs well when error rates are low. It is
also general in the sense that it is not very dependent on the
properties of the RTP streams it compresses. CRTP is a good candidate
for channels with low error rates and in cases when many different
RTP streams are intermixed.
13. Intellectual property considerations
Ericsson has filed patent applications that might possibly have
technical relations to this contribution. For the avoidance of doubt,
Ericsson supports the handling of IPR issues according to RFC 2026.
Jonsson, Degermark, Hannu, Svanbro [Page 37]
INTERNET-DRAFT Robust Header Compression June 22, 1999
14. References
[UDP] Jon Postel, "User Datagram Protocol", RFC 761, August 1980.
[IPv4] Jon Postel, "Internet Protocol", RFC 791, September 1981.
[IPv6] Steven Deering, Robert Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RTP] Henning Schulzrinne, Stephen Casner, Ron Frederick, Van
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[HDLC] William Simpson, "PPP in HDLC-like framing", RFC 1662, July
1994.
[VJHC] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[IPHC] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header
Compression", RFC 2507, February 1999.
[CRTP] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999.
[PPPHC] Mathias Engan, Steven Casner, Carsten Bormann, "IP Header
Compression over PPP", RFC 2509, February 1999.
[CRTPC] Mikael Degermark, Hans Hannu, Lars-Erik Jonsson, Krister
Svanbro, "CRTP over cellular radio links", Internet Draft
(work in progress), June 1999.
<draft-degermark-crtp-cellular-00.txt>
[CELL] Lars Westberg, Morgan Lindqvist, "Realtime traffic over
cellular access networks", Internet Draft (work in
progress), June 1999.
<draft-westberg-realtime-cellular-00.txt>
[WCDMA] "Procedure for Evaluation of Transmission Technologies for
FPLMTS", ITU-R TG8-1,8-1/TEMP/233-E, September 1995.
Jonsson, Degermark, Hannu, Svanbro [Page 38]
INTERNET-DRAFT Robust Header Compression June 22, 1999
15. AuthorsÆ addresses
Lars-Erik Jonsson Tel: +46 920 20 21 07
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 Mobile: +46 70 365 20 58
SE-971 28 Lulea, Sweden EMail: lars-erik.jonsson@ericsson.com
Mikael Degermark Tel: +46 920 911 88
Dept of CS & EE Fax: +46 920 728 01
Lulea University of Technology Moblie: +46 70 833 89 33
SE-971 87 Lulea EMail: micke@sm.luth.se
Hans Hannu Tel: +46 920 20 21 84
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 Mobile: +46 70 378 04 73
SE-971 28 Lulea, Sweden EMail: hans.hannu@lu.erisoft.se
Krister Svanbro Tel: +46 920 20 20 77
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 Mobile: +46 70 531 25 08
SE-971 28 Lulea, Sweden EMail: krister.svanbro@lu.erisoft.se
Jonsson, Degermark, Hannu, Svanbro [Page 39]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Appendix A. Detailed classification of header fields
(According to chapter 7)
A.1. IPv4 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC-KNOWN |
| Header Length | 4 | STATIC-KNOWN |
| Type Of Service | 8 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag | 1 | STATIC-KNOWN |
| May fragment flag | 1 | STATIC |
| Last fragment flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC-KNOWN |
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC |
| Destination Address | 32 | STATIC |
+---------------------+-------------+----------------+
Summarizing the bits corresponding to the classes gives:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| STATIC | 8 +1 bit |
| STATIC-KNOWN | 3 +7 bits |
| CHANGING | 4 |
| INFERRED | 4 |
+--------------+--------------+
A.2. IPv6 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC-KNOWN |
| Traffic Class | 8 | CHANGING |
| Flow Label | 20 | STATIC |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC-KNOWN |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC |
| Destination Address | 128 | STATIC |
+---------------------+-------------+----------------+
Jonsson, Degermark, Hannu, Svanbro [Page 40]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Summarizing the bits corresponding to the classes gives:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| STATIC | 34.5 |
| STATIC-KNOWN | 1.5 |
| CHANGING | 2 |
| INFERRED | 2 |
+--------------+--------------+
A.3. UDP header fields
+------------------+-------------+-------------+
| Field | Size (bits) | Class |
+------------------+-------------+-------------+
| Source Port | 16 | STATIC |
| Destination Port | 16 | STATIC |
| Length | 16 | INFERRED |
| Checksum | 16 | CHANGING |
+------------------+-------------+-------------+
Summarizing the bits corresponding to the classes gives:
+----------+--------------+
| Class | Size (octets)|
+----------+--------------+
| STATIC | 4 |
| CHANGING | 2 |
| INFERRED | 2 |
+----------+--------------+
A.4. RTP header fields
+-----------------+-------------+----------------+
| Field | Size (bits) | Class |
+-----------------+-------------+----------------+
| Version | 2 | STATIC-KNOWN |
| Padding | 1 | STATIC |
| Extension | 1 | STATIC |
| CSRC Counter | 4 | CHANGING |
| Marker | 1 | CHANGING |
| Payload Type | 7 | CHANGING |
| Sequence Number | 16 | CHANGING |
| Timestamp | 32 | CHANGING |
| SSRC | 32 | STATIC |
| CSRC | 0(-480) | CHANGING |
+-----------------+-------------+----------------+
Jonsson, Degermark, Hannu, Svanbro [Page 41]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Summarizing the bits corresponding to the classes gives:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| STATIC | 4 + 2 bits |
| STATIC-KNOWN | 2 bits |
| CHANGING | 7.5(-67.5) |
+--------------+--------------+
A.5. Summary
If we summarize this for IP/UDP/RTP we get:
+----------------+--------------+--------------+
| Class \ IP ver | IPv4 (octets)| IPv6 (octets)|
+----------------+--------------+--------------+
| STATIC | 16 +3 bits | 42 +6 bits |
| STATIC-KNOWN | 4 +1 bit | 1 +6 bits |
| CHANGING | 13.5(-73.5) | 11.5(-71.5) |
| INFERRED | 6 | 4 |
+----------------+--------------+--------------+
| Total | 40(-100) | 60(-120) |
+----------------+--------------+--------------+
Jonsson, Degermark, Hannu, Svanbro [Page 42]
INTERNET-DRAFT Robust Header Compression June 22, 1999
Appendix B. Mapping of ID and AD fields
(According to chapter 7.4.2)
The 5 bit Sequence field is defined for all bit patterns except the
ones below which are reserved.
00000
11111
This leaves 32-2=30 code points to use for an encoding of ID/AD
called ED. The number of possible ID and AD values are 4 and 7
respectively. To encode all combinations, 4x7=28 code points is
needed and they will therefore fit into the field. The encoding is
carried out as follows:
AD ID ED
-----------------------------------
0 -1 *111 00
1 -1 001 00
2 -1 010 00
3 -1 011 00
4 -1 100 00
5 -1 101 00
6 -1 110 00
0 1 000 01
1 1 001 01
2 1 010 01
3 1 011 01
4 1 100 01
5 1 101 01
6 1 110 01
0 2 000 10
1 2 001 10
2 2 010 10
3 2 011 10
4 2 100 10
5 2 101 10
6 2 110 10
0 3 000 11
1 3 001 11
2 3 010 11
3 3 011 11
4 3 100 11
5 3 101 11
6 3 110 11
The three first bits encode the AD field and the last two the ID
field except for the combination marked *, for which the encoding of
AD is changed from 000 to 111 to not infer with the reserved
patterns. Two combinations, 11101 and 11110 are not used at all.
Jonsson, Degermark, Hannu, Svanbro [Page 43]
INTERNET-DRAFT Robust Header Compression June 22, 1999
This Internet-Draft expires in December 1999.
Jonsson, Degermark, Hannu, Svanbro [Page 44]
| PAFTECH AB 2003-2026 | 2026-04-24 04:14:57 |