Network Working Group Carsten Bormann (ed.), TZI/Uni Bremen
INTERNET-DRAFT xx
Expires: December 2000 xx
Carsten Burmeister, Matsushita
Christopher Clanton, Nokia
Mikael Degermark, Lulea University
Hideaki Fukushima, Matsushita
Hans Hannu, Ericsson
Lars-Erik Jonsson, Ericsson
Rolf Hakenberg, Matsushita
Tmima Koren, Cisco
Khiem Le, Nokia
Zhigang Liu, Nokia
Akihiro Miyazaki, Matsushita
Krister Svanbro, Ericsson
Thomas Wiebke, Matsushita
Haihong Zheng, Nokia
June 29, 2000
RObust Header Compression (ROHC)
<draft-ietf-rohc-rtp-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 product of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@cdt.luth.se.
Bormann (ed.) [Page 1]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Abstract
Existing header compression schemes do not work well when used over
links with significant error rates, especially when the round-trip
time of the link is long. For many bandwidth limited links where
header compression is essential, such characteristics are common.
A header compression framework and a highly robust and efficient
header compression scheme is introduced in this document, adaptable
to the characteristics of the link over which it is used and also to
the properties of the packet streams it compresses.
Bormann (ed.) [Page 2]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Table of contents
1. Introduction..................................................4
2. Terminology...................................................6
3. Background....................................................9
3.1. Header compression fundamentals........................9
3.2. Existing header compression schemes....................9
3.3. Requirements on a new header compression scheme.......10
3.4. Classification of header fields.......................11
4. Header compression framework.................................
4.1. Operating assumptions.................................
4.2. Dynamicity............................................
4.3. Compression and decompression states..................
4.4. Different modes of operation..........................
4.5. Encoding methods......................................
4.5.1. Least Significant Bits (LSB) encoding........
4.5.2. Least Significant Part (LSP) encoding........
4.5.3. LSB or LSP encoding with extended range......
4.6. Requirements on lower layers..........................
5. The protocol.................................................
5.1. Data structures.......................................
5.1.1. Per-channel parameters.......................
5.1.2. Per-CID parameters, profiles.................
5.1.3. Contexts.....................................
5.2. Packet types..........................................
5.2.1 Packets from compressor to decompressor......
5.2.2. Feedback from decompressor to compressor.....
5.2.3. Parameters needed for mode transition........
5.3. Operation in unidirectional mode......................
5.3.1. Compressor states and logic..................
5.3.2. Decompressor states and logic................
5.4. Operation in bi-directional optimistic mode...........
5.4.1. Compressor states and logic..................
5.4.2. Decompressor states and logic................
5.5. Operation in bi-directional reliable mode.............
5.5.1. Compressor states and logic..................
5.5.2. Decompressor states and logic................
5.6. Mode transitions......................................
5.6.1. From Unidirectional to Optimistic mode.......
5.6.2. From Optimistic to Reliable mode.............
5.6.3. From Reliable to Optimistic mode.............
5.6.4. From Optimistic to Unidirectional mode.......
5.7. Packet formats
5.7.1. Static information packets, initialization...
5.7.2. Dynamic information packets..................
5.7.3. Compressed packets...........................
5.7.4. Extensions to compressed headers.............
5.7.5. Feedback packets.............................
5.8. Encoding of field values..............................
5.8.1. LSP encoding of field values.................
5.8.2. LSB encoding of field values.................
Bormann (ed.) [Page 3]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.8.3. Timer-based timestamp decompression..........
5.9. Header compression CRCs, coverage and polynomials.....
5.9.1. STATIC packet CRC............................
5.9.2. DYNAMIC packet CRC...........................
5.9.3. COMPRESSED packet CRCs.......................
6. Implementation issues........................................
6.1. Reverse decompression.................................
6.2. Pre-verification of CRCs..............................
6.3. New reconstruction attempts with LSB and LSP encoding.
7. Further work.................................................
8. Implementation status........................................
9. Security considerations......................................
10. Acknowledgements.............................................
11. Intellectual property considerations.........................
12. References...................................................
13. Authors' addresses...........................................
Appendix A. Detailed classification of header fields
A.1. General classification
A.1.1. IPv6 header fields
A.1.2. IPv4 header fields
A.1.3. UDP header fields
A.1.4. RTP header fields
A.1.5. Summary for IP/UDP/RTP
A.2. Analysis of change patterns of header fields
A.2.1. IPv4 Identification
A.2.2. IP Traffic-Class / Type-Of-Service
A.2.3. IP Hop-Limit / Time-To-Live
A.2.4. UDP Checksum
A.2.5. RTP CSRC Counter
A.2.6. RTP Marker
A.2.7. RTP Payload Type
A.2.8. RTP Sequence Number
A.2.9. RTP Timestamp
A.2.10. RTP Contributing Sources (CSRC)
A.3. Header compression strategies
A.3.1. Do not send at all
A.3.2. Transmit only initially
A.3.3. Transmit initially, update occasionally
A.3.4. Be prepared to update or send as-is
A.3.5. Guarantee continuous robustness
A.3.6. Transmit as-is in all packets
A.3.7. Establish and be prepared to update delta
(Editor's note: The TOC has not been updated.
I have marked text I consider questionable by making it italic, and
text that I think simply should be deleted by striking it through.)
Bormann (ed.) [Page 4]
INTERNET-DRAFT Robust Header Compression June 29, 2000
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 the revolutionary possibility of always being reachable with
reasonable service quality no matter where they are. However, until
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 (such as Internet telephony) has generally been low.
Today, IP telephony is gaining momentum thanks to improved technical
solutions. It seems reasonable to believe that in the years to come,
IP will become 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.
One of the scenarios 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 implemented for each
supported service over the cellular link. However, this would limit
Bormann (ed.) [Page 5]
INTERNET-DRAFT Robust Header Compression June 29, 2000
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.
Bormann (ed.) [Page 6]
INTERNET-DRAFT Robust Header Compression June 29, 2000
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. Cellular radio links have a rather high BER. In
this document BER is usually given as a probability, but one also
needs to consider the error distribution as bit errors are not
independent. In our simulations we use a channel with a certain
BER, and the error distribution is according to a realistic channel
[WCDMA].
Cellular links
Wireless links between mobile terminals and base stations. The BER
and the RTT are rather high in order to achieve an efficient system
overall.
Compression efficiency
The performance of a header compression scheme can be described
with three parameters, compression efficiency, robustness and
compression reliability. The compression efficiency is determined
by how much the header sizes are reduced by the compression scheme.
Compression reliability
The performance of a header compression scheme can be described
with three parameters, compression efficiency, robustness and
compression reliability. The compression reliability is a measure
for how well the scheme ensures that the decompressed headers are
not erroneous and the possibility to avoid damage propagation from
the decompressor.
Context
The context is the state which the compressor uses to compress a
header and which the decompressor uses to decompress a header. The
context basically contains the uncompressed version of the last
header sent (compressor) or received (decompressor) over the link,
except for fields in the header that are included "as-is" in
compressed headers or can be inferred from, e.g., the size of the
link-level frame. The context can also contain additional
information describing the packet stream, for example the typical
inter-packet increase in sequence numbers or timestamps.
Bormann (ed.) [Page 7]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Context damage
When the context of the decompressor is not consistent with the
context of the compressor, header decompression will fail. This
situation can occur when the context of the decompressor has not
been initialized properly or when packets have been lost or damaged
between compressor and decompressor. Packets which cannot be
decompressed due to inconsistent contexts are said to be lost due
to context damage. Packets that are incorrectly reconstructed due
to context damage are said to have suffered damage propagation.
Context repair mechanism
To avoid excessive context damage, a context repair mechanism is
needed. Context repair mechanisms can be based on explicit requests
for context updates, periodic updates sent by the compressor, or
methods for local repair at the decompressor side.
FER
Frame Error Rate. The FER considered in this document includes the
frames lost on the channel between compressor and decompressor and
frames lost due to context damage. FER is here defined to be
identical to packet loss rate.
(Editor: A much better definition would be to reserve FER for the
error rate we get from lower layers and use PER for the error rate
we generate/hand up.)
Header compression profile
A header compression profile is a specification of how to compress
the headers of a certain kind of packet stream over a certain kind
of link. Compression profiles provide the details of the header
compression framework introduced in this document. The profile
concept makes use of profile identifiers to separate different
profiles which are used when setting up the compression scheme. All
variations and parameters of the header compression scheme are
handled by different profile identifiers, which makes the number of
profiles rather large. This can act as a deterrent when first
studying the concept, but is a real strength for several reasons.
One advantage of this merging of parameters into one is that new
parameters can be added by the endpoints without affecting the
negotiation requirements on the link in between. Another benefit of
the concept is that different combinations of functionality might
be implemented with different methods, meaning that the scheme can
be optimized regardless of what functionality is enabled. Finally,
it should be noted that even if there are a large number of
profiles, only a small number of them can/will be implemented over
a specific link (IPv4 and IPv6 profiles will for example probably
Bormann (ed.) [Page 8]
INTERNET-DRAFT Robust Header Compression June 29, 2000
not coexist). Most profiles usable in a certain environment will
probably also be almost identical from an implementation point of
view.
Header compression CRC
A CRC (Cyclic Redundancy Checksum) computed by the compressor and
included in each compressed header. Its main purpose is to provide
a way for the decompressor to reliably verify the correctness of
reconstructed headers. What values the CRC is computed over depends
on the packet type it is included in; typically it covers most of
the original header fields.
Pre-HC links
Pre-HC links are all links a packet has traversed before the header
compression point. If we consider a path with cellular links as
first and last hops, the Pre-HC links for the compressor at the
last link are the first cellular link plus the wired links in
between.
Robustness
The performance of a header compression scheme can be described
with three parameters, compression efficiency, robustness and
compression reliability. A robust scheme tolerates errors on the
link over which header compression takes place without losing
additional packets, introducing additional errors, or using more
bandwidth.
RTT
Round Trip Time - The time it takes to send a packet back and forth
over the link.
Simplex link
A simplex (or unidirectional) link is a point to point link without
a return channel. Over simplex links, header compression must rely
on periodic refreshes since feedback from the decompressor can not
be sent to the compressor. For simplex links, a header compression
CRC is mandatory to guarantee correct decompression.
Spectrum efficiency
Radio resources are limited and expensive. Therefore they must be
used efficiently to make the system economically feasible. In
cellular systems this is achieved by maximizing the number of users
served within each cell, while the quality of the provided services
is kept at an acceptable level. A consequence of efficient spectrum
Bormann (ed.) [Page 9]
INTERNET-DRAFT Robust Header Compression June 29, 2000
use is a high rate of errors (frame loss and residual bit errors),
even after channel coding with error correction.
Timestamp delta
The timestamp delta is the increase in the timestamp value between
two consecutive packets.
Bormann (ed.) [Page 10]
INTERNET-DRAFT Robust Header Compression June 29, 2000
3. Background
This chapter provides a background to the subject of header
compression. The fundamental ideas are described together with
descriptions of existing header compression schemes, their drawbacks
and requirements and motivation for new header compression solutions.
3.1. Header compression fundamentals
The main reason why header compression can be done at all is the fact
that there is lots of redundancy between header fields, both within
the same packet header but especially between consecutive packets
belonging to the same packet stream. By sending static field
information only initially and utilizing dependencies and
predictability for other fields, the header size can be significantly
reduced for most packets.
In general, header compression methods maintain a context, which is
essentially the uncompressed version of the last header sent over
the link, at both compressor and decompressor. Compression and
decompression are done relative to the context. When compressed
headers carry differences from the previous header, each compressed
header will update the context of the decompressor. In this case,
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 into sync, after such events.
3.2. 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 octets.
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 octets of 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 UDP/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.
Bormann (ed.) [Page 11]
INTERNET-DRAFT Robust Header Compression June 29, 2000
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 ideally for a lossy cellular
link. It is clear that CRTP alone is not a viable header compression
scheme for cellular links.
To avoid losing packets 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 has
got 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 with TWICE, CRTP
doubled the number of lost packets. TWICE improves CRTP performance
significantly. However, there are several problems with using TWICE:
1) It becomes mandatory to use the UDP checksum:
- the minimal 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 occurs 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 to succeed.
3.3. Requirements on a new header compression scheme
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
Bormann (ed.) [Page 12]
INTERNET-DRAFT Robust Header Compression June 29, 2000
size; a larger header would make IP telephony over cellular links
economically unattractive.
A major cause of the bad performance of CRTP over cellular links is
the long link roundtrip time, during which many packets are lost when
the context is out of sync. This problem can be attacked directly by
finding ways to reduce the link roundtrip time. Future generations of
cellular technologies may indeed achieve lower link roundtrip times.
However, these 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 infeasible [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.
A detailed description of the requirements specified for ROHC may be
found in [REQ].
3.4. Classification of header fields
As mentioned earlier, header compression is possible due to the fact
that there is much redundancy between header field values within
packets, but especially between consecutive packets. To utilize these
properties for header compression, it is important to understand the
behavior of the various header fields. To do this, all header fields
have been classified in detail in appendix A. The fields are first
classified on a high level and then some of them are studied more in
detail. Finally, the appendix concludes with recommendations about
how the various fields should be handled by header compression
algorithms. The main conclusion that can be drawn is that most of the
header fields can easily be compressed away since they are never or
seldom changing. Only 5 fields with a total size of about 10 octets
are rather difficult to compress and must be handled in a
sophisticated way by the compression scheme. Those fields are:
- IPv4 Identification (16 bits)
Bormann (ed.) [Page 13]
INTERNET-DRAFT Robust Header Compression June 29, 2000
- UDP Checksum (16 bits)
- RTP Marker (1 bit)
- RTP Sequence Number (16 bits)
- RTP Timestamp (32 bits)
It is rather obvious that these fields then will have a large impact
on how a header compression scheme is designed. More detail about
this should be found in Appendix A.
Bormann (ed.) [Page 14]
INTERNET-DRAFT Robust Header Compression June 29, 2000
4. Header compression framework
4.1. Operating assumptions
TBW
4.2. Dynamicity
TBW
4.3. Compression and decompression states
TBW: Compression and decompression states, how they interact with
each other. They must not be correlated. High level description
without transitions described.
The compressor starts in the lowest compression state and
gradually transitions to higher compression states. The general
principle is the compressor will always operate in the highest
possible compression state, under the constraint that the compressor
has sufficient confidence that the decompressor has the information
necessary to decompress a header compressed according to that state.
In the reliable mode, that confidence comes from receipt of ACKs from
the decompressor. Otherwise, that confidence comes from sending the
information a certain number of times, and, if a back channel is
available, from not receiving NAKs (negative acknowledgements).
The compressor may also transition back to a lower compression
state when necessary.
For IP/UDP/RTP compression, the three compressor states are the
Initialization/Refresh, First Order, and Second Order. A brief
description of each is given in the subsections below.
4.3.1. Initialization/Refresh (IR) State
In this state, the compressor essentially sends IR headers. The
information sent in a refresh may be static and non-static fields in
uncompressed form (full refresh), or just non-static fields in
uncompressed form (non-static refresh or dynamic refresh). The
compressor enters this state at initialization, upon request from
decompressor, or upon Refresh Time-out. The compressor leaves the IR
state when it is confident that the decompressor has correctly
received the refresh information.
Bormann (ed.) [Page 15]
INTERNET-DRAFT Robust Header Compression June 29, 2000
4.3.2. First Order (FO) State
Subsequently to the IR state, the compressor operates in the FO
state when the header stream does not conform to a uniform pattern,
or when the compressor is not confident that the decompressor has
acquired the parameters of the uniform pattern. In this state, the
compressor essentially sends FO headers. In the case of speech with
silence suppression turned on, a new talk spurt following a silence
interval will result in the RTP TS incrementing by more than the
regular TS increment. Consequently, the header stream does not
conform to the uniform pattern, and the compressor is in the FO
state. The compressor will leave this state and transition to the SO
state when the current header conforms to a string, and the
compressor is confident the decompressor has acquired the parameters
of the uniform pattern.
4.3.3. Second Order (SO) State
The compressor enters this state when the header to be compressed
belongs to a uniform pattern, and the compressor is sufficiently
confident that the decompressor has also acquired the parameters of
the uniform pattern. In the SO state, the compressor sends SO
headers, which mainly consist of a sequence number. While in the SO
state, the decompressor does a simple extrapolation based on
information it knows about the pattern of change of the header fields
and the sequence number contained in the SO header in order to
regenerate the uncompressed header. The compressor leaves this state
to go back to FO state when the header no longer conforms to the
uniform pattern.
4.4. Different modes of operation.
TBW: The difference between states and modes.
TBW: - Unidirectional mode
- Bi-directional optimistic mode
4.4.3. Bi-directional reliable mode
(Essentially Unedited Text from ACE. This is probably too long for
chapter 4.)
An ACK packet contains a sequence number that uniquely identifies
the compressed header packet that is being ACKed. ACKnowledgements
have four main functions:
Bormann (ed.) [Page 16]
INTERNET-DRAFT Robust Header Compression June 29, 2000
- To inform the compressor that Refresh information has been
received. In that case, the compressor knows that the decompressor
has acquired the information necessary to decompress FO headers.
This means the compressor can reliably transition to the next higher
compression state, the FO state. This kind of ACK is referred to as
an IR-ACK.
- To inform the compressor that FO information has been received;
in that case, the compressor knows that the decompressor has acquired
the information necessary to decompress SO headers. This means the
compressor can reliably transition to the next higher compression
state, SO state; this kind of ACK is referred to as an FO-ACK.
- To inform the compressor that a header with a specific sequence
number n has been received; in that case, the compressor knows that
the decompressor can determine the sequence number without any
ambiguity (caused, e.g., by counter wrap-around) up to header number
n + seq_cycle, where seq_cycle is the counter cycle (determined by
the number of bits, k, in the sequence number). This kind of ACK is
referred to as an SO-ACK.
- When information is sent as in-band signaling, to confirm that
the in-band signaling information has been received
The control of transition from IR to FO to SO states by ACKs
ensures that there is no context desynchronization, and therefore no
error propagation. That is, a compressed header that is not received
in error can always be correctly decompressed, because
synchronization is never lost.
Reception of ACKs by the compressor can also be used to increase
compressor header field encoding efficiency. Compression is more
efficient because the compressor just has to send the necessary
information (but no more) to ensure correct decompression of the
current header. In general, the minimal information that the
compressor needs to send depends on what information the decompressor
already knows. The information known at the decompressor is
indicated to the compressor in the decompressor's ACK transmission.
An enhancement to the acknowledgement procedure can be used to
reduce FO ACK traffic on the feedback channel; this traffic can be
quite high if there is significant round trip delay between
compressor and decompressor. In this case, several FO headers would
be sent before the compressor can receive an ACK, and normally, one
ACK would be sent by the decompressor for each FO header received.
Bormann (ed.) [Page 17]
INTERNET-DRAFT Robust Header Compression June 29, 2000
The basic idea is that whenever the decompressor receives a packet
and needs to send an ACK to the compressor, it just sends the ACK
once (or twice if there is no default 'pattern' agreed on by the
compressor and decompressor) and waits for some round trip time (as
opposed to sending ACKs in response to each, e.g., FO packet on the
feedback channel). After the round trip time, if the decompressor
can confirm that the compressor received the ACK (evidenced by
receipt of an SO packet at the decompressor), it continues normal
decompression. Otherwise, it will send the ACK again and the process
repeats.
The only potential negative to this approach is if the ACK sent by
the decompressor is lost. In that case, progression to the next
higher compression state by the compressor is delayed until the next
ACK is correctly received (at least one round trip time).
The decompressor uses as reference for decompression only those
headers which it is sufficiently confident of the correct
decompression (secure reference). A secure reference must be chosen
from the headers received with an OK CS. Until a new secure reference
is chosen, all subsequent headers are decompressed with respect to
the current secure reference. A major advantage of this approach is
that an undetected error which affects correct decompression of
header m will not affect decompression of subsequent headers. For
example, if header # 3 is an FO used as a secure reference, and
header # 5 is an SO with an undetected error, the decompression of
header # 6 will be based solely on header # 3 and not affected by
header # 5. In other words, an undetected error will affect only the
current header, just like when headers are not compressed.
4.5. Encoding methods
The analysis of header field changes in appendix A 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, the RTP timestamp value and, for IPv4, the IP ID
value. However, as described in A.2, both the RTP timestamp and the
IP ID value (if sequentially assigned) are expected to follow the RTP
sequence number for most packets. The most important task is then to
communicate RTP sequence number information in an efficient way. This
chapter describes the encoding methods used in a general way. How the
methods are applied to fields in different compressed headers is
described in the packet format chapter.
4.5.1. Least Significant Bits (LSB) encoding
Bormann (ed.) [Page 18]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A commonly used method for updating fields whose values are always
subject to small changes (usually positive) is Least Significant Bits
(LSB) encoding. For example, an increase of up to 16 could be handled
with only 4 bits with LSB encoding (if decreases are not expected).
This method is used for many different fields in the ROHC packet
headers defined in this document. If a field is labeled "<fieldname>
LSB", it means that the field contains only the least significant
bits of the corresponding original field.
4.5.2. Least Significant Part (LSP) encoding
One restriction with LSB encoding is that whole bits are needed,
meaning that only 2, 4, 8, 16, 32, ... code-points could be used. In
some cases, especially when several mechanisms are integrated for
efficiency reasons, it would be desirable to have a method that could
make use of any number of available code-points. To signal one
special event one could either use one single bit or, if the event is
not to be signaled in parallel with other information, as one bit
pattern for several bits. That would leave more bit patterns for
other usage.
Assume that we have 4 special events to signal and 5 bits available.
Taking 2 bits for these events, then there would be 3 bits (8 code-
points) left for other usage. If we instead reserved 4 of the code-
points represented by all 5 bits, there would instead be 32-4=28
code-points left for other usage. The only disadvantage would be that
the bits cannot be used for both purposes at the same time.
What would be desirable is to do LSB encoding of code-points instead
of whole bits. Therefore the method called Least Significant Part
(LSP) encoding has been introduced. LSP encoding of size (number of
code-points) M for a value N is defined as:
LSP:M(N) = N modulo M
An example showing the LSP encoding and decoding of a counter S(n)
with M code-points is used below to illustrate the LSP principle.
S'(n) is the decoded value corresponding to the original S(n) value.
With S'(n-1), we denote the last correctly decompressed value.
Input sequence: S(n)
Encoded sequence: LSP:M(S(n)) = S(n) modulo M
Decoded sequence: S'(n) = S'(n-1) - LSP:M(S'(n-1)) + LSP:M(S(n)) =
S'(n-1) - S(n-1) modulo M + S(n) modulo M
To handle modulo wrap-around, an additional verification is inserted.
If the decoded value S'(n) is smaller than S'(n-1)-R, S'(n) is
increased with M (reordering of order R is then handled with this
encoding).
Bormann (ed.) [Page 19]
INTERNET-DRAFT Robust Header Compression June 29, 2000
When applying LSP encoding, there are thus two parameters that must
be set:
M - The number of code-points to use (modulo value)
R - The reordering order to handle
A similar mechanism as for modulo wrap-around should also be used to
handle full-field wrap-around.
4.5.3. LSB or LSP encoding with extended range
If needed, it could be good to extend the range covered by the LSB or
LSP encoding. For the LSB case, it is simple to send only the next
more significant bits. For the LSP, what must be done is to rewrite
the definition of LSP so that it defines an additional parameter.
The LSP definition from previous chapter can instead be expressed as:
LSP:M(N) = N - INT:M(N)*M [ INT:M(N) = (N - LSP:M(N)) / M) ]
And in that case, INT:M(N) is the integer part left after division.
If additional bits can be transmitted to increase the range covered,
this can be done by sending the least significant bits (LSB) of this
integer part, INT:M(N). The example from previous chapter will then
change into:
Input sequence: S(n)
Encoded sequence: LSP:M(S(n)) = S(n) modulo M
INT:M(S(n)) = (S(n)-LSP:M(S(n))) / M
Decoded sequence: S'(n) = S'(n-1) - LSP:M(S'(n-1)) * M
+ LSP:M(S(n)) * M
- LSB(INT:M(S'(n-1))) * M
+ LSB(INT:M(S(n))) * M
4.5.4. VLE - Variable Length Encoding
(Editor: This needs to be renamed to _window-based LSB encoding_ or
maybe some better term.)
An alternative approach to encoding irregular changes in header
fields is to send the 'k' least significant bits of the original
header field value.
Clearly, it is desirable for the compressor to minimize this
number of bits. Due to the possible loss of packets on the channel
between compressor and decompressor (CD-CC), the compressor does not
know which packet will be used as the reference by the decompressor,
and hence, does not know how many LSBs need to be sent.
Bormann (ed.) [Page 20]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Variable Length Encoding (VLE) solves this problem. The basic
algorithm employs a 'sliding window', maintained by the compressor,
which is advanced when the compressor has sufficient confidence that
the compressor has certain information. The confidence may be
obtained by various means, e.g., an ACK from the decompressor if
operating in RPP. In the case of NRP a sliding window of fixed size,
e.g. M (described later) may be used. In either case, the value of k
determined depends on the current values in the sliding window.
Details of the operation follow below.
4.5.4.1. VLE Basics
Basic concepts of VLE are:
* The decompressor uses one of the decompressed header values as a
reference value, v_ref. The reference may be chosen by various
means- one approach might be to select only headers whose correct
reconstruction is verified by inclusion of a checksum with the
compressed header ("secure" reference).
* The compressor maintains a sliding window of the values (VSW)
which may be chosen as a reference by the decompressor. It also
maintains the maximum value (v_max) and the minimum value (v_min) of
VSW.
* When the compressor has to compress a value v, it calculates the
range r = max(|v - v_max|, |v - v_min|). The value of k needed is k
= ceiling(log2(2 * r + 1)), i.e., the compressor sends the
ceiling(log2(2 * r +1)) LSBs of v as the encoded value.
* The compressor adds v into the VSW and updates the v_min and
v_max IF the value v could potentially be used as a reference by the
decompressor.
* The decompressor chooses as the decompressed value the one that
is closest to v_ref and whose k LSB equals the compressed value that
has been received.
It is obvious that we need to move forward (or shrink) the sliding
window to prevent k from increasing too much. To do that, the
compressor only needs to know which values in VSW have been received
by the decompressor. In the case of RPP, that information is carried
in the ACKs. In the case of NRP, the VSW is moved without ACK, if
there are a maximum number of entries, 'M', already present in VSW.
M is defined in the compressor logic section and further elaborated
upon in the "Implementation Hints" appendix.
The VLE concept can be applied to RTP Timestamp, RTP Sequence
Number, IP-ID header fields, etc.
Bormann (ed.) [Page 21]
INTERNET-DRAFT Robust Header Compression June 29, 2000
4.5.4.2. One-Sided Variable Length Coding (OVLE)
The VLE encoding scheme is very general and flexible, as it can
accommodate arbitrary changes (positive, negative) from one value to
the next. When VLE is applied to a field that is monotonic (e.g.
RTP SN), there is a loss in efficiency, because k, the number of bits
is defined by the condition
(2p+1) < 2 to the kth(p=|current value-reference value|).
On the other hand, if the variation is known to be monotonic, the
required k is smaller, as it has to satisfy only
p < 2 to the kth.
One-Sided Variable Length Encoding (OVLE) is based on the idea to
use a k that satisfies the latter condition, when the field to be
compressed is monotonic (increasing or decreasing). When the field
is almost always monotonic (quasi-monotonic), OVLE compression can be
used when the field is behaving monotonically, and 'regular' VLE used
when it is not.
The savings over VLE is 1 bit, and since that saving is achieved
most of the time, it translates into a 1 bit savings in the average
overhead. Alternatively, the number of bits can be kept the same,
but the frequency of ACKs can be reduced by a factor of 2.
4.5.5. Timer-Based Compression of RTP Timestamp
(Editor: This needs to be aligned with 5.8.3!)
A useful observation is that the RTP timestamps when generated at
the source closely follow a linear pattern as a function of the time
of day clock, particularly for the case when speech is being carried
in the RTP payload.
For example, if the time interval between consecutive speech
samples is 20 msec, then the RTP time stamp of header n (generated at
time n*20 msec) = RTP time stamp of header 0 (generated at time 0) +
TS_stride * n, where TS_stride is a constant dependent on the voice
codec. In what follows, n is referred to as the 'packed' RTP TS.
Consequently, the RTP TS in headers coming into the decompressor
also follow a linear pattern as a function of time, but less closely,
due to the delay jitter between the source and the decompressor. In
normal operation (no crashes or failures), the delay jitter is
bounded, to meet the requirements of conversational real-time
traffic. Thus, it is possible for the decompressor to obtain an
approximation of the packed RTP TS of the current header (the one to
Bormann (ed.) [Page 22]
INTERNET-DRAFT Robust Header Compression June 29, 2000
be decompressed), by adding the time elapsed since a reference header
to the packed RTP TS of that reference header. The decompressor then
refines this approximation with the additional information received
in the compressed header. The compressed header carries the k least
significant bits of the packed RTP TS. The required value of k to
ensure correct decompression is a function of the jitter between the
source and decompressor. The compressor can estimate the jitter and
determine k, or alternatively it can have a fixed k,
and filter out the packets with excessive jitter. Once the
decompressor has the packed RTP TS, it can convert to the original
RTP TS.
The advantages to this approach are many:
* The size of the compressed RTP TS is constant and small. In
particular, it does NOT depend on the length of the silence interval.
This is in contrast to other RTP TS compression techniques, which
require a variable number of bits dependent on the duration of the
preceding silence interval. It is very important to be able to
efficiently compress the RTP TS, as it is one of the essential
changing fields (see Appendix A).
* No synchronization is required between the timer process and the
decompressor process.
* Robustness to errors: the partial RTP TS information in the
compressed header is self contained and only needs to be combined
with the decompressor timer to yield the full RTP TS value. Loss or
corruption of a header will not invalidate subsequent compressed
headers.
As an example, consider the scenario in which a long silence
interval has just ended, and the header compressor scheme is
preparing to send an FO header to decompressor to adjust for the
unexpected change in RTP timestamp. The compressor knows that the
packet which has just arrived is the first packet of a new talkspurt
as opposed to following a lost packet because the RTP SN increments
by only one. Note that we need not assume any special behavior of
the input to the compressor (i.e. the scheme tolerates reordering, or
more generally, non-increasing RTP timestamp behavior observed prior
to the compressor).
At the end of the silence interval, the compressor sends in the FO
compressed header the k least significant bits of
p_TS_current = (current RTP time stamp - TS0)/TS_stride.
p_TS_current is the "packed" representation of the current time;
it has granularity of TS stride, which is the RTP timestamp increment
Bormann (ed.) [Page 23]
INTERNET-DRAFT Robust Header Compression June 29, 2000
observed during e.g. a VoIP session (e.g. 160 for a 20 mS voice
codec).
TS0 is an arbitrary timestamp offset.
The compressor runs the following algorithm to determine k.
STEP 1: calculate Network_Jitter (Current_header, j) as
| (T_current - T_j) - (p_TS_current - p_TS_j) |
for all packets in a sliding window, TSW. TSW contains several
pairs (T_j, p_TS_j) of values corresponding to the packets sent that
may be used as a reference, including the last packet which was
ACKed. In the case of RPP, TWS is moved when an ACK with some
indication is received from the decompressor. In the case of NRP
mode, the TSW is moved without ACK if there are a maximum number of
entries, 'M', present in TSW. I.e., the sliding window is managed
just like for the case of VLE.
T_current is the current wall clock time at the compressor, and
T_j is the wall clock time at which the packet j in the sliding
window was received by the compressor. Both T_current and T_j are in
units of time interval (e.g. 20 ms) equivalent to TS_stride.
p_TS_current and p_TS_j are the packed RTP timestamp times of the
packets, determined from the actual RTP header.
STEP 2: compute Max_Network_Jitter, where
Max_Network_Jitter = Max{Network_Jitter(current, j)},for all
headers j in TSW
Note that Max_Network_Jitter is positive.
STEP 3: k is then calculated as
k = ceiling(log2(2 * J + 1), where
J = Max_Network_Jitter + Max_CD_CC_Jitter + 2.
Max_CD_CC_Jitter is the maximum possible CD-CC jitter expected on
the CD-CC. Such a maximum depends only on the characteristics of the
CD- CC, and is expected to be reasonably small in order to have good
quality for real-time services.
The factor + 2 is to account for the quantization error caused by
the timers at the compressor and decompressor, which can be +/- 1.
Bormann (ed.) [Page 24]
INTERNET-DRAFT Robust Header Compression June 29, 2000
4.6. Requirements on lower layers
This chapter lists general ROHC requirements on an underlying link
layer. See also the ROHC lower layer requirements document [LLG].
Framing
Framing, which makes it possible to separate different packets, is
the most important link layer functionality.
Length
Most link layers can indicate the length of the packet, and this
information has therefore been removed from the packet headers.
This means that it now MUST be given by the link layer.
Error protection
A reliable link layer CRC covering at least the header part of the
packet is assumed. The CRC SHOULD ensure that packets with errors
in the header part are never delivered.
Negotiation
In addition to the packet handling mechanisms above, the link
layer MUST also provide a way to carry on the negotiation of
header compression parameters.
Bormann (ed.) [Page 25]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5. The protocol
5.1. Data structures
5.1.1. Per-channel parameters
5.1.2. Per-CID parameters, profiles
5.1.3. Contexts
5.2. Packet types
This chapter defines the various packet types that are used by the
ROHC scheme. It also lists some parameters that are needed in the
various packet headers to carry out transition between the three
modes of operation.
5.2.1. Packets from compressor to decompressor
The ROHC scheme defines three different packet types for the
information sent from compressor to decompressor. The header formats
for these packet types may vary but their meaning will always be the
same. The three packet types defined are:
FH (Full Header) : In these packets, all information needed to
establish the decompressor context is sent.
FO (First Order) : Only a limited amount of context information is
sent in a FO packet and no STATIC information.
However, successful decompression of subsequent
packets requires that the information sent in
an FO packet is correctly transferred.
SO (Second Order) : The SO packets are small and (almost)
independent packets. Subsequent packets are not
depending on the SO packet for successful
decompression.
TBW: How these packet types are used, their relation to the three
compression states with the same names etc...
5.2.2. Feedback packets from decompressor to compressor
Bormann (ed.) [Page 26]
INTERNET-DRAFT Robust Header Compression June 29, 2000
In addition to the packet types used from compressor to decompressor,
feedback packets are also defined to use from decompressor to
compressor. The feedback packet formats may vary and there may also
be special feedback packet types defined. However, these three
feedback packet types must always be supported to control state and
mode transition:
ACK : Acknowledge a successful decompression of a packet,
which means that the context is up to date.
NACK : Indicates that decompression has failed.
STATIC-NACK : Indicates that decompression has failed due to an
invalid (or never established) STATIC context.
TBW: How these packet types are used etc...
5.2.3. Parameters needed for mode transition
TBW:
All feedback packets of the types defined above must carry the
sequence number of the packet that it corresponds to and a parameter
telling the desired compression mode to work in (U=Unidirectional,
O=Optimistic, R=Reliable).
5.3. Operation in unidirectional mode
TBW: General description of the unidirectional mode
5.3.1. Compression states and logic
Below is the state machine for the compressor in unidirectional mode.
Details of each state, the transitions between states and compression
logic is given subsequent to the figure.
Optimistic approach Optimistic approach
+------>------>------+ +------>------>------+
| | | |
| v | v
+----------+ +----------+ +----------+
| FH State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | Timeout | | Timeout / Update | |
| +------<------<------+ +------<------<------+ |
| |
Bormann (ed.) [Page 27]
INTERNET-DRAFT Robust Header Compression June 29, 2000
| Timeout |
+------<------<------<------<------<------<------<------<------+
TBW: Descriptions of timers, optimistic approach, transitions and the
packets used. Text from ROCCO draft may be reused.
5.3.2. Decompression states and logic
FH
+-->------>------>------>------>------>--+
| |
FO,SO | SO FH,FO | FH,FO,SO
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+--------------+ +----------------+ +--------------+
| No Context | | Static Context | | Full Context |
+--------------+ +----------------+ +--------------+
^ | ^ |
| Invalid decompression | | Invalid decompression |
+-----<------<------<-----+ +-----<------<------<-----+
TBW: CRC failure, repeated reconstruction's, decompressor sliding
window, timer-based decompression, transition logic
No feedback messages are sent to the compressor when working in
unidirectional mode.
5.4. Operation in bi-directional optimistic mode
TBW: Description of this mode
5.4.1. Compression states and logic
Below is the state machine for the compressor in bi-directional
optimistic mode. Details of each state, the transitions between
states and compression logic is given subsequent to the figure.
Optimistic approach / ACK
+------>------>------>------>------>------>------>------>------+
| |
| Optimistic appr. / ACK Optimistic appr. / ACK |
| +------>------>------+ +------>------>------+ |
| | | | | |
| | v | v v
Bormann (ed.) [Page 28]
INTERNET-DRAFT Robust Header Compression June 29, 2000
+----------+ +----------+ +----------+
| FH State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | STATIC-NACK | | NACK / Update | |
| +------<------<------+ +------<------<------+ |
| |
| STATIC-NACK |
+------<------<------<------<------<------<------<------<------+
TBW: Descriptions of optimistic approach, transitions and the packets
used.
5.4.2. Decompression states and logic
The decompression states and the state transition logic are the same
as for the unidirectional case (see section 5.3.2). What differs is
the feedback logic, which states what feedback messages to send due
to different events when operating in the various states.
In NC state: - When a FH packet is correctly decompressed, send an
ACK with the mode parameter set to O
- When an FO or SO packet is received or decompression
of a FH packet has failed, send a STATIC-NACK with
the mode parameter set to O
In SC state: - When a FH packet is correctly decompressed, send an
ACK with the mode parameter set to O
- When an FO packet is correctly decompressed,
optionally send an ACK with the mode parameter set to
O
- When a SO packet is received, send a NACK with the
mode parameter set to O
- When decompression of an FO or FH packet has failed,
send a STATIC-NACK with the mode parameter set to O
In FC state: - When a FH packet is correctly decompressed, send an
ACK with the mode parameter set to O
- When an FO packet is correctly decompressed,
optionally send an ACK with the mode parameter set to
O
- When an SO packet is correctly decompressed, no
feedback should be sent
- When decompression of an SO, FO or FH packet has
failed, send a NACK with the mode parameter set to O
Bormann (ed.) [Page 29]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.5. Operation in bi-directional reliable mode
5.5.1. Compression states and logic
Below is the state machine for the compressor in bi-directional
reliable mode. Details of each state, the transitions between states
and compression logic is given subsequent to the figure.
ACK
+------>------>------>------>------>------>------>------+
| |
| ACK ACK | ACK
| +------>------>------+ +------>------>------+ +->-+
| | | | | | |
| | v | v | v
+----------+ +----------+ +----------+
| FH State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | STATIC-NACK | | NACK / Update | |
| +------<------<------+ +------<------<------+ |
| |
| STATIC-NACK |
+------<------<------<------<------<------<------<------<------+
TBW: Descriptions of transitions and the packets used.
5.5.2. Decompression states and logic
The decompression states and the state transition logic are the same
as for the unidirectional case (see section 5.3.2). What differs is
the feedback logic, which states what feedback messages to send due
to different events when operating in the various states.
In NC state: - When a FH packet is correctly decompressed, send an
ACK with the mode parameter set to R
- When an FO or SO packet is received or decompression
of a FH packet has failed, send a STATIC-NACK with
the mode parameter set to R
In SC state: - When an FO or FH packet is correctly decompressed,
send an ACK with the mode parameter set to R
- When an SO packet is received, send a NACK with the
mode parameter set to R
- When decompression of an FO or FH packet has failed,
send a STATIC-NACK with the mode parameter set to R
Bormann (ed.) [Page 30]
INTERNET-DRAFT Robust Header Compression June 29, 2000
In FC state: - When an FO or FH packet is correctly decompressed,
send an ACK with the mode parameter set to R
- When an updating SO packet is correctly decompressed,
periodically send an ACK with the mode parameter set
to R
- When decompression of an SO, FO or FH packet has
failed, send a NACK with the mode parameter set to R
5.6. Mode transitions
The decision to move from one compression mode to another is taken by
the decompressor and the possible mode transitions are shown in the
figure below. How the transitions are performed is described in the
subsequent chapters.
+---------------------+
| Unidirectional mode |
+---------------------+
^ |
| |
| v
+---------------------+
| Optimistic mode |
+---------------------+
^ |
| |
| v
+---------------------+
| Reliable mode |
+---------------------+
5.6.1. From Unidirectional to Optimistic mode
As long as there is a feedback channel available, the decompressor
can at any moment decide to initiate transition from unidirectional
to bi-directional Optimistic mode. All feedback packets can be used
with the mode parameter set to O=Optimistic and the decompressor can
then directly start working in Optimistic mode.
ACK (O) : Is sent to transit after a successful
decompression. The compressor can, when receiving
this packet, move directly to SO state if no
update is needed compared to the acknowledged
packet.
NACK (O) : Is sent to transit after a decompression failure
if any preceding packet has been correctly
decompressed. The compressor must, when receiving
Bormann (ed.) [Page 31]
INTERNET-DRAFT Robust Header Compression June 29, 2000
this packet, go to FO state to update the
decompressor context.
STATIC-NACK (O) : Is sent to transit after a decompression failure
when decompression has never succeeded. The
compressor must, when receiving this packet, start
from FH state to establish the static part of the
context.
5.6.2. From Optimistic to Reliable mode
Transition from Optimistic to Reliable mode is only allowed after at
least one packet has been correctly decompressed, which means that
the static part of the context is established. Either the ACK(R) or
the NACK(R) feedback packet is used to initiate the transition and
the compressor MUST always run in FO state during transition. The
transition procedure is described below:
Comnpressor Decompressor
----------------------------------------------
| |
| ACK(R)/NACK(R) +-<-<-<-| Transition
| +-<-<-<-<-<-<-<-+ | initiated
|-<-<-<-+ |
Go to FO state | |
|->->->-+ FO(SN0,R) |
| +->->->->->->->-+ |
|->-.. +->->->-| Decompressor
|->-.. | transits to
| ACK(SN0,R) +-<-<-<-| Reliable mode
| +-<-<-<-<-<-<-<-+ |
Transition |-<-<-<-+ |
completed | |
|->->->-+ SO (Reliable mode) |
| +->->->->->->->-+ |
| +->->->-|
| |
As long as the decompressor has not received an FO packet with the
mode transition parameter set to R, it must stay in Optimistic mode.
The compressor must stay in FO state until it has received an ACK for
an FO packet sent with the mode transition parameter set to R
(indicated by the sequence number).
Since transition from Unidirectional to Optimistic mode do not
require any handshakes, it is possible to transit directly from
Unidirectional to Reliable mode, but only if at least one packet has
been successfully decompressed indicating a correct static context at
the decompressor.
Bormann (ed.) [Page 32]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.6.3. From Reliable to Optimistic mode
Either the ACK(O) or the NACK(O) feedback packet is used to initiate
the transition from Reliable to Optimistic mode and the compressor
MUST always run in FO state during transition. The transition
procedure is described below:
Comnpressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| Transition
| +-<-<-<-<-<-<-<-+ | initatied
|-<-<-<-+ |
Go to FO state | |
|->->->-+ FO(SN0,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| Decompressor
|->-.. | transits to
| ACK(SN0,O) +-<-<-<-| Optimistic mode
| +-<-<-<-<-<-<-<-+ |
Transition |-<-<-<-+ |
completed | |
|->->->-+ SO (Optimistic mode) |
| +->->->->->->->-+ |
| +->->->-|
| |
As long as the decompressor has not received an FO packet with the
mode transition parameter set to O, it must stay in Reliable mode.
The compressor must stay in FO state until it has received an ACK for
a FO packet sent with the mode transition parameter set to O
(indicated by the sequence number).
5.6.4. From optimistic to unidirectional mode
TBW: (idea text provided at the moment)
Initiate at compressor side by sending FO/FH packets with NO_FEEDBACK
flag set. When ack of that FO/ FH is received with mode-flag set to
U:
* for optimistic mode, go to unidirectional.
* for reliable mode, go to FO state and start transition procedure
to optimistic mode, but with the FO mode parameter set to U.
When procedure has completed, go to unidirectional mode.
In both cases, SO packets in the forward direction indicates to the
decompressor that the transition has completed.
Bormann (ed.) [Page 33]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Transition could also be initiated by the decompressor by sending U-
marked feedback. Decompressor could stop sending feedback when it
receives periodic refreshes from compressor.
5.7. Packet formats
Table 5.1 describes which packet formats are used.
NOTE: These packet formats do not include the parameters needed for
mode transition, those must be added for the scheme to work.
The first five columns profile state parameters that affect the
choice of packet types:
IPv This is the IP version for which the profile is designed.
Possible values for this column are 6 and 4.
CID This column gives the number of concurrent packet streams
that are supported by the header compression profile through
context identifiers (CIDs).
Chk This column indicates whether the profile supports packet
streams with the UDP checksum (E)nabled or D(isabled).
ID For profiles supporting IPv4, this column indicates which
behavior of the IPv4 Identification field the profile is
optimized for. Possible values in this column are:
(S)EQUENTIAL These profiles can handle all kind of
Identification assignment methods but
will be less efficient than RANDOM
profiles if the assignment truly is
random. If the value is sequentially
assigned, no extra overhead is added
for Identification.
(R)ANDOM These profiles are recommended if it is
known that random assignment is used.
The Identification field will be
included "as-is" which means that the
header size will increase by two
octets.
TbT Timer-based Timestamp decompression. Requires a timer at the
decompressor side to estimate timestamp jumps. Compressor
never sends more than a few bits of timestamp LSB with these
profiles. Can be (E)nabled or (D)isabled (see chapter 5.5.3).
S S gives the minimal header Size for the profile.
Bormann (ed.) [Page 34]
INTERNET-DRAFT Robust Header Compression June 29, 2000
The next five columns indicate how each profile is implemented. This
includes header formats for STATIC (STA, see chapter 5.7.1), DYNAMIC
(DYN, see chapter 5.7.2) and COMPRESSED (COM, see chapter 5.7.3)
packets, and also what EXTENSION (EXT, see chapter 5.7.4) formats are
used with the COMPRESSED packets. The CRC column tells the coverage
of the header compression CRC: uncompressed (H)eader or the same
coverage as for the UDP (C)hecksum (see chapter 5.8.).
Bormann (ed.) [Page 35]
INTERNET-DRAFT Robust Header Compression June 29, 2000
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| I | C | C | I | T | | S | | S | D | C | E | C |
| P | I | h | D | b | | | | T | Y | O | X | R |
| v | D | k | | T | | | | A | N | M | T | C |
+===+=====+===+===+===+ +===+ +===+===+=========+===+===+
| 6 | 1 | E | - | E | | 2 | | 1 | 1 | 1 | A | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 6 | 1 | E | - | D | | 2 | | 1 | 1 | 1 | A | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 6 | 256 | E | - | E | | 3 | | 2 | 2 | 2 | A | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 6 | 256 | E | - | D | | 3 | | 2 | 2 | 2 | A | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 1 | D | S | E | | 1 | | 3 | 3 | 5/17, 9 | D | H |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 1 | D | S | D | | 1 | | 3 | 3 | 5/17,13 | B | H |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 1 | D | R | E | | 3 | | 3 | 3 | 7/19,11 | C | H |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 1 | D | R | D | | 3 | | 3 | 3 | 7/19,15 | A | H |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 1 | E | S | E | | 2 | | 3 | 5 | 1 | D | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 1 | E | S | D | | 2 | | 3 | 5 | 1 | B | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 1 | E | R | E | | 4 | | 3 | 5 | 3 | C | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 1 | E | R | D | | 4 | | 3 | 5 | 3 | A | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 256 | D | S | E | | 2 | | 4 | 4 | 6/18,10 | D | H |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 256 | D | S | D | | 2 | | 4 | 4 | 6/18,14 | B | H |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 256 | D | R | E | | 4 | | 4 | 4 | 8/20,12 | C | H |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 256 | D | R | D | | 4 | | 4 | 4 | 8/20,16 | A | H |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 256 | E | S | E | | 3 | | 4 | 6 | 2 | D | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 256 | E | S | D | | 3 | | 4 | 6 | 2 | B | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 256 | E | R | E | | 5 | | 4 | 6 | 4 | C | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
| 4 | 256 | E | R | D | | 5 | | 4 | 6 | 4 | A | C |
+---+-----+---+---+---+ +---+ +---+---+---------+---+---+
Table 5.1 : Packet format table
Bormann (ed.) [Page 36]
INTERNET-DRAFT Robust Header Compression June 29, 2000
The packet types defined in chapter 5.2 are implemented with 4
different packet formats: STATIC, DYNAMIC, COMPRESSED and FEEDBACK.
To identify the packet format used, 4 bit patterns for the initial 5
bits of the first octet (not including a potential CID field) in all
packets are reserved. These patterns are:
STATIC 11111
DYNAMIC 1110* (both 11100 and 11101 are reserved for this)
FEEDBACK 11110
The other 28 (32-4) bit patterns indicate a COMPRESSED packet format
and the usage of these patterns are explained further on.
This section defines the header formats of the four ordinary packet
formats STATIC, DYNAMIC, COMPRESSED and FEEDBACK together with
descriptions of when and how to use them. A subsections is also
dedicated to the EXTENSION formats of COMPRESSED headers.
Bormann (ed.) [Page 37]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.7.1. Static information packets, initialization
The STATIC packet type is a packet containing no payload but only the
header fields that are expected to be constant throughout the
lifetime of the packet stream (classified as STATIC in appendix A). A
packet of this kind MUST be sent once as the first packet from
compressor to decompressor and also when requested by the
decompressor (see chapter 5.4.5). If the D-bit is set, a DYNAMIC
packet (without CID) is attached to the STATIC packet to create a
complete context initialization packet. The STATIC packet formats are
shown below for IPv6 and IPv4, respectively. Note that some fields
are only present in some of the STATIC packet types.
IPv6 (45-46 octets): STATIC1, STATIC2:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only present in STATIC2
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | D | - | - |
+---+---+---+---+---+---+---+---+
| |
+ Flow Label +
| |
+ +---+---+---+---+
| | - | - | P | E |
+---+---+---+---+---+---+---+---+
| |
/ Source Address / 16 octets
| |
+---+---+---+---+---+---+---+---+
| |
/ Destination Address / 16 octets
| |
+---+---+---+---+---+---+---+---+
| |
+ Source Port +
| |
+---+---+---+---+---+---+---+---+
| |
+ Destination Port +
| |
+---+---+---+---+---+---+---+---+
| |
/ SSRC / 4 octets
| |
+---+---+---+---+---+---+---+---+
| Header Compression CRC | see chapter 5.9.1.
+---+---+---+---+---+---+---+---+
Bormann (ed.) [Page 38]
INTERNET-DRAFT Robust Header Compression June 29, 2000
IPv4 (18-19 octets): STATIC3, STATIC4:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only present in STATIC4
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | F | P | E |
+---+---+---+---+---+---+---+---+
| |
/ Source Address / 4 octets
| |
+---+---+---+---+---+---+---+---+
| |
/ Destination Address / 4 octets
| |
+---+---+---+---+---+---+---+---+
| |
+ Source Port +
| |
+---+---+---+---+---+---+---+---+
| |
+ Destination Port +
| |
+---+---+---+---+---+---+---+---+
| |
/ SSRC / 4 octets
| |
+---+---+---+---+---+---+---+---+
| Header Compression CRC | see chapter 5.9.1.
+---+---+---+---+---+---+---+---+
All fields except for the initial five bits, the padding (-) and the
Header Compression CRC are the ordinary IP, UDP and RTP fields
(F=IPv4 May Fragment, P=RTP Padding, E=RTP Extension).
The number of STATIC packets sent on each occasion should be limited.
If the decompressor receives DYNAMIC or COMPRESSED headers without
having received a STATIC packet, the decompressor MUST send a
STATIC_FAILURE_FEEDBACK packet.
5.7.2. Dynamic information packets
The DYNAMIC packet type has a header containing all changing header
fields in their original, uncompressed form, and carries a payload
just like ordinary COMPRESSED packets. This packet type is used after
the initial STATIC packet to set up the decompressor context for the
first time, and also whenever the header field information cannot be
Bormann (ed.) [Page 39]
INTERNET-DRAFT Robust Header Compression June 29, 2000
encoded in EXTENDED_COMPRESSED packets. DYNAMIC packets could be used
due to significant field changes or upon INVALID_CONTEXT_FEEBACK.
All fields except for the initial four bits, the Timestamp Delta, and
the Header Compression CRC are ordinary IP, UDP and RTP fields. The
Timestamp Delta is the current delta between RTP timestamps in
consecutive RTP packets. Initially this value SHOULD be set to 160.
The packet formats are shown below for IPv6 and IPv4, respectively.
Note that some fields are only present in some of the DYNAMIC packet
types.
IPv6 (13-16 octets + CSRC List of 0-60 octets): DYNAMIC1, DYNAMIC2:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only in DYNAMIC2
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CSRC Counter |
+---+---+---+---+---+---+---+---+
| Traffic Class |
+---+---+---+---+---+---+---+---+
| Hop Limit |
+---+---+---+---+---+---+---+---+
| |
+ UDP Checksum +
| |
+---+---+---+---+---+---+---+---+
| M | Payload Type |
+---+---+---+---+---+---+---+---+
| |
+ Sequence Number +
| |
+---+---+---+---+---+---+---+---+
| |
/ Timestamp / 4 octets
| |
+---+---+---+---+---+---+---+---+
: :
: CSRC List : 0-15 x 4 octets
: :
+---+---+---+---+---+---+---+---+
| |
+ Timestamp Delta +
| |
+---+---+---+---+---+---+---+---+
| Header Compression CRC | see chapter 5.9.2.
+---+---+---+---+---+---+---+---+
/ Payload /
+---+---+---+---+---+---+---+---+
Bormann (ed.) [Page 40]
INTERNET-DRAFT Robust Header Compression June 29, 2000
IPv4 (15-18 octets + CSRC List of 0-60 octets): DYNAMIC3, DYNAMIC4,
DYNAMIC5, DYNAMIC6:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only in DYNAMIC4 and DYNAMIC6
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CSRC Counter |
+---+---+---+---+---+---+---+---+
| Type Of Service |
+---+---+---+---+---+---+---+---+
| |
+ Identification +
| |
+---+---+---+---+---+---+---+---+
| Time To Live |
+---+---+---+---+---+---+---+---+
: :
+ UDP Checksum + only in DYNAMIC5 and DYNAMIC6
: :
+---+---+---+---+---+---+---+---+
| M | Payload Type |
+---+---+---+---+---+---+---+---+
| |
+ Sequence Number +
| |
+---+---+---+---+---+---+---+---+
| |
/ Timestamp / 4 octets
| |
+---+---+---+---+---+---+---+---+
: :
: CSRC List : 0-15 x 4 octets
: :
+---+---+---+---+---+---+---+---+
| |
+ TS Delta +
| |
+---+---+---+---+---+---+---+---+
| Header Compression CRC | see chapter 5.9.2.
+---+---+---+---+---+---+---+---+
/ Payload /
+---+---+---+---+---+---+---+---+
Each time a DYNAMIC packet is sent, several subsequent packets SHOULD
also be DYNAMIC packets to ensure a successful update even when
packets are lost. Context updates both with DYNAMIC and COMPRESSED
packets could also be acknowledged with CONTEXT_UPDATED_FEEDBACK.
Bormann (ed.) [Page 41]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.7.3. Compressed packets
The COMPRESSED packet type is the most commonly used packet and is
designed to handle ordinary changes as efficiently as possible.
When changes are regular, all information is carried in the base
header. When desired, it is possible to send additional information
in extensions to the COMPRESSED base-header.
The COMPRESSED base-header formats are shown below. Note that some
fields are only present in some of the COMPRESSED packet types.
Defines packet types: COMPRESSED1..COMPRESSED4:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only in COMPRESSED type 2 and 4
+---+---+---+---+---+---+---+---+
| Sequence LSP# | | # see chapter 5.8.2
+---+---+---+---+---+ +---+
| Header Compression CRC* | X | * see chapter 5.9.3
+---+---+---+---+---+---+---+---+
: :
+ Identification + only in COMPRESSED type 3 and 4
: :
+...+...+...+...+...+...+...+...+
: :
/ Extension / only present if X=1
: :
+---+---+---+---+---+---+---+---+
/ Payload /
+---+---+---+---+---+---+---+---+
Defines packet types: COMPRESSED5..COMPRESSED8:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only in COMPRESSED 6 and 8
+---+---+---+---+---+---+---+---+
| 0 | Sequence LSB# | CRC* | # see chapter 5.8.1
+---+---+---+---+---+---+---+---+ * see chapter 5.9.3
: :
+ Identification + only in COMPRESSED 7 and 8
: :
+---+---+---+---+---+---+---+---+
/ Payload /
+---+---+---+---+---+---+---+---+
Bormann (ed.) [Page 42]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Defines packet types: COMPRESSED9..COMPRESSED12:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only in COMPRESSED 10 and 12
+---+---+---+---+---+---+---+---+
| 1 0 | CRC* | * see chapter 5.9.3
+---+---+---+---+---+---+---+---+
| Sequence LSB# | STS LSB# | X | # see chapter 5.8.1
+---+---+---+---+---+---+---+---+
: :
+ Identification + only in COMPRESSED 11 and 12
: :
+...+...+...+...+...+...+...+...+
: :
/ Extension / only present if X=1
: :
+---+---+---+---+---+---+---+---+
/ Payload /
+---+---+---+---+---+---+---+---+
Defines packet types: COMPRESSED13..COMPRESSED16:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only in COMPRESSED 14 and 16
+---+---+---+---+---+---+---+---+
| 1 0 | M | STS LSB# | # see chapter 5.8.1
+---+---+---+---+---+---+---+---+
| Sequence LSB# | CRC* | X | * see chapter 5.9.3
+---+---+---+---+---+---+---+---+
: :
+ Identification + only in COMPRESSED 15 and 16
: :
+...+...+...+...+...+...+...+...+
: :
/ Extension / only present if X=1
: :
+---+---+---+---+---+---+---+---+
/ Payload /
+---+---+---+---+---+---+---+---+
Bormann (ed.) [Page 43]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Defines packet types: COMPRESSED17..COMPRESSED20:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: Context Identifier (CID) : only in COMPRESSED 18 and 20
+---+---+---+---+---+---+---+---+
| 0 | C | Sequence LSB# | # see chapter 5.8.1
+---+---+---+---+---+---+---+---+
: CRC* : only present if C=1
+...+...+...+...+...+...+...+...+ * see chapter 5.9.3
: :
+ Identification + only in COMPRESSED 19 and 20
: :
+---+---+---+---+---+---+---+---+
/ Payload /
+---+---+---+---+---+---+---+---+
The coverage of the Header Compression CRC is described in chapter
5.6.3. In that chapter, the CRC polynomials to use are also defined.
The interpretations of the Sequence and STS (Scaled TimeStamp) fields
for different packet formats are given in section 5.8.
Bormann (ed.) [Page 44]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.7.4. Extensions to compressed headers
Less regular changes in the header fields or updates of decompressor
contexts require an extension in addition to the base header. When
there is an extension present in the COMPRESSED packet, this is
indicated by the extension bit (X) being set. Extensions are of
variable size depending on the information needed to be transmitted.
However, the first three extension bits are used as an extension Type
field for all extension formats. The extension can carry an M-bit, a
t-bit, a SEQ EXT LSB field (called SEQ*), a (S)TS (EXT) LSB field
(called TS*), an ID LSB field and a bit mask for additional fields.
The M-bit is the RTP marker bit and the (S)TS (EXT) LSB is timestamp
information sent with the least significant bits (the most
significant bits are then expected to be unchanged compared to
context). The timestamp information could either be the LSB of the
(S)caled (T)ime(S)tamp value (if indicated with the t-bit unset) or
the LSB of the absolute timestamp value. For profiles with a
timestamp field in the compressed base header, the timestamp
information is sent as an extended range to that field. The SEQ EXT
LSB is extended range for the RTP sequence number. How extended range
works is described in chapter 5.5.1 and 5.5.2. The t-bit is sent when
timestamp is not scaled, otherwise it is always scaled with the
timestamp delta. The ID LSB is the LSB of the IP Identification
value. Various bit mask patterns are possible and can consist of
S,H,C,D,T and I. The interpretations of these bits are given at the
end of this chapter.
The guiding principle for choosing the extension type is to find the
smallest header type that can communicate the information needed.
For the profiles defined in this document, four different extension
sets are used, called A, B, C and D. Set A and C are for IPv6 and do
not handle the IPv4 identification field, which set B and D do. Set A
and B handle timestamp information which set C and D do not. All
possible extensions are shown below with indications of which sets
and types the extensions correspond to. For instance, B3 means that
in extension set B, the extension is used with type value 3
(indicated in the type field).
The defined extension types are shown below:
0 7
- - +-+-+-+-+-+-+-+-+
A0, B0, |0 0 0| SEQ* |
C0, D0 - - +-+-+-+-+-+-+-+-+
0 7
- - +-+-+-+-+-+-+-+-+
A1, B1 |0 0 1|M| TS* |
- - +-+-+-+-+-+-+-+-+
Bormann (ed.) [Page 45]
INTERNET-DRAFT Robust Header Compression June 29, 2000
1
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A2 |0 1 0|M| TS* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 2
0 7 8 5 6 3
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A3 |0 1 1|M|t| TS* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7
- - +-+-+-+-+-+-+-+-+ - -
A4 |1 0 0|M|H|D|T|t|
- - +-+-+-+-+-+-+-+-+ - -
1
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
A5 |1 0 1|M|C|H|S|D| TS* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
1 1 2
0 7 8 5 6 3
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
A6 |1 1 0|M|C|H|S|D|t| TS* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
1
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
A7 |1 1 1|M|C|H|S|D|T|t| SEQ* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
1
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B2 |0 1 0|M| TS* | SEQ* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B3 |0 1 1|M| TS* | ID LSB |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bormann (ed.) [Page 46]
INTERNET-DRAFT Robust Header Compression June 29, 2000
0 7
- - +-+-+-+-+-+-+-+-+
B4, D4 |1 0 0|M| ID LSB|
- - +-+-+-+-+-+-+-+-+
0 7
- - +-+-+-+-+-+-+-+-+ - -
B5 |1 0 1|M|H|D|T|I|
- - +-+-+-+-+-+-+-+-+ - -
1 2
0 7 8 5 3
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B6 |1 1 0|M|t| TS* | ID LSB |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
B7 |1 1 1|M|C|H|S|D|T|I|t| SEQ* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
1
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C1, D1 |0 0 1|M| SEQ* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
C2, D2 |0 1 0|M|C|H|S| SEQ* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
0 7
- - +-+-+-+-+-+-+-+-+ - -
C3, D3 |0 1 1|M|C|H|S|-|
- - +-+-+-+-+-+-+-+-+ - -
0 7 8 5
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D5 |1 0 1|M| ID LSB |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bormann (ed.) [Page 47]
INTERNET-DRAFT Robust Header Compression June 29, 2000
1 1 2
0 7 8 5 6 3
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
D6 |1 1 0|M|C|H|S|-| ID |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
Bit masks indicating additional fields have the following meaning:
C - Traffic (C)lass / Type Of Service
H - (H)op Limit / Time To Live
S - Contributing (S)ources - CSRC
D - Timestamp (D)elta
T - (T)imestamp LSB
I - (I)dentification LSB
If any of these fields are included, they will appear in the order as
listed above and the format of the fields will be as described below.
C - Traffic Class / Type Of Service
The field contains the value of the original IP header field.
8 bits
- - +-+-+-+-+-+-+-+-+ - -
| TC / TOS |
- - +-+-+-+-+-+-+-+-+ - -
H - Hop Limit / Time To Live
The field contains the value of the original IP header field.
8 bits
- - +-+-+-+-+-+-+-+-+ - -
| HL / TTL |
- - +-+-+-+-+-+-+-+-+ - -
S - Contributing Sources
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 |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+ - -
Bormann (ed.) [Page 48]
INTERNET-DRAFT Robust Header Compression June 29, 2000
D - Timestamp Delta
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 the number of samples divided by
8. Thus, only Timestamp Delta values evenly divisible by 8 can
be communicated in the Timestamp Delta field of 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 DYNAMIC packet.
8 bits
- - +-+-+-+-+-+-+-+-+ - -
|Timestamp Delta|
- - +-+-+-+-+-+-+-+-+ - -
Note that when the Timestamp Delta is changed, Timestamp LSB
field MUST also be included not downscaled with the delta.
T - Timestamp LSB
The field contains the 16 least significant bits of the RTP
timestamp, scaled if t-bit not set. May be sent as extended
range for some profiles.
16 bits
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
| TS* |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
I - Identification
The field contains the IP Identification.
16 bits
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID |
- - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When information of any kind is sent in an extension, the
corresponding information SHOULD also be sent in some subsequent
packets (either as Extensions or in DYNAMIC packets).
Bormann (ed.) [Page 49]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.7.5. Feedback packets
Feedback packets are used by the decompressor to provide various
types of feedback to the compressor. That could include active
feedback to assure error free performance or passive feedback (in
case of invalidated context) to request a context update from the
compressor. The feedback mechanisms defined here leave a lot to the
implementation regarding how to use feedback. The general feedback
packet format is shown below:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
FEEDBACK (GENERAL) : Context Identifier (CID) :
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | Type |
+---+---+---+---+---+---+---+---+
Note that The CID field is present only for profiles using STATIC
packet format 2 or 4, which are profiles supporting multiple packet
streams. The Type field tells what kind of feedback the packet
corresponds to and the feedback types defined are the following:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
STATIC_FAILURE_FEEDBACK : Context Identifier (CID) :
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 0 0 |
+---+---+---+---+---+---+---+---+
The STATIC_FAILURE_FEEDBACK packet tells the compressor that the
static part of the decompressor context is invalid, and that an
update of that part is required. Reasons for sending such feedback
could be that no STATIC packet has been received at all, or that
decompression has failed even when DYNAMIC packets are decompressed.
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
INVALID_CONTEXT_FEEDBACK : Context Identifier (CID) :
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 0 1 |
+---+---+---+---+---+---+---+---+
| Last Sequence Number LSB |
+---+---+---+---+---+---+---+---+
The INVALID_CONTEXT_FEEDBACK packet SHOULD be sent to signal an
invalid decompressor context, indicated by failing decompression of
COMPRESSED packets.
Bormann (ed.) [Page 50]
INTERNET-DRAFT Robust Header Compression June 29, 2000
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
NO_PACKETS_FEEDBACK : Context Identifier (CID) :
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 1 0 |
+---+---+---+---+---+---+---+---+
| Last Sequence Number LSB |
+---+---+---+---+---+---+---+---+
The NO_PACKET_FEEDBACK packet can be used by the decompressor to
signal that packets have not been received for some time. It is not
always possible for the decompressor to notice such events, and it is
therefore up to the implementers to decide whether and when to use
this feedback packet.
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
LONGEST_LOSS_FEEDBACK : Context Identifier (CID) :
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 1 1 |
+---+---+---+---+---+---+---+---+
| Last Sequence Number LSB |
+---+---+---+---+---+---+---+---+
| Length of longest loss |
+---+---+---+---+---+---+---+---+
The LONGEST_LOSS_FEEDBACK packet can be used by the decompressor to
inform the compressor about the length of the longest loss event that
has occurred on the link between compressor and decompressor. It is
not always possible for the decompressor to provide this information,
and it is therefore up to the implementers to decide whether and when
to use this feedback packet.
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
CONTEXT_UPDATED_FEEDBACK : Context Identifier (CID) :
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 1 0 0 |
+---+---+---+---+---+---+---+---+
| Last Sequence Number LSB |
+---+---+---+---+---+---+---+---+
The CONTEXT_UPDATED_FEEDBACK packet can be used to signal that an
update of some header fields has been correctly received, either in a
DYNAMIC packet or in an EXTENDED_COMPRESSED packet. It is optional to
use this active feedback mechanism and the compressor MUST NOT expect
such packets initially. First after reception of one such packet, the
compressor can expect to get this feedback from the decompressor.
Bormann (ed.) [Page 51]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.8. Encoding of field values
The source increases the RTP sequence number by one for each packet
sent. However, due to losses and reordering before the compression
point, the changes seen by the compressor may vary. This would
especially be the case if we consider the scenario in Figure 1.1
where there are cellular links at both ends of the path. That is one
reason why sequence number changes need special treatment, but
another reason is that both timestamps and IP identification for most
packets can be recreated with a combination of history and sequence
number knowledge. The profiles defined in this document handle the
sequence number, timestamp and identification values with LSB
encoding, except for some profiles that use LSP encoding for the
sequence number. For timestamp, some profiles also use the principle
with timer-based decompression. This chapter describes how the
different encoding methods are applied to the various field values.
5.8.1. LSB encoding of field values
LSB encoding is used for sequence number, timestamp and
identification encoding as described in chapter 4.5.1. The sequence
numbers, included in all compressed headers, can be sent with
extended range in extension headers. This is also the case with the
timestamp value when not using timer-based TS reconstruction (see 5.7
and 5.7.8). With timer-based timestamp decompression, the amount of
timestamp LSB that is sent is always limited to the size of the field
in the compressed header. Note that in most headers, the timestamp
value is sent as STS LSB (scaled timestamp LSB), which means that it
is the least significant bits of the timestamp, scaled down with the
timestamp delta (STS LSB = LSB of [TS / TS Delta]).
5.8.2. LSP encoding of field values
LSP, as described in chapter 4.5.2, is used for sequence numbers in
the "Sequence LSP" field of COMPRESSED1..COMPRESSED4 headers. For
those headers, there are 28 code-points left for sequence information
because 4 are reserved for packet type identification. An LSP of size
28 is therefore used with the following encoding:
CODE(n) = LSP:28(n)
The sequence range can be extended with extra bits in extension
headers, as described in chapter 4.5.3. The "SEQ EXT LSB" field must
for the case of extended LSP consist of the LSB of the integer
quotient.
The reordering parameter for LSP MUST be set to 2 meaning that first
and second order reordering can be handled by the encoding.
Bormann (ed.) [Page 52]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.8.3. Timer-based timestamp decompression
The RTP timestamp field is one of the header fields that may change
dynamically on a per packet basis. For audio services, the timestamp
value can be inferred from the encoded RTP sequence number value
during talk spurts. When the encoded sequence number is incremented
by N, the timestamp value is incremented by N * Timestamp-Delta-
value. However, when a talk spurt has faded into silence and a new
talk spurt starts, the timestamp value will take a leap compared to
the sequence number. To communicate this leap in the timestamp value,
some additional action has to be taken. In chapter 5.7.4, extension
headers are defined that can transfer this leap in the timestamp
value. That increases, however, the average header size. This chapter
describes an optional method used by some profiles (see the TbT
column of table 5.1) to reconstruct the timestamp value, requiring
only a fixed number of added bits for timestamp leaps. The method
makes use of timers or a local wall clock at the decompressor.
To initialize the header compression and the timer-based timestamp
reconstruction, the absolute value of the timestamp together with the
sequence number must be transferred from compressor to decompressor
at the beginning of the compression session. A default timestamp
delta is also transferred. This is done through the transmission of a
DYNAMIC header. For speech codecs with 8 kHz sampling frequency and
20 ms frame sizes, for example, the timestamp delta will be 8000*0.02
= 160. The decompressor then knows that the timestamp will increase
by 160 for each packet containing 20 ms of speech. Hence, by using a
local clock and by measuring packet arrival times, the decompressor
can estimate the timestamp change compared to the previous packet.
If, for example, a speech period has been succeeded by a silence
period at the time T0 and a new speech period starts at the time
T0+dT, it can be assumed that the timestamp has changed by:
round(dT/(time for one speech frame)) * (timestamp delta)
The packet time interval (or codec frame size in time) may be
determined through the a priori knowledge that most speech codecs
have constant frame sizes of 10, 20 or 30 ms, or through measurements
on packet arrival times.
The decompressor can then get an estimate of the timestamp change,
add this change to the previous value and replace the least
significant bits with those received in the compressed header. This
should give the correct timestamp value.
It is very important to verify the correctness of a timer-based
timestamp decompression. However, this is automatically done in ROCCO
with the header compression CRC verification.
Bormann (ed.) [Page 53]
INTERNET-DRAFT Robust Header Compression June 29, 2000
5.9. Header compression CRCs, coverage and polynomials
This chapter contains a description of how to calculate the different
CRCs used in the packet headers defined in this document.
5.9.1. STATIC packet CRC
The CRC in the STATIC header is calculated over the whole STATIC
packet except for the header compression CRC itself. Therefore, the
header compression CRC field MUST be set to 0 before the CRC
calculation.
The CRC polynomial to be used in STATIC packets is:
C(x) = 1 + x + x^2 + x^8
5.9.2. DYNAMIC packet CRC
The CRC in the DYNAMIC packet is calculated over the original
IP/UDP/RTP header. Before the calculation of the CRC, the IPv4 header
checksum and the UDP checksum have to be set to 0. This makes it
possible to recalculate the checksums after the decompression.
Calculation over the full IP/UDP/RTP headers ensures that the
decompressed IP/UDP/RTP header is a correct header.
The CRC polynomial to be used in DYNAMIC packets is:
C(x) = 1 + x + x^2 + x^8
5.9.3. COMPRESSED packet CRCs
COMPRESSED1..COMPRESSED4
The header compression CRC in COMPRESSED header types 1 to 4 is
calculated over the same headers as the CRC in the DYNAMIC packet,
except for profiles which use replacement of the UDP checksum, I.e.
except for profiles 1-4 and 13-16. In profiles 1-4 and 13-16, the
header compression CRC also covers the payload covered by the UDP
checksum.
The polynomial to be used is:
C(x) = 1 + x + x^4 + x^5 + x^9 + x^10
Bormann (ed.) [Page 54]
INTERNET-DRAFT Robust Header Compression June 29, 2000
COMPRESSED5..COMPRESSED8 and COMPRESSED13..COMPRESSED16
In COMPRESSED header types 5 to 8 and 13 to 16 the header compression
CRC is calculated over the same headers as the CRC in the DYNAMIC
packet, but with a different polynomial:
C(x) = 1 + x + x^3
COMPRESSED9..COMPRESSED12
In COMPRESSED header types 9 to 12 the header compression CRC is
calculated over the same headers as the CRC in the DYNAMIC packet,
but with a different polynomial:
C(x) = 1 + x + x^3 + x^4 + x^6
COMPRESSED17..COMPRESSED20
In COMPRESSED header types 17 to 20 the header compression CRC is
calculated over the same headers as the CRC in the DYNAMIC packet,
but with a different polynomial:
C(x) = ????
5.10 State transitions using keyword packets
(Editor: This section is separate because I believe merging it in is
not just an editorial exercise.)
5.10.1 The concept of keyword based state transitions
The main purpose of this algorithm is to enable the compressor to
employ the optimistic approach (for uni- or bi-directional links) as
described in greater detail in sections 5.3.1 and 5.3.2.
For an optimistic approach the compressor decides when it wants to
proceed from FO to SO state. Basically the transition will be made
after the compressor thinks the FO packets are received correctly and
the valid context is established. However this is an optimistic and
not a reliable approach. The compressor might proceed to SO state and
send SO packets, while the decompressor lost packets and is still in
FO state. Therefore a mechanism is needed to detect this case.
This section describes in greater detail the mechanism of using
keyword packets to transit securely from FO to SO state.
5.10.1.1 Keyword field, update and non-update packet
The algorithm is based on the concept that some packets update the
context, namely update packets, while others do not update the
Bormann (ed.) [Page 55]
INTERNET-DRAFT Robust Header Compression June 29, 2000
context at all, namely non-update packets. All packets indicate the
context state that is referenced and therefore needed to decompress
the packet correctly.
The main idea how this is done is the definition of a keyword field.
The packets with the same keyword field value, reference the same
context state. The context state to be used is defined by sending a
update packet, i.e. a packet that has a new keyword value and which
contents update the context to the new context state. The following
packets are called non-update packets, because they do not update the
context.
Hence, if a non-update packet gets lost, the receiver is nevertheless
able to decompress the following packets.
5.10.1.2 Refreshing the context by sending update packets
From time to time it will be necessary to update the context. There
are mainly two reasons to do so.
First, while compressing and transmitting the compressed non-update
packets, the LSB encoded values may increase and need more coded bits
in the compressed header. If the header size exceeds a certain
threshold, a new keyword should be sent in an update packet. This
enables the compressor to use less LSB in the following non-update
packets. E.g. after a while the number of LSB to encode the RTP
sequence number will grow. If this value exceeds 6 bits, it might be
useful to send an update packet, because the information would not
fit into an one-byte header packet any more. After the successful
update the compressor is able to send one-byte header packets again.
This means that the compressor is still in SO state and thus sends SO
packets. The corresponding update packets that are sent are also SO
packets, because they still rely on the previous update. This also
means that the update packets are small, i.e. only two bytes in size.
Second, if a value had changed and seems to be stable now, a new
update packet should be sent. This means a transition from SO to FO
state happened. It is not possible to use SO packets any more,
because some fields can not be calculated from the RTP sequence
number any more. It is not necessary to send update packets in FO
state. The problem would be, that changed value would have to be
transmitted in all following packets. This means that FO packets have
to be send all the time, i.e. the compressor stays in FO state. To
get into SO state, the compressor has to use the optimistic approach,
which says that if he thinks the decompressor has established the new
context he switches to SO state. To update the context at the
decompressor, update packets have to be sent.
E.g. after a silent period the timestamp changes by another value
than the default difference timestamp. From this on it is not
Bormann (ed.) [Page 56]
INTERNET-DRAFT Robust Header Compression June 29, 2000
possible for the decompressor to calculate the timestamp from the RTP
sequence number. The compressor is in FO state and either sends the
LSB of the timestamp in every packet, or updates the context, to
enable a later transition to SO state again.
5.10.1.3 Minimizing the loss probability of update packets (safe
transition from FO to SO state)
This section describe the transition from FO to SO state in greater
detail and gives algorithms that support a save transition.
It is useful to send several update packets with the same keyword
value to establish a new context state for both sides, before going
to SO state. The LSB encoded values are transmitted as usual in those
packets, while one has to take care that the original values of the
fields that changed irregularly are transmitted in every of those
update packets. The use of this mechanism reduces the context state
loss probability, because only one of those update packets has to be
received correctly.
Sending several update packets with the same keyword could be done
either successively or in any kind of sparse mode, e.g. as described
in [ref to sparse mode description, TBD].
5.10.1.4 Restrict the use of new keywords
The number of different keywords is limited by the number of bits
used for the keyword field. Here only one bit is used, which leads to
two different keywords. To ensure that consecutive packet loss of a
few packets does not lead to wrong decompression, the use of new
keyword values must be limited.
It is only allowed to send a new keyword in an update packet, if N
non-update packets were sent since the last keyword change. The value
N should be set according to the expected longest loss event. This
restriction is possible, because one never is forced to send an
update packet. It is always possible to send all information in a
non-update packet. This might lead to a decreased efficiency for
short times, because the compressor stays longer in FO state, but if
the keywords are used properly, this should only very seldom happen.
To use the keyword properly means that it is only changed if the
compressor is rather sure that the values will remain constant for
the next packets. An example of a non-properly used keyword change is
the definition of a new default delta timestamp value (in an update
packet), just because it changed for one packet. This might be due to
a silent period and might change back to the original value in the
next packet again.
If the compressor follows this restriction, more than N consecutive
packets have to be lost, before the decompressor would not detect the
Bormann (ed.) [Page 57]
INTERNET-DRAFT Robust Header Compression June 29, 2000
loss of the update packet. To avoid even this situation a time-out
might be applied, after which the decompressor will only accept new
update packets or Full Header packets.
5.10.1.5 Loss of update packets
Only if the update packets are transmitted correctly, the receiver is
able to decompress any incoming compressed header (i.e. the receiver
is then in SO state). Therefore if the update packets are transmitted
multiple times, the probability that none of this packets is
received, is very low. However, packet loss may occur while
transmitting update packets. In case none of the update packets was
received and the decompressor received a packet with a new keyword
that is not an update packet, it must send a message to the
compressor, to ask for a packet with a header that re-establishes its
context. This is always an update packet or a Full Header packet.
5.10.1.6 The use of LSB encoding in the context of this algorithm
The packets that follow an update packet, are encoded by transmitting
the Least Significant Bits (LSB) of regular changing fields (e.g. RTP
Sequence Number). In some cases it might not be necessary to transmit
the regular changing fields at all, e.g. if the timestamp can be
calculated from the sequence number it is not transmitted. The
packets also contain the original values of fields that did change
since the last update, but are usually assumed to be constant (e.g.
RTP Marker bit, RTP Payload Type).
A problem in using LSBs is the wrap-around. Because only some bits of
the original value is transmitted, it has to be ensured, that the
decompression is correct. If other bits than the transmitted bits
have changed, the decompressor must be able to compute this.
To solve this problem Variable Length Encoding (VLE) as described in
[ref to VLE] is used.
5.10.1.7 Adaptation to the environment
The compressor has a lot of freedom in the compression algorithm.
Even though the use of new keywords is restricted, the compressor
decides when the keywords should be changed. Two strategies are
possible, which are a trade-off between compression efficiency and
robustness against packet loss. One possibility is to send a new
keyword as often as needed and possible. E.g. the keyword is changed,
if the header size exceeds 1 byte. Another possibility is to sent new
keywords less frequent. While on the one hand the compression
efficiency might be better in the first case, the second possibility
is more robust and less susceptible for packet loss.
Using this freedom the compressor may adapt the compression to the
environment (i.e. the experienced BER or RTT). Another parameter of
Bormann (ed.) [Page 58]
INTERNET-DRAFT Robust Header Compression June 29, 2000
the environment that should be taken into consideration is the
assignment of the IPv4 Identification value. While it is possible to
have a totally random IP Identification, it might also be possible
that it is increased for every packet by a fixed value (sequential IP
ID). Different sets of packet types, used for different environments
might lead to a better performance. This paper defines two different
packet type sets. The packet formats are optimised for different
environments. If the IP ID is assigned sequentially, increasing by a
fixed value for each packet, the header compression mechanism should
take advantage of it. Anyway, because we cannot assume this
behaviour, another set of packet formats is defined, which is
optimised for non sequential IPv4 Identification values.
The two sets of packet formats are called packet-profiles in the
remainder of this document.
5.10.1.8 Dealing with Residual Bit Error Rate
A requirement from the lower layers that this header compression
scheme works above, is that the residual bit error rate should be
kept to a minimum. However bit errors might occur in compressed
packet. To avoid a damage propagation (see [requirements document]
for the definition of damage propagation) the update packets are
protected by a CRC, which is calculated over the uncompressed header.
Detailed information about the CRC and its usage can be found in
section [CRC usage]. Because only the update packets update the
context on which the non-update packets rely, damage propagation is
prevented, by protecting only the update packets.
5.10.3 Packet-Profile 1, optimized for sequential IPv4 Identification
This section shows five different packets that are used to transmit
the data and signal errors from the receiver to the sender. The
packet formats are optimised for the use in an environment, where the
IPv4 Identification is assigned sequentially for the compressed
packet stream. The format of the packets is described and it is
explained in detail how the decompressor is able to regenerate the
complete header from the given information. The exact compression
behaviour is implementation specific, but it has to be ensured, that
any decompressor is able to regenerate the complete header in the
described way.
5.10.3.1 Full Header packet
The Full Header packet is sent at the beginning of the session to
establish a valid context, i.e. to switch from Init- to FO state. It
is only sent another time if requested by the receiver or a severe
error occurred. The receiver must request a Full Header packet only
if the initial packet was lost, or a severe error occurred, that
cannot be solved by a Compressed Packet.
Bormann (ed.) [Page 59]
INTERNET-DRAFT Robust Header Compression June 29, 2000
To ensure the correct reception of the fields that are only
transmitted in this packet type, it might be useful to use this
packet type for several succeeding packets. The next packet type to
use is always an update packet, which contains a new keyword. The
decompressor will discard any other received packet and sent a
context state feedback, until it receives an update packet to
establish a valid context (the keyword is part of the context).
The format of this packet's header is quite similar to the original
IP/UDP/RTP header. However, as described in other header compression
papers, such as CRTP [7], the length fields of the IP and UDP packets
are redundant. They are usually signalled by the link layer. This
enables us to use these fields to signal the header compression
specific session context identifier (CID)as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C-L| | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CID) | (CID) | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-L (CID Length):
00 - no CID
01 - 8 bit
10 - 16 bit
The selection of 0, 8 or 16 bit CIDs enables the compressor to set-up
enough sessions while keeping the overhead to a minimum.
Packet type identification might not be done by the link layer. In
this case another byte is added before the original full header:
+-+-+-+-+-+-+-+-+
|1|1|1|0|-|-|-|-| Packet Type Identification
+-+-+-+-+-+-+-+-+
: RTP/UDP/IP :
: packet :
5.10.3.2 Basic-Compressed packet
FO packets are always of this type. Only if no extensions are
transmitted, this is an SO packet. This is useful either to enlarge
the number of RTP sequence number bits, or to send an update packet
out of SO state.
The header of the Basic-Compressed packet is divided into a basic
header that is transmitted for every packet of this type and header
Bormann (ed.) [Page 60]
INTERNET-DRAFT Robust Header Compression June 29, 2000
extensions that are only used if necessary. Update and non-update
packets can be sent in Basic-Compressed packet format. The type is
identified by the new keyword flag, which is set for update packets.
5.10.3.2.1 Basic header
The basic header's format is as follows:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: MSB of Session CID : if 16 bit CID is used
+...+...+...+...+...+...+...+...+
: LSB of Session CID : if 16 or 8 bit CID is used
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 |KW |NKW| M | E | S |
+---+---+---+---+---+---+---+---+
: LSB of RTP SN :
+...+...+...+...+...+...+...+...+
: MSB of RTP SN : if S==1
+...+...+...+...+...+...+...+...+
: :
: Extension(s) : if E==1
: :
+...+...+...+...+...+...+...+...+
: :
+ UDP Checksum + if non-zero in context
: :
+...+...+...+...+...+...+...+...+
: CRC :
+---+---+---+---+---+---+---+---+
| RTP Data |
: :
CID:
The first two bytes can be used for the session CIDs.
KW (Keyword):
The Keyword field must be present in every packet. To detect loss of
update packets, it must be changed at each renewal.
NKW (New Keyword Indication):
If this bit is set, the compressor defines this packet as an update
packet. The context state after decompressing this packet is stored
and referenced in the following packets. Several successive update
packets should be sent, each containing the relevant information, to
ensure the reception at the decompressor. This bit also indicates the
presence of the CRC.
M (RTP Marker):
The M-bit represents the original RTP Marker.
E (Extension):
This bit indicates that at least one extension is used. The different
possible extensions, that are used to transmit information about
Bormann (ed.) [Page 61]
INTERNET-DRAFT Robust Header Compression June 29, 2000
irregular changes in the header fields, are described in detail in
the following sections.
S (RTP Sequence Number Indication):
This bit indicates if the LSB of the RTP Sequence Number or the
original value follows directly.
S=0: 8 bit LSB RTP Sequence Number
S=1: 16 bit RTP Sequence Number
UDP Checksum:
If the UDP Checksum is enabled, this field contains the 16-bit
Checksum, else it is not present.
CRC:
This 8 bit CRC is calculated over the uncompressed header. It is used
to verify the correct transmission of the compressed packet.
5.10.3.2.2 Changing Field Extension
This extension is sent every time some header fields changed in an
irregular way and cannot be calculated from the RTP Sequence Number.
This might be the case e.g. for the RTP Timestamp after a silent
period, or for the IPv4 Time To Live value. If the NKW-bit is set
(i.e. the packet is an update packet), the fields transmitted in this
extension define the new context state to be referenced by the
following packets. Several successive update packets should be sent,
each containing the relevant fields, to ensure the reception at the
decompressor.
The format of the Changing Field Extension is defined below:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | ID |TS |TOS|TTL|PT | E |
+---+---+---+---+---+---+---+---+
. .
. (LSB) IPv4 Identification . if ID > 0
. .
+...+...+...+...+...+...+...+...+
. .
. (LSB) RTP Timestamp . if TS == 1
. .
+...+...+...+...+...+...+...+...+
: IPv4 Type of Service : if TOS == 1
+...+...+...+...+...+...+...+...+
: IPv4 Time To Live : if TTL == 1
+...+...+...+...+...+...+...+...+
: RTP Payload Type : - : if PT == 1
+...+...+...+...+...+...+...+...+
The first bit (0) indicates the extension that is used.
Bormann (ed.) [Page 62]
INTERNET-DRAFT Robust Header Compression June 29, 2000
ID (IPv4 Identification Indication):
This bit indicates if the original IPv4 Indication value is
transmitted in the IPv4 Identification field or the LSB of the
Identification or nothing.
ID=0: No IPv4 Identification
ID=1: 8 bit LSB IPv4 Identification
ID=2: 16 bit IPv4 Identification
ID=3: not used
TS (RTP Timestamp Indication):
This bit indicates if the RTP Timestamp is transmitted. If it is set
to one, one of the following fields are used in the (LSB) RTP
Timestamp field:
+---+---+---+---+---+---+---+---+
| 0 | |
+---+ 15 LSB of RTP Timestamp +
| |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 1 | 0 | |
+---+---+ +
| |
+ 22 LSB of RTP Timestamp +
| |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 | |
+---+---+---+ +
| |
+ 29 LSB of RTP Timestamp +
| |
+ +
| |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | - - - - |
+---+---+---+---+---+---+---+---+
| |
+ +
| |
+ RTP Timestamp +
| |
+ +
| |
+---+---+---+---+---+---+---+---+
TOS (IPv4 Type Of Service Indication):
Bormann (ed.) [Page 63]
INTERNET-DRAFT Robust Header Compression June 29, 2000
This bit indicates the transmission of the IPv4 Type Of Service value
in the IPv4 Type Of Service field.
TTL (IPv4 Time To Live Indication):
This bit indicates the transmission of the IPv4 Time To Live value in
the IPv4 Time To Live field.
PT (RTP Payload Type Indication):
This bit indicates the transmission of the RTP Payload Type value in
the RTP Payload Type field.
E (Extension):
This bit indicates that another extension follows this one.
5.10.3.2.3 Default Delta Extension
The compressor will follow the changes in the RTP Timestamp values
and the IPv4 Identification values, relative to the changes in the
RTP Sequence Number values. To do this a delta value according to the
following equation might be used:
dTS = (TS(n)-TS(n-1)) / (SN(n)-SN(n-1)), with
dTS : delta Timestamp
TS(n) : Timestamp of current packet
TS(n-1) : Timestamp of previous packet
SN(n) : Sequence Number of current packet
SN(n-1) : Sequence Number of previous packet
If the compressor detects that for several packets the delta
timestamp or delta identification value is the same, this delta value
can be used to calculate the timestamp or identification from the
sequence number. To do so, the decompressor has to be informed about
this default delta value. The compressor uses this extension to
signal default delta timestamp (ddTS) or default delta identification
(ddID) values to the decompressor. This extension should be sent in
update packets only. If it is used, a change extension, containing
the timestamp or respectively the identification field must be sent
as well.
The format of the Default Delta Extension is given below:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 0 | - | - | ddTL | ddIDL |
+---+---+---+---+---+---+---+---+
: ddTS : if ddTL > 0
+...+...+...+...+...+...+...+...+
: ddTS : if ddTL > 1
+...+...+...+...+...+...+...+...+
: ddTS : if ddTL > 2
Bormann (ed.) [Page 64]
INTERNET-DRAFT Robust Header Compression June 29, 2000
+...+...+...+...+...+...+...+...+
: ddID : if ddIDL > 0
+...+...+...+...+...+...+...+...+
: ddID : if ddIDL > 1
+...+...+...+...+...+...+...+...+
The first four bits identify this extension.
ddTL (default delta Timestamp Length):
This field indicates the length of the default delta Timestamp field:
ddTL=0: no default delta Timestamp field present
ddTL=1: 1 byte
ddTL=2: 2 byte
ddTL=3: 3 byte
ddIDL (default delta Identification Length):
This field indicates the length of the default delta Identification
field:
ddIDL=0: no default delta Identification field present
ddIDL=1: 1 byte
ddIDL=2: 2 byte
ddIDL=3: not used
5.10.3.3 One-Byte-Header or Two-Byte-Header packet
Packets of these two types are always non-update packets. Since they
only contain parts of the RTP sequence number they can only be sent
in SO state and therefore they are SO packets. They reference the
last update packet and carry the same keyword value.
If the compressor communicated the default delta values to the
decompressor and all changes are regular, the decompressor should be
able to recalculate the identification and timestamp value from the
sequence number. Hence it is not necessary to transmit these values
in all packets.
The One-Byte-Header or Two-Bytes-Header packets cannot be used if
other fields than the sequence number, timestamp and identification
changed. The timestamp and identification also have to change
according to the following equations:
TS(n) = TS(n-1) + (SN(n) - SN(n-1)) * ddTS
ID(n) = ID(n-1) + (SN(n) - SN(n-1)) * ddID
ddTS : default delta Timestamp
ddID : default delta Identification
TS(n) : Timestamp of current packet
TS(n-1) : Timestamp of previous packet
SN(n) : Sequence Number of current packet
SN(n-1) : Sequence Number of previous packet
Bormann (ed.) [Page 65]
INTERNET-DRAFT Robust Header Compression June 29, 2000
ID(n) : Identification of current packet
ID(n-1) : Identification of previous packet
In this state the compressor might use the One-Byte-Header or Two-
Byte-Header packet. These packets contain only the LSB of the RTP
Sequence Number and the keyword, which is enough information for the
decompressor to regenerate the original header.
The packet format for the One-Byte-Header packet is given below:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: MSB of Session CID : if 16 bit CID is used
+...+...+...+...+...+...+...+...+
: LSB of Session CID : if 16 or 8 bit CID is used
+---+---+---+---+---+---+---+---+
| 0 |KW |LSB RTP Sequence Number|
+---+---+---+---+---+---+---+---+
The packet format for the Two-Byte-Header packet is given below:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: MSB of Session CID : if 16 bit CID is used
+...+...+...+...+...+...+...+...+
: LSB of Session CID : if 16 or 8 bit CID is used
+---+---+---+---+---+---+---+---+
| 1 | 0 |KW | |
+---+---+---+
| LSB RTP Sequence Number |
+---+---+---+---+---+---+---+---+
The decision which of these packets is to be used should be done
according the context RTP sequence number. The not transmitted MSB of
the RTP sequence number must not change.
5.10.3.4 Context State packet
This header compression mechanism is aimed to perform good, even if
used over an unreliable channel. Hence bit errors can occur quite
frequently and packets will get lost. If the lost packet was a non-
update packet, this does not effect the decompressor at all, but
reception of a non-update packet with a new keyword, without
receiving an corresponding update packet invalidates the
decompressor's context. From this moment on any compressed packet,
even if it was received correctly, cannot be decompressed, until the
context is updated correctly again.
To minimize the probability of this situation, several successive
update packets should be sent (with the same keyword). But even all
Bormann (ed.) [Page 66]
INTERNET-DRAFT Robust Header Compression June 29, 2000
of these packets might get lost. Hence a mechanism is needed to
inform the compressor about a lost context, to request an update
packet.
To request a context update, the decompressor must send immediately
after detecting an invalid context, a Context State packet. This
packet contains the last correctly received keyword and RTP Sequence
Number. The compressor knows at reception of such a Context State
packet, what information it has to send in the update extension, to
update the decompressor's context correctly.
Another error, that could occur, is the loss of the first packet,
i.e. the Full Header packet. Since most of the header information,
e.g. addresses and ports, are transmitted only in this packet, it is
essential for the decompressor to establish a valid context to
receive this packet. If the decompressor receives a Compressed
packet, with a new session CID, that was not initialized, by a Full
Header packet, this Full Header packet must have been lost. In this
case the decompressor must request a new Full Header packet, by the
means of the Context State packet.
The format of the Context State packet is as follows:
+...+...+...+...+...+...+...+...+
: MSB of Session CID : if 16 bit CID is used
+...+...+...+...+...+...+...+...+
: LSB of Session CID : if 8 or 12 bit CID is used
+---+---+---+---+---+---+---+---+
|FHL|KW | |
+---+---+---+---+---+---+---+---+
: :
+ RTP Sequence Number + if FHL == 0
: :
+...+...+...+...+...+...+...+...+
CID:
The first two bytes can be used for the session CID.
FHL (Full Header Lost):
If this bit is set to one, the first Full Header packet was lost, no
context was established and a new Full Header packet is requested. If
it is set to zero a context update is required and the RTP Sequence
Number of the last correctly decompressed packet is transmitted as
well.
5.10.4 Packet-Profile 2, optimized for non-sequential IPv4
Identification
This section shows five different packets that are used to transmit
the data from the sender to the receiver and signal errors from the
Bormann (ed.) [Page 67]
INTERNET-DRAFT Robust Header Compression June 29, 2000
receiver to the sender. The packet formats are optimised for the use
in an environment, where the IPv4 Identification is not assigned
strictly sequentially for the compressed packet stream. The
identification value is expected to increase by a small random number
(e.g. smaller than 64). The format of the packets is described and it
is explained in detail how the decompressor is able to regenerate the
complete header from the given information. The exact compression
behaviour is implementation specific, but it has to be ensured, that
any decompressor is able to regenerate the complete header in the
described way.
5.10.4.1 Full Header packet
The Full Header packet is sent at the beginning of the session to
establish a valid context, i.e. to transit from Init- to FO state. It
is used exactly as in packet-profile 1 and has the same format (see
section 5.10.3.1 for details).
5.10.4.2 Basic-Compressed packet
The header of the Basic-Compressed packet is divided into a basic
header that is transmitted for every packet of this type and header
extensions that are only used if necessary. As described for the
previous packet-profile, this packet can be used for update packets
(new-keyword flag set to one) or non-update packets. As described
before if no extensions are used, this packet can be sent in SO state
and therefore actually is an SO packet. Else it is an FO packet.
5.10.4.2.1 Basic header
The basic header's format is as follows:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: MSB of Session CID : if 16 bit CID is used
+...+...+...+...+...+...+...+...+
: LSB of Session CID : if 16 or 8 bit CID is used
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 |KW |NKW| M | E |S/I|
+---+---+---+---+---+---+---+---+
: Type : :
+...+...+ Sequence Number & + if S/I==1
: Identification :
+...+...+...+...+...+...+...+...+
: :
: Extension(s) : if E==1
: :
+...+...+...+...+...+...+...+...+
: :
+ UDP Checksum + if non-zero in context
: :
Bormann (ed.) [Page 68]
INTERNET-DRAFT Robust Header Compression June 29, 2000
+...+...+...+...+...+...+...+...+
: CRC :
+---+---+---+---+---+---+---+---+
| RTP Data |
: :
CID:
The first two bytes can be used for the session CIDs.
KW (Keyword):
The Keyword field must be present in every packet. To detect loss of
update packets, it must be changed at each update.
NKW (New Keyword Indication):
If this bit is set, the compressor defines this packet as an update
packet. The context state after decompressing this packet is stored
and referenced in the following packets. Several successive update
packets should be sent, each containing the relevant information, to
ensure the reception at the decompressor. This bit also indicates the
presence of the CRC.
M (RTP Marker):
The M-bit represents the original RTP Marker.
E (Extension):
This bit indicates that at least one extension is used. The different
possible extensions, that are used to transmit information about
irregular changes in the header fields, are described in detail in
the following sections.
S/I (RTP Sequence Number & Identification Indication):
This bit signals that the LSB of the RTP Sequence Number and IPv4
Identification follow directly.
Type:
These two bits indicate how the following bytes are used for the
Sequence Number and Identification:
Type = 0:
7 bit RTP Sequence Number
7 bit IPv4 Identification
Type = 1:
6 bit RTP Sequence Number
16 bit IPv4 Identification
Type = 2:
8 bit RTP Sequence Number
14 bit IPv4 Identification
Type = 3:
10 bit RTP Sequence Number
12 bit IPv4 Identification
UDP Checksum:
Bormann (ed.) [Page 69]
INTERNET-DRAFT Robust Header Compression June 29, 2000
If the UDP Checksum is enabled, this field contains the 16-bit
Checksum, else it is not present.
CRC:
This 8 bit CRC is calculated over the uncompressed header. It is used
to verify the correct transmission of the compressed packet.
5.10.4.2.2 Changing Field Extension
This extension is used similar as in packet-profile one and also has
the same format. For details see section 5.10.3.2.2.
5.10.4.2.3 Default Delta Extension
This extension is used similar as in packet-profile one and also has
the same format. For details see section 5.10.3.2.3.
5.10.4.2.4 Two-Byte-Header or Three-Byte-Header packet
These two packet types can only be used for non-update packets. They
reference the last update packet and therefore carry the same keyword
value. These packets can only be sent in SO state and therefore are
SO packets.
If the compressor communicated the default delta values to the
decompressor, the decompressor should be able to recalculate the
timestamp value from the sequence number. Hence it is not necessary
to transmit this value in all packets.
These packets cannot be used if other fields than the sequence
number, timestamp and identification changed. The timestamp also has
to change according to the following equations:
TS(n) = TS(n-1) + (SN(n) - SN(n-1)) * ddTS
ddTS : delta Timestamp
TS(n) : Timestamp of current packet
TS(n-1) : Timestamp of previous packet
SN(n) : Sequence Number of current packet
SN(n-1) : Sequence Number of previous packet
In this state the compressor might use the Two-Byte-Header or Three-
Byte-Header packet. These packets contain only the LSB of the RTP
Sequence Number, LSB of IPv4 Identification and the keyword, which is
enough information for the decompressor to regenerate the original
header.
The packet format for the Two-Byte-Header packet is given below:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
Bormann (ed.) [Page 70]
INTERNET-DRAFT Robust Header Compression June 29, 2000
: MSB of Session CID : if 16 bit CID is used
+...+...+...+...+...+...+...+...+
: LSB of Session CID : if 16 or 8 bit CID is used
+---+---+---+---+---+---+---+---+
| 0 |KW |LSB RTP Sequence Number|
+---+---+---+---+---+---+---+---+
| LSB IPv4 Identification |
+---+---+---+---+---+---+---+---+
The packet format for the Three-Byte-Header packet is given below:
0 1 2 3 4 5 6 7
+...+...+...+...+...+...+...+...+
: MSB of Session CID : if 16 bit CID is used
+...+...+...+...+...+...+...+...+
: LSB of Session CID : if 16 or 8 bit CID is used
+---+---+---+---+---+---+---+---+
| 1 | 0 |KW | T | |
+---+---+---+---+ +
| LSB RTP Sequence Number |
+ & +
| LSB IPv4 Identification |
+---+---+---+---+---+---+---+---+
The T-bit indicates how the next bits are used to transport the RTP
Sequence Number and the IPv4 Identification:
T=0:
10 bit RTP Sequence Number
10 bit IPv4 Identification
T=1:
8 bit RTP Sequence Number
12 bit IPv4 Identification
The decision which of these packets is to be used should be done
according to the number of packets already sent after the last update
packet (or the first update packet of a set of update packets sent
successively). The not transmitted MSB of these values must not have
changed.
5.10.4.3 Context State packet
The use and format of the context state packet is similar to packet-
profile 1, see section 5.10.3.3 for details.
6. Implementation issues
Bormann (ed.) [Page 71]
INTERNET-DRAFT Robust Header Compression June 29, 2000
This document specifies mechanisms for the protocol, while much of
the usage of these mechanisms is left to the implementers to decide
upon. This chapter is aimed to give guidelines, ideas and suggestions
for implementing the scheme.
6.1. Reverse decompression
This chapter describes an optional decompressor operation to reduce
discarded packets due to an invalid context.
Once a context becomes invalid (e.g., in the case when more
consecutive packet losses than expected has occurred), subsequent
compressed packets cannot be decompressed correctly with normal
decompression operation. This decompression operation aims at
decompressing these packets with a later recovered context. The
decompressor stores them until the context is validated. After the
context is updated, the decompressor tries to recover the stored
packets in the reverse order from the packet updating the context.
Each time the stored packet is decompressed, its correctness is
verified using the header compression CRC, which is transmitted in
each compressed header. Correctly decompressed packets are
transferred to upper layers in the original order.
Note that this reverse decompression introduces buffering while
waiting for the context to be validated and thereby introduces
additional delay. Thus, it should be used only when some amount of
delay could be accepted. For example, for video packets belonging to
the same video frame, the delay of packet arrival time does not cause
presentation time delay. Delay-insensitive streaming applications can
also be tolerant to such delay.
The following illustrates the decompression procedure in some detail:
1. The decompressor stores compressed packets that cannot be
decompressed correctly due to an invalid context.
2. When the decompressor has received a context updating packet and
the context has been validated, it starts to recover the stored
packets in reverse order. Decompression is carried out followed
by the last decompressed packet to its previous packet as if the
two packets were reordered. After that, decompressor checks the
correctness of the reconstructed header using the header
compression CRC.
3. If the header compression CRC indicates a successful
decompression, the decompressor stores the complete packet and
tries to decompress its previous packet. In this way, the stored
packets are recovered from correctly decompressed packets until
no compressed packets are left. For each packet, the decompressor
Bormann (ed.) [Page 72]
INTERNET-DRAFT Robust Header Compression June 29, 2000
checks the correctness of the decompressed headers using header
compression CRC.
4. If the header compression CRC indicates an incorrectly
decompressed packet, the reverse decompression attempt must be
terminated and all remaining packets must be discarded.
5. Finally, the decompressor forwards all the correctly decompressed
packets to upper layers in the original order.
6.2. Pre-verification of CRCs
For reasons of compression efficiency, it is desirable to keep the
size of the header compression CRC as small as possible. However, if
the size of the CRC is decreased, the reliability is also decreased
and erroneous headers could be generated and passed on from the
decompressor. It would then be desirable to find a method of
increasing the strength of the CRC without making it larger.
There is one property of the header compression CRC and its usage
that can be used to achieve this goal. The CRCs that will occur at
the decompressor will in most cases follow a pattern well known also
to the compressor. There are two factors that will affect which CRCs
are generated and in which order they will occur. If the decompressor
makes several reconstruction attempts, the first factor affecting the
CRCs will be the order and properties of the assumptions made for
each reconstruction attempt. The attempts are in general:
1:st attempt: No loss is assumed
2:nd attempt: Loss of the preceding packet is assumed
3:rd attempt: Loss of the two preceding packets is assumed
4:th attempt: Loss of the three preceding packets is assumed
etc.
The other factor that will affect the CRCs generated is what has
really happened to preceding packets, that is, if no loss has
occurred or if one or several preceding packets have been lost
between compressor and decompressor.
Since the compressor knows how the decompressor performs the
reconstruction attempts, the compressor can PRE-CALCULATE and VERIFY
the most probable CRC situations. If a CRC is found not to detect an
erroneous header, then a different packet type with a larger CRC
(such as the "normal" COMPRESSED packet) should be used instead or
additional information could be sent (by using EXTENDED_COMPRESSED or
DYNAMIC packets). To ensure reliability, the important thing is that
the CRC must fail if the header is not correctly reconstructed.
Combining the two factors described above gives a list of the most
probable CRCs that MUST fail.
Bormann (ed.) [Page 73]
INTERNET-DRAFT Robust Header Compression June 29, 2000
- If ONE packet WAS lost, attempt one (no loss) MUST fail
- If TWO packets WERE lost, attempt one (no loss) MUST fail
- If TWO packets WERE lost, attempt two (one lost) MUST fail
- If THREE packets WERE lost, attempt one (no loss) MUST fail
- If THREE packets WERE lost, attempt two (one lost) MUST fail
- If THREE packets WERE lost, attempt three (two lost) MUST fail
- etc.
By doing PRE-CALCULATIONS of the six CRCs that would be the result of
the events listed above, the CRC can be kept strong enough, even with
a reduced size, because CRCs likely to fail will be avoided.
6.3. New reconstruction attempts with LSB and LSP encoding
ROCCO profiles using LSP encoding can handle 25 consecutive packet
losses without invalidating the context. LSB or LSP encoding is also
used for other fields and the range handled is then much larger.
However, for all LSP or LSB decoding, the range can be extended with
multiples by making reconstruction attempts (also called "guesses").
The limiting factors are implementation complexity and time. The
following example shows how this can be done:
In chapter 5.3.2, LSP encoding is described. When an LSP encoded
value for M code-points is decoded to a value S'(n), the original
header can be reconstructed. If the CRC verification fails, a new
reconstruction attempt could be made with S'(n)+M as the sequence
number. If M was a multiple of 2 (LSB encoding), this would be the
same as changing the value of the lowest MSB bit (i.e. the lowest bit
NOT transmitted in LSB). More attempts could then be made increasing
the sequence number by M for each attempt.
Bormann (ed.) [Page 74]
INTERNET-DRAFT Robust Header Compression June 29, 2000
7. Further work
(Editor: This section is _further work_ in particular as it needs to
be integrated into the rest of the document.)
7.1. Compression of IPv6 extension headers
The ROHC scheme defined in this document currently do not support
compression of IPv6 extension headers, which is an undesirable
limitation. Therefore, it is necessary to investigate what is really
needed from the compression scheme regarding compression of
extensions, and also to further develop the scheme to include the
desired extension support.
1. Header Compression for IPv6 Extension Header
The IPv6 extension headers are encoded as a list of items. Each
item is one of the extension headers. The length of each extension
header may vary from each other. When more than one extension header
is used in the same packet, the order of these extension headers is
recommended in RFC 2460, but not mandatory. Thus, although it is
unlikely to happen, the order of the extension headers may vary
during the same session. In addition, one or more extension header
may be added or removed during the session and the content of each
extension header may change. Therefore, the IPv6 extension headers
are classified as a list of items and the item list compression
mechanism can be applied.
The compression of IPv6 extension headers at the list level is
specified in the item list compression scheme in Appendix COMPLIST.
The compressed value of the extension header list is referred to as a
compressed extension header list. The compression of IPv6 extension
headers at the item level, i.e., the compression scheme used for each
type of extension header, is defined in this subsection. The
reference extension header used to compress a given extension header
is the extension header in the reference list that has the same type.
The compressed value of an extension header is referred to as a
compressed extension header.
1.1. IPv6 Extension Header Types
The table below summarizes classification of the various IPv6
extension header fields. HbHH, DOH1, RH, FrH, AH, ESPH, DOH2, BU, BA,
BR, and HA stand for Hop-by-Hop Options Header, Destination Options
Header 1, Routing Header, Fragment Header, Authentication Header,
Encapsulating Security Payload Header, Destination Options Header 2,
Binding Update, Binding Acknowledgement, Binding Request and Home
Address respectively.
+--------+-------------+--------------------------------------+
| Ext. | Static | Non-static |
Bormann (ed.) [Page 75]
INTERNET-DRAFT Robust Header Compression June 29, 2000
| Header | +------------------+-------------------+
| Type | | Essential | Non-Essential |
+--------+-------------+------------------+-------------------+
| HbHH | | | Next Header |
| | | | Hdr Ext Len |
| | | | Options |
+--------+-------------+------------------+-------------------+
| DOH1 | | | Next Header |
| | | | Hdr Ext Len |
| | | | Options |
+--------+-------------+------------------+-------------------+
| RH | | | Next Header |
| | | | Hdr Ext Len |
| | | | Routing Type |
| | | | Segments Left |
| | | | type-specific data|
+--------+-------------+------------------+-------------------+
| RH | | | Next Header |
| | | | Hdr Ext Len |
| | | | Routing Type |
| | | | Segments Left |
| | | | type-specific data|
+--------+-------------+------------------+-------------------+
| FrH | Reserved | Identification | Next Header |
| | Res | Fragment Offset | |
| | | M flag | |
+--------+-------------+------------------+-------------------+
| AH | | Sequence Number | Next Header |
| | | Authentication | Payload Len |
| | | data | SPI |
+--------+-------------+------------------+-------------------+
| ESPH* | | Sequence Number | SPI |
+--------+-------------+------------------+-------------------+
| DOH2 | | | Next Header |
| | | | Hdr Ext Len |
| +----+-------------+------------------+-------------------+
| | BU | Option Type | Sequence Number | Option Length |
| | | Reserved | | A, H, R, D |
| | | | | Prefix Length |
| | | | | Lifetime |
| | | | | Sub-Options |
| +----+-------------+------------------+-------------------+
| | BA | Option Type | Sequence Number | Option Length |
| | | | | Status |
| | | | | Lifetime |
| | | | | Refresh |
| | | | | Sub-Options |
| +----+-------------+------------------+-------------------+
| | BR | Option Type | | Option Length |
| | | | | Sub-Options |
| +----+-------------+------------------+-------------------+
Bormann (ed.) [Page 76]
INTERNET-DRAFT Robust Header Compression June 29, 2000
| | HA | Option Type | | Option Length |
| | | Home Address| | Sub-Options |
+---+----+-------------+------------------+-------------------+
* note: Only the fields that can be compressed are listed.
1.2. Compression of IPv6 Extension Headers at Item Level
For a given extension header in the extension header list, it can
be classified as belonging to one of the three transformation cases
defined in Appendix COMPLIST. Depending on the transformation case,
the correspondent encoding technique is used. Note that the type-
specific data field in the c_item with code "10" and "11" is not
present.
1.2.1 Special Treatment of Next Header Field
The next header field in an extension header changes whenever the
type of the immediately following header changes, e.g., a new
extension header is inserted after it, the immediate subsequent
extension header is removed from the list, or the order of several
extension headers is changed. Thus, in particular, it may not be
uncommon that for a given extension header, only the next header
field changes but the remaining fields don't change. Therefore, the
next header field in each extension header needs to be treated in a
special way.
The classification of the transformation case that an extension
header belongs to should depend on the behavior of the other
remaining fields except the next header field. In the case that only
the next header field changes, the extension header should be
considered as unchanged, and classified as belonging to
transformation case A. In the other case where both the next header
field and some remaining fields change, the compression of the
remaining fields for each type of the extension header is specified
in section 1.2.2. The special treatment of the change of the next
header field is defined as follows.
* In the case that a subsequent extension header is removed from
the list or the order of several extension headers is changed, the
new value of the next header field can be obtained from the reference
extension header list. For example, assume that the reference
extension header list (ref_list) consists of extension header A, B
and C (ref_ext_hdr A, B, C), and the current extension header list
(curr_list) only consists of extension headers A and C (curr_ext_hdr
A, C). The order and value of the next header field of these
extension headers are as follows.
ref_list:
+--------+-----+ +--------+-----+ +--------+-----+
| type B | | | type C | | | type D | |
Bormann (ed.) [Page 77]
INTERNET-DRAFT Robust Header Compression June 29, 2000
+--------+ | +--------+ | +--------+ |
| | | | | |
+--------------+ +--------------+ +--------------+
ref_ext_hdr A ref_ext_hdr B ref_ext_hdr C
curr_list:
+--------+-----+ +--------+-----+
| type C | | | type D | |
+--------+ | +--------+ |
| | | |
+--------------+ +--------------+
curr_ext_hdr A curr_ext_hdr C
Comparing the curr_ext_hdr A in curr_list and the ref_ext_hdr A
in ref_list, the value of next header field is changed from "type B"
to "type C" because of removal of extension header B. The new value
of the next header field in curr_ext_hdr A, i.e., "type C" doesn't
need to be sent to the decompressor, because when the decompressor
detects (by observing the list level encoding) that the immediate
following extension header B is removed from the list, it retrieves
the next header field in ref_ext_hdr B and use it to replace the next
header field in the curr_ext_hdr A.
A similar scheme is used to regenerate the next header field
when the order of several extension headers is changed.
* In the case that a new extension header is inserted after an
existing extension header, the next header field in the new extension
header carries the type of itself, instead of the type of extension
header that follows. For example, assume that the reference extension
header list (ref_list) consists of extension header A and C
(ref_ext_hdr A, C), and the current extension header list (curr_list)
consists of extension header A, B and C (curr_ext_hdr A, B, C). The
order and the value of the next header field of these extension
headers are as follows.
ref_list:
+--------+-----+ +--------+-----+
| type C | | | type D | |
+--------+ | +--------+ |
| | | |
+--------------+ +--------------+
ref_ext_hdr A ref_ext_hdr C
curr_list:
+--------+-----+ +--------+-----+ +--------+-----+
| type B | | | type C | | | type D | |
+--------+ | +--------+ | +--------+ |
| | | | | |
+--------------+ +--------------+ +--------------+
curr_ext_hdr A curr_ext_hdr B curr_ext_hdr C
Bormann (ed.) [Page 78]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Comparing the curr_list and the ref_list, the value of the next
header field in extension header A is changed from "type C" to "type
B".
In the compressed extension header list, the uncompressed
curr_ext_hdr B is carried in the uncompressed data field in c_item or
u_item depending on the list encoding scheme used. However, instead
of carrying the type of the next header (type C) in the next header
field, the type of curr_ext_hdr B (type B) should be carried. When
the decompressor detects (by observing the list level encoding) that
a new extension is inserted after curr_ext_hdr A, it will replace the
old next header field in ref_ext_hdr A with the type of the inserted
extension header, i.e., type B, which is carried in the next header
field in the c_item or u_item for extension header B. At the same
time, the decompressor also replace the next header field in
curr_ext_hdr B with the old value of the next header field in
ref_ext_hdr A, i.e., type C.
1.2.2. Compression of Each Type of Extension Header
In general, the encoding scheme used for each IPv6 extension
header is similar to the scheme used for IPv4 and IPv6 base header,
although the compressed format for each type of extension header may
be different for each header. In this section, the format of the
compressed data field in c_item or uc_item is defined for each type
of extension header. Note that the non-essential fields discussed in
the following subsections don't include the next header field.
1.2.2.1. Hop-by-Hop Options Header and Destination Options Header 1
The hop-by-hop options header (HbHH) and the destination option
header 1(DOH1, the header processed by the first destination that
appears in the Ipv6 Destination Address field plus subsequent
destinations listed in the Routing header) are expected to rarely
change from packet to packet during the session. However, if any
change happens to any field in these two headers, the correspondent
compressed extension header is sent.
The compressed HbHH consists of a bit mask that indicates the
presence of the changed field, and the corresponding field value. The
compressed DOH1 has the same structure as the compressed HbHH. The
meaning of each field in the compressed HbHH is also the same as for
the compressed DOH1. Therefore, in this subsection, only the
compressed HbHH is discussed.
The structure of compressed HbHH is as follows.
+---+---
+:::::::::::::+::::::::::::::::::::::::+
Bormann (ed.) [Page 79]
INTERNET-DRAFT Robust Header Compression June 29, 2000
compressed HbHH: | L | O | Hdr Ext Len | Compressed Option List
|
+---+---
+:::::::::::::+::::::::::::::::::::::::+
* L bit indicates the presence of the Hdr Ext Len field that
carries the value of Hdr Ext Len in the current HbHH.
* O bit indicates the presence of the Compressed Option List field
that carries the compressed value of the Options field.
The Options field in HbHH is encoded as a list of options, and
each option is considered as an item. The Options field can be
compressed using the generic item list compression scheme specified
in Appendix COMPLIST at the list level. At the item level, the format
of the compressed option depends on the type of the option.
1.2.2.2. Routing Header
The content of the Routing Header (RH) is expected to rarely
change from packet to packet during the session. However, if any
change happens to any field in RH, a compressed RH is sent.
The structure of the compressed RH is as follows.
+---------------+:::::::::::::+::::::::::::::+
compressed RH: | L | T | S | T | Hdr Ext Len | Routing Type |
+---------------+:::::::::::::+::::::::::::::+
:::::::::::::::+:::::::::::::::::::::::::::::::::::::::::::::::::+
Segments Left | type-specific data (compressed or uncompressed) |
:::::::::::::::+:::::::::::::::::::::::::::::::::::::::::::::::::+
The 4-bit bit mask indicates which fields are present.
* L bit - Hdr Ext Len
* T bit - Routing Type
* S bit - Segments Left
* T bit - type-specific data
The Hdr Ext Len, Routing Type and Segments Left fields are all
sent uncompressed. The type-specific data can be sent compressed or
uncompressed. The type 0 routing header can be compressed using the
scheme specified below and for any other unknown type of routing
header, the type-specific data field should be sent uncompressed.
1.2.2.2.1. Compression of Type-specific Data Field in Type 0 Routing
Header
The type-specific data field in the type 0 routing header consists
of Reserved field and a list of 128-bit addresses. The Reserved field
is not expected to change and doesn't need to be sent in the
compressed type-specific data field. The list of addresses is encoded
Bormann (ed.) [Page 80]
INTERNET-DRAFT Robust Header Compression June 29, 2000
as an item list and can be compressed using the scheme defined in
Appendix COMPLIST. The structure of compressed type-specific data
fields in the type 0 routing header is as follows.
compressed type-specific data field in type 0 routing header:
+---+----------------------------------------+
| C | compressed / uncompressed address list |
+---+----------------------------------------+
C bit indicates the type of the following field. "0" indicates
that the uncompressed address list is carried in the following field,
while "1" indicates the compressed address list is carried. The
decision of which format to use is up to the compressor. An example
of the criteria could be compression efficiency or processing
complexity.
As mentioned before, the address list can be compressed using the
scheme defined in Appendix COMPLIST. Each address in the address list
is considered as an item. The insertion and removal scheme defined in
Appendix COMPLIST can be used to encode the change.
1.2.2.3. Fragment Header
If the fragment header (FrH) is present, its contents are expected
to change from packet to packet. To address the change, a compressed
FrH is sent.
The structure of the compressed FrH is as follows.
+-----------------+--------+----------------------
-----+
compressed FrH: | Fragment Offset | M flag | compressed
Identification |
+-----------------+--------+----------------------
-----+
The Fragment Offset and M flag fields in the compressed FrH are
copies of the same fields in the original FrH. The compressed
Identification field carries the compressed value of the
Identification field in the original FrH, using the Identification
field in the reference FrH as the reference. The scheme used to
compress and encode Identification field is VLE as defined in [ACE].
The format of compressed Identification using VLE is listed as
follows.
- "0" + 4-bit LSB
- "10" + 8-bit LSB
- "110" + 16-bit LSB
- "111" + 32-bit LSB
1.2.2.4. Authentication Header and Encapsulating Security Payload
Header
Bormann (ed.) [Page 81]
INTERNET-DRAFT Robust Header Compression June 29, 2000
In the Authentication Header (AH), the SPI field only changes when
a new security session is established, thus, it is expected to rarely
change from packet to packet during the session. The Payload Len
field changes only when SPI changes. Two change cases are listed as
follow.
* In the case that the SPI field changes, all the fields in AH may
change. For simplicity, an uncompressed AH is sent.
* In the case that no change happens to the SPI field, the AH is
not considered as changed. When the decompressor detects from the
encoding that the AH is not changed, it copies the SPI and Payload
Len fields from the reference AH. The other two fields in AH -
sequence number and authentication data, are handled as defined
below.
The sequence number field in the AH contains a monotonically
increasing counter value for a security association. Like IP-ID in
Ipv4, if one observes only one of the flows, the sequence number in
AH may appear to be nonlinear due to disruption by other IP flows
that also use the same security association. If the sequence number
in the AH linearly increases, it doesn't need to be sent. The
decompressor regenerates this field by applying linear extrapolation
(with delta = 1). Otherwise, a compressed sequence number should be
sent in a compressed IP/UDP/RTP header. The format of the compressed
IP/UDP/RTP header containing the compressed sequence number should be
defined in ROHC. The compression scheme for the sequence number in
the AH is VLE, as defined in [ACE].
The authentication data field in AH changes from packet to
packet and should be sent in every packet. If the uncompressed AH is
sent, the authentication data field is sent inside the uncompressed
AH; otherwise, it is sent after the compressed IP/UDP/RTP and IPv6
extension headers and before the payload.
If Encapsulating Security Payload Header (ESP) is used, the UDP
and RTP headers are both encrypted and cannot be compressed. In this
case, special compressed packet format needs to be defined in ROHC.
In ESP, the only fields that can be compressed are the SPI and the
sequence number. If SPI field changes, the uncompressed ESP is sent;
otherwise, a compressed ESP that carries all the fields except SPI
and sequence number is sent. The sequence number in ESP has the same
behavior as the same field in AH, thus, they are compressed in the
same manner.
1.2.2.5. Destination Options Header 2
The Destination Option Header 2 (DOH2) is for options to be
processed only by the final destination of the packet. When ESP is
used to provide security services, the DOH2 is encrypted and cannot
Bormann (ed.) [Page 82]
INTERNET-DRAFT Robust Header Compression June 29, 2000
be compressed. Otherwise, the following compression mechanisms can
be applied.
DOH2 contains Hdr Ext Len and Options fields. If any change
happens to any fields in DOH2, a compressed DOH2 is sent.
The structure of the compressed DOH2 is as follows.
+-------------+-------------------------+
compressed DOH2: | Hdr Ext Len | compressed options list |
+-------------+-------------------------+
The Hdr Ext Len in the compressed DOH2 is a copy of the same field
in the original DOH2. The compressed options list field carries the
compressed value of the options field. Multiple options can be
included in the options field. Assuming that the number of options in
the options field in DOH2 is n, the structure of compressed options
list field is as follows.
+------------+------------+-----+------------+
compressed options: | c_option 1 | c_option 2 | ... | c_option n |
+------------+------------+-----+------------+
The i-th compressed option (c_option i) in the compressed options
list carries the compressed or uncompressed value of the i-th option
in the options field in DOH2. The structure of c_option is defined as
follows.
+-------------+---+----------------------------------+
c_option: | Option Type | C | compressed / uncompressed option |
+-------------+---+----------------------------------+
* Option Type is the copy of the same field in the uncompressed
option. Four destination options - Binding Update (BU), Binding
Acknowledgement (BA), Binding Request (BR) and Home Address (HA) have
been defined in mobile IPv6.
* C bit = "0" indicates the all the fields in the option except
the Option Type are sent, while C bit = "1" indicates the compressed
option is followed. The decision of sending compressed option or
uncompressed option as well as the format of the compressed option
for BU, BA, BR and HA are defined in the following subsections. For
any other unknown type of options, the uncompressed value is always
sent.
Since each of the aforementioned four options follows a certain
pattern individually, but is not sent in every packet, an individual
context for each type of option should be established and maintained
by the compressor and the decompressor. The linkage between these
individual contexts and the context maintained for IP base header and
the UDP/RTP header could be the RTP sequence number. In addition, an
individual compression state is maintained for each option. Unlike
Bormann (ed.) [Page 83]
INTERNET-DRAFT Robust Header Compression June 29, 2000
the compression states used for IP base header and RTP/UDP headers,
only two compression states are defined for these four options -
original state and compressed state. In the original state, the
original value of the option is sent, while in the compressed state,
the compressed value of the option is sent.
1.2.2.5.1. Home Address Option (HA) and Binding Request Option (BR)
At the beginning, the compressor stays in the original state and
sends uncompressed HAs. When the decompressor receives an
uncompressed HA, it restores the static fields, i.e., the option Type
field and the Home Address field, and then acknowledges the received
packet. After receiving an acknowledgement for the packet that
carries the HA, the compressor switches to the compressed state for
HA. When the decompressor receives a compressed HA, it retrieves the
static fields from storage. The sub-option field (if present) and the
Option Len field can be obtained from the compressed HA.
The structure of compressed HA is defined as follows.
+---+::::::::::::+::::::::::::+
compressed HA: | S | Option Len | sub-option |
+---+::::::::::::+::::::::::::+
S bit indicates whether or not sub-option is present. If it is
present, both the Option Len and sub-option fields should be sent
uncompressed and the S bit is set to "1". Otherwise, S bit is set to
"0" and no other fields needs to be sent in the compressed HA. In the
second case, the decompressor regenerates the Option Len field as 16.
BR option can also be sent compressed or uncompressed. The
compression scheme for BR option is similar to that of HA option.
The structure of compressed BR is the same as the structure of
compressed HA. The only difference is in the case that the sub-option
field is not present, the decompressor assigns 0 to the Option Len
field.
1.2.2.5.2. Binding Update Option (BU) and Binding Acknowledgement
Option (BA)
BU and BA options are not sent in every packet. For example, BU
option is only sent when the mobile node changes its care-of address
or it observes that its entry in the binding cache at the
correspondent node doesn't exist or may expire soon. Since these
options are not sent frequently, to keep a simple compression and
decompression logic, these options can be sent uncompressed whenever
they are present.
However, to obtain higher compression efficiency, these options
can be sent compressed at the price of more complicated logic and a
higher memory requirement.
Bormann (ed.) [Page 84]
INTERNET-DRAFT Robust Header Compression June 29, 2000
To compress the current BU option, a BU that was sent previously
and has been acknowledged by the decompressor is used as the
reference. Since the BU option is not sent in every packet, the
reference header used to compress the base IPv6 header and the
UDP/RTP header may not be able to be used as the reference for BU
option because it may not contain a BU option. Therefore, a separate
reference needs to be maintained for BU option.
The reference for BU can be selected based on the acknowledgement.
When the decompressor receives a packet containing BU, it inserts the
BU into the sliding window (refer to [ACE]) in the individual BU
context, and acknowledges the packet. After the compressor receives
the acknowledgement, it updates the reference to be used for BU.
When the BU is present in the packet the next time, the new
reference is used to compress the BU. To identify the reference BU,
an identifier for BU (BU_ref_id) is needed. The sequence number field
in BU option increments (not necessary strictly by 1) from packet to
packet and can be used as the BU_ref_id. The BU_ref_id is carried in
the compressed BU header.
When the decompressor receives a compressed BU header, it
retrieves the reference BU from the sliding window and use it to
decompress the BU option. The decompressor also shrinks the sliding
window by removing all the BUs before the reference BU.
The structure of the compressed BU is as follows.
+-----------+---------------+-------------+--------
-+
compressed BU: | BU_ref_id | A | H | R | D | L | PL | LT | SP | SC
|
+-----------+---------------+-------------+--------
-+
:::::::::::::::+:::::::::::::::+----------------------------+
Option Length | Prefix Length | Compressed Sequence Number |
:::::::::::::::+:::::::::::::::+----------------------------+
:::::::::::::::::::::+:::::::::::::+
Compressed Lifetime | Sub-Options |
:::::::::::::::::::::+:::::::::::::+
The A, H, R, D bits are copied from the original BU. The
subsequent bit mask indicates the presence of the field that is
changed. The mapping of the bit mask and the subsequent changing
fields is as follows. A "1" in the bit mask means the correspondent
field is present.
- L bit: Option Length
Bormann (ed.) [Page 85]
INTERNET-DRAFT Robust Header Compression June 29, 2000
- PL bit: Prefix Length
- LT bit: Lifetime
Among the above three fields, only the Lifetime field can be sent
compressed if it changes. All the other fields should be sent
uncompressed. The compression scheme used for Lifetime field is VLE
as defined in [ACE]. The format of compressed Lifetime is the same as
the format for compressed Identification in Fragment Header, which is
defined in 1.2.3.3.
The SP and SC bits are used for compression of the sub-options
field. SP bit indicates the presence of sub-options field. If it is
present, the SC bit indicates whether or not the sub-options field
can be sent compressed. If the sub-options field in the current BU is
not the same as the sub-options field in the reference BU, SC bit is
set to "0" and the uncompressed value of the sub-options field is
sent. Otherwise, SC bit is set to "1" and sub-options field is not
sent.
The sequence number in the BU should be sent all the time. Its
compressed value is carried in the compressed sequence number field.
The compression scheme for sequence number is VLE, as defined in
[ACE]. The format of the compressed sequence number is as follow.
- "0" + 4-bit LSB
- "10" + 8-bit LSB
- "11" + 16-bit LSB
The compression scheme for BA option is exactly the same as the
scheme defined for BU option. The format for the compressed BA is as
follows.
+-----------+-----------------+---------+
compressed BA: | BA_ref_id | L | ST | LT | R | SP | SC |
+-----------+-----------------+---------+
:::::::::::::::+::::::::+----------------------------+
Option Length | Status | Compressed Sequence Number |
:::::::::::::::+::::::::+----------------------------+
:::::::::::::::::::::+::::::::::::::::::::+:::::::::::::+
Compressed Lifetime | Compressed Refresh | Sub-Options |
:::::::::::::::::::::+::::::::::::::::::::+:::::::::::::+
BU_ref_id is used to identify the reference BA. The sequence
number field in BA option increments (not necessary strictly by 1)
from packet to packet and can be used as the BA_ref_id.
The mapping of the bit mask and the subsequent changing fields is
as follows.
Bormann (ed.) [Page 86]
INTERNET-DRAFT Robust Header Compression June 29, 2000
- L bit: Option Length
- S bit: Status
- LT bit: Lifetime
- R bit: Refresh
Among the above four fields, Lifetime and Refresh fields can be
sent compressed if they change. The other two fields should be sent
uncompressed. The compression scheme used for Lifetime field or
Refresh field is VLE as defined in [ACE]. The format for compressed
Lifetime and compressed Refresh is the same as the format for
compressed Identification in Fragment Header, which is defined in
1.2.3.3.
The sequence number in BA has the same behavior as the sequence
number in the BU, thus, it is compressed in the same manner.
7.2. Efficient compression of CSRC lists
The Contributing Source (CSRC) List in a RTP header contains the
Synchronization Source (SSRC) identifiers of the contributing sources
for the payload in current packet.
A CSRC list contains at most 15 identifiers, due to the 4-bit size of
CSRC Count (CC) field in RTP header. Each 32-bit identifier is
chosen randomly by the original synchronization source so that it is
globally unique within an RTP session.
The compression scheme introduced here will utilize the facts
mentioned above. To maintain transparency, the order of identifiers
is preserved during compression. In other words, the CSRC list is
really compressed as a list, not as a set.
7.2.1. Data Structure and Algorithm
The scheme is essentially reference based compression. (Refer to
Appendix COMPLIST for general discussion on list compression). The
reference CSRC list (ref_CSRC) could be the CSRC list in the last
acknowledged RTP header.
Four encoding formats are provided in this scheme, which are
differentiated by the Encoding Type (ET) value. The compressor will
choose the most efficient one based on the change from the ref_CSRC
to the current CSRC list (cur_CSRC).
7.2.2. Generic
Bormann (ed.) [Page 87]
INTERNET-DRAFT Robust Header Compression June 29, 2000
This format can handle any change from the ref_CSRC to the cur_CSRC.
However, it should be used only if the change cannot be handled
efficiently by the formats described in the following sections.
Below is the format of a compressed CSRC list (comp_CSRC). Note that
the ref_CSRC is identified by the RTP SN of the RTP header in which
it was carried.
+---------+--------+--------+----------+------+----------+
| ET = 00 | ref_SN | cur_CC | c_item 1 | .... | c_item n |
+---------+--------+--------+----------+------+----------+
ET: 2 bits
ref_SN: could be uncompressed (16 bits), or compressed (a few LSBs),
depending on the ROHC compression of RTP SN
cur_CC: 4 bits, the number of c_items
Each c_item above has one of the following structures:
a)
+---+-----+
| 0 | pos |
+---+-----+
This indicates that an SSRC at position pos in the ref_CSRC is also
present in cur_CSRC. Note the length of the pos field needs not to be
sent explicitly, since it can be determined by both compressor and
decompressor as ceil(log2(k)), where k is the number of SSRCs in the
ref_CSRC.
b)
+---+------+
| 1 | SSRC |
+---+------+
This indicates a new SSRC is present in current CSRC list. Note the
new SSRC itself is not compressed due to its random nature.
After receiving a comp_CSRC, the decompressor 1) fetches the ref_CSRC
from its context, 2) scans the c_item list in the received comp_CSRC
and builds the cur_CSRC item by item, and 3) copies the value of
cur_CC into the CC field in the decompressed RTP header.
7.2.3. Insertion Only
If the change from the ref_CSRC to cur_CSRC only involves addition of
new SSRCs (i.e., no order change, no deletion), a more efficient
format can be used.
Bormann (ed.) [Page 88]
INTERNET-DRAFT Robust Header Compression June 29, 2000
For example, this format is efficient in handling the event that a
new party or parties join speaker becomes active in a conference
call.
+---------+--------+--------+-------+-----+-------+
| ET = 01 | ref_SN | add_CC | pos 1 | ... | pos n |
+---------+--------+--------+-------+-----+-------+
--------+-----+--------+
SSRC 1 | ... | SSRC n |
--------+-----+--------+
ET: 2 bits
ref_SN: same as in generic format
add_CC: 4 bits, the number of new SSRCs present in this comp_CSRC.
After receiving a comp_CSRC with ET = 01, the decompressor will
insert the new SSRC_i right before position pos_i in the ref_CSRC.
Note that the length of pos fields is now equal to ceil(log2(k+1)),
where k is the number of SSRCs in the ref_CSRC. The extra one is
needed since the insertion could happen at both the head and the tail
of the list.
7.2.4. Deletion Only
This format is optimized for the case that the change from ref_CSRC
to the cur_CSRC only involves removal of some SSRC(s) in the
ref_CSRC. For example, it can be used when a party or parties leave a
conference call.
+---------+--------+--------+-------+-----+-------+
| ET = 10 | ref_SN | del_CC | pos 1 | ... | pos m |
+---------+--------+--------+-------+-----+-------+
ET: 2 bits
ref_SN: same as in generic format
del_CC: the number of SSRCs should be deleted from ref_CSRC.
length = log2(k), where k is the number of SSRCs in
the ref_CSRC.
After receiving such a comp_CSRC, the decompressor will fetch the
ref_CSRC, then remove each SSRC whose position is listed in the
comp_CSRC.
The length of pos fields are determined in the same way as the
generic format.
Bormann (ed.) [Page 89]
INTERNET-DRAFT Robust Header Compression June 29, 2000
7.2.5. Insertion and Deletion Only
The following format can handle the case where both insertion and
deletion of SSRCs happen, but there is no order change. Note that
the generic format could be more efficient if the change is
significant compared with the size of cur_CSRC, and thus should be
used instead.
+---------+--------+--------+-------+-----+-------+
| ET = 11 | ref_SN | del_CC | pos 1 | ... | pos m |
+---------+--------+--------+-------+-----+-------+
---------+-------+-----+-------+--------+-----+--------+
add_CC | pos 1 | ... | pos n | SSRC 1 | ... | SSRC n |
---------+-------+-----+-------+--------+-----+--------+
ET: 2 bits
ref_SN: same as in generic format
del_CC: same as in the deletion only fomrat
add_CC: 4 bits, the number of new SSRCs
This case can be considered as two combined transformations. First,
deletion (section X.2.3) is applied to ref_CSRC as identified by the
ref_SN. Let's call the resulted CSRC list mid_CSRC. Then, insertion
(section X.2.2) is applied to mid_CSRC. Therefore, each pos in the
deletion part refers a position in ref_CSRC, while each pos in the
insertion part indexes into the mid_CSRC.
7.3. Tunneling
7.3.1. Header Compression for IPv4 Tunneling Header
In order to route the packets to the mobile node that is on a
foreign link, the home agent of the mobile node may encapsulate the
original packet into an IP header and tunnel the packet to the care-
of address of the mobile node. In the case of foreign agent care-of
address in Mobile IPv4, the tunneling header in each tunneled packet
will be removed by the foreign agent before transferring it to the
mobile node through the air interface; therefore there is no need for
compression of tunneling header. In the case that mobile node uses
collocated care-of address, the tunneled packet will be sent to
mobile station through air interface, and compression needs to be
applied to the tunneling header.
7.3.1.1. Mobile IPv4 Tunneling Header Fields Type
The table below summarizes classification of the various fields
defined in different tunneling headers used in Mobile IPv4. In the
column of Encapsulation Scheme (Enc. Scheme), three encapsulation
Bormann (ed.) [Page 90]
INTERNET-DRAFT Robust Header Compression June 29, 2000
methods are included - IP in IP Encapsulation (IIE), Minimum
Encapsulation (ME), Generic Routing Encapsulation (GRE).
(Editor's note: Harmonize with the way this is described in ROHC
document)
+------+------+---------+---------------------------------+
|Enc. |Header| Static | Non-static |
|Scheme|type | +-----------+---------------------+
| | | | Essential | Non-Essential |
+------+------+---------+-----------+---------------------+
| IIE |inner | same as in the table in Appendix A |
| |header| in ACE Internet Draft |
| +------+-------------------------------------------+
| |outer | same as in the table in Appendix A |
| |header| in ACE Internet Draft |
+------+------+-------------------------------------------+
| ME |IP | same as in the table in Appendix A |
| |header| in ACE Internet Draft |
| +------+----------+----------+---------------------+
| |Mini. | Protocol | | S bit |
| |Fw. | | | Header Checksum |
| |header| | | Original Dest. Addr.|
| | | | | Original Src. Addr. |
+------+------+----------+----------+---------------------+
| GRE |inner | same as in the table in Appendix A |
| |header| in ACE Internet Draft |
| +------+-------------------------------------------+
| |outer | same as in the table in Appendix A |
| |header| in ACE Internet Draft |
| +------+----------+----------+---------------------+
| |GRE | Protocol | Sequence | C, R, K, S, s bits |
| |header| Ver | number | Recur |
| | | | | Flags |
| | | | | Checksum |
| | | | | Offset |
| | | | | Key |
| | | | | Routing |
+------+------+----------+----------+---------------------+
7.3.1.2. Compression of Tunneling Headers in MIPv4
Three encapsulation schemes have been specified in MIPv4. For
different encapsulation scheme, the compression methods are different
from each other.
7.3.1.2.1. IP in IP Encapsulation in IPv4
Using IP in IP Encapsulation, the original inner IP header is not
modified at all and therefore can be compressed as if it is not
Bormann (ed.) [Page 91]
INTERNET-DRAFT Robust Header Compression June 29, 2000
encapsulated. The outer header is compressed at the IP level, while
the inner header is compressed as defined in ROHC.
7.3.1.2.2. Minimum Encapsulation in IPv4
With Minimum Encapsulation, the original IP header is modified and
the Minimal Forwarding Header is inserted between the modified IP
header and the original IP payload. The modified IP header plus the
the UDP/RTP headers is compressed as defined in ROHC.
The compression scheme for the Minimal Forwarding Header is
similar to the scheme applied to the IP header. The static and
changing non- essential fields in the Minimum Forwarding Header are
sent in the Full Header and Refresh state. When any change happens to
any non-essential field in the Minimum Forwarding Header, a
compressed header with a bit mask indicating the change should be
sent.
7.3.1.2.3. Generic Routing Encapsulation in IPv4
With Generic Routing Encapsulation, the original IP packet is
encapsulated in an outer IP header. A GRE header is inserted between
the inner header and the outer header. The original IP/UDP/RTP header
is compressed as if there is no encapsulation. The outer IP header is
compressed at the IP level.
The compression scheme for the GRE header is similar to the scheme
applied to the IP header. All the static and changing non-essential
fields in the GRE header are sent in the Full Header and refresh
state. When any change happens to any non-essential field in the GRE
header, a compressed header with a bit mask indicating the change
should be sent. If the sequence number in the GRE header is present,
the scheme to compress sequence number could be VLE, as defined in
ACE draft.
7.4. RTCP
RTCP is the RTP Control Protocol, [RTP]. RTCP is based on periodic
transmission of control packets to all participants in a session,
using the same distribution mechanism as for data packets. Its
primary function is to provide feedback from the data receivers on
the quality of the data distribution. The feedback information may be
used for issues related to congestion control functions, and directly
useful for control of adaptive encodings.
In an RTP session there will be two types of packet streams; one with
the RTP-header and application data, and a second stream with the
RTCP control information. The difference between the streams at the
transport level is the UDP port numbers, which is plus one for RTCP.
Bormann (ed.) [Page 92]
INTERNET-DRAFT Robust Header Compression June 29, 2000
The question is how should ROHC header compressor handle the RTCP
stream.
a) One compressor/decompressor entity for both streams and carried on
the same channel using CIDs to distinguish between them. Although
they could share some parts of their contexts. Hence, on the RTCP
stream IP/UDP compression might be utilized.
b) One compressor/decompressor entity for both streams and carried on
the same channel, but without using CIDs to distinguish between them.
To avoid unnecessary extra overhead a packet type, or some other
method, can be used to tell that this compressed packet carries RTCP
data and not RTP.
c) Two compressor/decompressor entities, one for RTP and another one
for RTCP, and the streams carried on their own channel. This means
that they will not share the same CID number space.
7.5. non-RTP UDP traffic
(Editor's note: This is text from draft-koren-avt-crtp-enhance-01.txt
to be added to rohc _ not yet consistent with the rest of the
document)
2.1 The negative cache stream flag
Certain streams, known or suspected to not be RTP, can be placed in a
"negative cache" at the compressor, so only the IP and UDP headers
are compressed. It is beneficial to notify the decompressor that the
compressed stream is in the negative cache: for such streams the
context is shorter - there is no need to include the RTP header, and
all RTP-related calculations can be avoided.
In this enhancement, a new flag bit "N" is added to the FULL_HEADER
packet that initializes a context at the decompressor. The bit
occupied by the new flag was previously always set to zero. If the N
flag is set to 1, this indicates that no COMPRESSED_RTP packets will
be transmitted in this context. This flag is only an optimization
and the decompressor may choose to ignore it.
Format of the FULL_HEADER length fields with the negative cache flag:
For 8-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |N| seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N=1: negative cache stream
Bormann (ed.) [Page 93]
INTERNET-DRAFT Robust Header Compression June 29, 2000
For 16-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 |N| seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N=1: negative cache stream
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2 Reject a new compressed stream
In a point to point link the two nodes can agree on the number of
compressed sessions they are prepared to support for this link. In an
end-to-end scheme a host may have compressed sessions with many hosts
and eventually may run out of resources. When the end-to-end tunnel
is negotiated, the number of contexts needed may not be predictable.
This enhancement allows the negotiated number of contexts to be
larger than could be accommodated if many tunnels are established.
Then, as context resources are consumed, an attempt to set up a new
context may be rejected.
The compressor initiates a compression of a stream by sending a
FULL_HEADER packet. Currently if the decompressor has insufficient
resources to decompress the new stream, it can send a CONTEXT_STATE
packet to invalidate the newly compressed stream. The compressor does
not know the reason for the invalidation: usually this happens when
the decompressor gets out of synchronization due to packet loss. The
compressor will most likely reattempt to compress this stream by
sending another FULL_HEADER.
This enhancement specifies that the decompressor may reject the
compression of a stream by sending a REJECT message to the
compressor. A REJECT message tells the compressor to stop compressing
this stream.
The REJECT message is a CONTEXT_STATE message with an additional
flag:
Type code = 1 :CONTEXT_STATE for 8-bit CID streams
Type code = 2 : CONTEXT_STATE for16-bit CID streams
Here is the format of CONTEXT_STATE packets with REJECT flags:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Type code=1: CS, 8-bit CID |
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
Bormann (ed.) [Page 94]
INTERNET-DRAFT Robust Header Compression June 29, 2000
| session context ID |
+---+---+---+---+---+---+---+---+
| 1 |R=1| 0 | 0 | sequence | R is the REJECT flag
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
. . .
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| 1 |R=1| 0 | 0 | sequence | R is the REJECT flag
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Type code=2: CS, 16-bit CID|
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| 1 |R=1| 0 | 0 | sequence | R is the REJECT flag
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
. . .
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| 1 |R=1| 0 | 0 | sequence | R is the REJECT flag
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
The session CID, sequence and generation are taken from the
FULL_HEADER.
The compressor may decide to wait for a while before attempting to
compress additional streams destined to the rejecting host.
Bormann (ed.) [Page 95]
INTERNET-DRAFT Robust Header Compression June 29, 2000
8. Implementation status
(Editor: I don't think we need this section. We might want an
_implementation notes_ section at one point.)
9. Security considerations
Because encryption eliminates the redundancy that header compression
schemes try to exploit, there is some inducement to forego encryption
in order to achieve operation over low-bandwidth links. However, for
those cases where encryption of data (and not headers) is sufficient,
RTP does specify an alternative encryption method in which only the
RTP payload is encrypted and the headers are left in the clear. That
would still allow header compression to be applied.
A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the
original packets but still have valid IP, UDP and RTP headers and
possibly even valid UDP checksums. Such corruption may be detected
with end-to-end authentication and integrity mechanisms which will
not be affected by the compression. Further, this header compression
scheme provides an internal checksum for verification of re-
constructed headers. This reduces the probability of producing
decompressed headers not matching the original ones without this
being noticed.
Denial-of-service attacks are possible if an intruder can introduce
(for example) bogus STATIC, DYNAMIC or FEEDBACK packets onto the link
and thereby cause compression efficiency to be reduced. However, an
intruder having the ability to inject arbitrary packets at the link
layer in this manner raises additional security issues that dwarf
those related to the use of header compression.
TBW: Header compression and IPsec
10. Acknowledgements
When designing this protocol, earlier header compression ideas
described in [CJHC], [IPHC] and [CRTP] have been important sources of
knowledge.
Thanks to Takeshi Yoshimura at NTT DoCoMo for providing the reverse
decompression chapter (chapter 6.3). Thanks also to Anton Martensson
for many valuable draft contributions and to Andreas Jonsson (Lulea
University), who made a great job supporting this work in his study
of header field change patterns. Thanks also to all others who have
given comments.
Bormann (ed.) [Page 96]
INTERNET-DRAFT Robust Header Compression June 29, 2000
11. Intellectual property considerations
(Editor's note: this section will go to www.ietf.org/ipr and be
replaced by the standard reference to that, but for now it is left in
the draft to simplify working on it.)
This proposal in is conformity with RFC 2026.
Telefonaktiebolaget LM Ericsson and its subsidiaries, in accordance
with corporate policy, will for submissions rightfully made by its
employees which are adopted or recommended as a standard by the IETF
offer patent licensing as follows:
If part(s) of a submission by Ericsson employees is (are) included in
a standard and Ericsson has patents and/or patent application(s) that
are essential to implementation of such included part(s) in said
standard, Ericsson is prepared to grant - on the basis of reciprocity
(grant-back) - a license on such included part(s) on reasonable, non-
discriminatory terms and conditions.
For the avoidance of doubt this general patent licensing undertaking
applies to this proposal.
Nokia has filed patent applications that might possibly have
technical relation to this contribution.
Matsushita has filed patent applications that might possibly have
technical relation to this contribution.
If part(s) of the contribution by Matsushita employee is (are)
included in a standard and Matsushita has patents and/or patent
application(s) that are essential to implementation of such included
part(s) in said standard, Matsushita is prepared to grant - on the
basis of reciprocity (grantback) - a license on such included part(s)
on reasonable, non-discriminatory terms and conditions (in according
with paragraph 10.3.3 of the RFC 2026).
Bormann (ed.) [Page 97]
INTERNET-DRAFT Robust Header Compression June 29, 2000
12. References
[UDP] Jon Postel, "User Datagram Protocol", RFC 768, 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, 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), December 1999.
<draft-degermark-crtp-cellular-01.txt>
[REQ] Mikael Degermark, "Requirements for robust IP/UDP/RTP header
compression", Internet Draft (work in progress), June 2000.
<draft-ietf-rohc-rtp-requirements-01.txt>
[LLG] Krister Svanbro, "Lower Layer Guidelines for Robust Header
Compression", Internet Draft (work in progress), May 2000.
<draft-ietf-rohc-lower-layer-guidelines-00.txt>
[CELL] Lars Westberg, Morgan Lindqvist, "Realtime traffic over
cellular access networks", Internet Draft
(work in progress), May 2000.
<draft-westberg-realtime-cellular-02.txt>
[WCDMA] "Universal Mobile Telecommunications System (UMTS);
Selection procedures for the choice of radio transmission
technologies of the UMTS (UMTS 30.03 version 3.1.0)".
ETSI TR 101 112 V3.0.1, November 1997.
Bormann (ed.) [Page 98]
INTERNET-DRAFT Robust Header Compression June 29, 2000
13. Authors' addresses
Carsten Bormann Tel: +
Fax: +
EMail:
Lars-Erik Jonsson Tel: +46 920 20 21 07
Ericsson Erisoft AB Fax: +46 920 20 20 99
SE-971 28 Lulea, Sweden EMail: lars-erik.jonsson@ericsson.com
other authors....
Bormann (ed.) [Page 99]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Appendix A. Detailed classification of header fields
Header compression is possible due to the fact that most header
fields do not vary randomly from packet to packet. Many of the fields
exhibit static behavior or changes in a more or less predictable way.
When designing a header compression scheme, it is of fundamental
importance to understand the behavior of the fields in detail.
In this appendix, all IP, UDP and RTP header fields are classified
and analyzed in two steps. First, we have a general classification in
A.1 where the fields are classified based on stable knowledge and
assumptions. The general classification does not take into account
the change characteristics of changing fields because those will vary
more or less depending on the implementation and on the application
used. A less stable but more detailed analysis considering the change
characteristics is then done in A.2. Finally, A.3 summarizes this
appendix with conclusions about how the various header fields should
be handled by the header compression scheme to optimize compression
and functionality.
A.1. General classification
On a general level, the header fields are separated into 5 classes:
INFERRED These fields contain values that can be inferred from
other values, for example the size of the frame
carrying the packet, and thus does not have to be
handled at all by the compression scheme.
STATIC These fields are expected to be constant throughout
the lifetime of the packet stream. Static information
must in some way be communicated once.
STATIC-DEF STATIC fields whose values define a packet stream.
They are in general handled as STATIC.
STATIC-KNOWN These STATIC fields are expected to have well-known
values and therefore do not need to be communicated
at all.
CHANGING These fields are expected to vary in some way, either
randomly, within a limited value set or range, or in
some other manner.
In this section, each of the IP, UDP and RTP header fields is
assigned to one of these classes. For all fields except those
classified as CHANGING, the motives for the classification are also
stated. CHANGING fields are in A.2 further examined and classified
based on their expected change behavior.
Bormann (ed.) [Page 100]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A.1.1. IPv6 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC-KNOWN |
| Traffic Class | 8 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC-KNOWN |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
Version
The version field states which IP version the packet is based on.
Packets with different values in this field must be handled by
different IP stacks. For header compression, different compression
profiles must also be used. When compressor and decompressor have
negotiated which profile to use, the IP version is also known to
both parties. The field is therefore classified as STATIC-KNOWN.
Flow Label
This field may be used to identify packets belonging to a specific
packet stream. If not used, the value should be set to zero.
Otherwise, all packets belonging to the same stream must have the
same value in this field, it being one of the fields defining the
stream. The field is therefore classified as STATIC-DEF.
Payload Length
Information about the packet length (and then also payload length)
is expected to be provided by the link layer. The field is
therefore classified as INFERRED.
Next Header
This field is expected to have the same value in all packets of a
packet stream. As for the version number, a certain compression
profile can only handle a specific next header which means that
this value is known when profile has been negotiated. The field is
therefore classified as STATIC-KNOWN.
Bormann (ed.) [Page 101]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Source and Destination addresses
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are therefore
classified as STATIC-DEF.
Summarizing the bits corresponding to the classes gives:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC-DEF | 34.5 |
| STATIC-KNOWN | 1.5 |
| CHANGING | 2 |
+--------------+--------------+
Bormann (ed.) [Page 102]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A.1.2. 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-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
Version
The version field states which IP version the packet is based on
and packets with different values in this field must be handled by
different IP stacks. For header compression, different compression
profiles must also be used. When compressor and decompressor has
negotiated which profile to use, the IP version is also well known
to both parties. The field is therefore classified as STATIC-KNOWN.
Header Length
As long as there are no options present in the IP header, the
header length is constant and well known. If there are options, the
fields would be STATIC, but we assume no options. The field is
therefore classified as STATIC-KNOWN.
Packet Length
Information about the packet length is expected to be provided by
the link layer. The field is therefore classified as INFERRED.
Flags
The Reserved flag must be set to zero and is therefore classified
as STATIC-KNOWN. The May Fragment flag will be constant for all
packets in a stream and is therefore classified as STATIC. Finally,
Bormann (ed.) [Page 103]
INTERNET-DRAFT Robust Header Compression June 29, 2000
the Last Fragment bit is expected to be zero because fragmentation
is NOT expected, due to the small packet size expected. The Last
Fragment bit is therefore classified as STATIC-KNOWN.
Fragment Offset
With the assumption that no fragmentation occurs, the fragment
offset is always zero. The field is therefore classified as STATIC-
KNOWN.
Protocol
This field is expected to have the same value in all packets of a
packet stream. As for the version number, a certain compression
profile can only handle a specific next header which means that
this value is well known when profile has been negotiated. The
field is therefore classified as STATIC-KNOWN.
Header Checksum
The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is
compressed away, there is no need to have this additional checksum;
instead it can be regenerate at the decompressor side. The field is
therefore classified as INFERRED.
Source and Destination addresses
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are therefore
classified as STATIC-DEF.
Summarizing the bits corresponding to the classes gives:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 4 |
| STATIC | 1 bit |
| STATIC-DEF | 8 |
| STATIC-KNOWN | 3 +7 bits |
| CHANGING | 4 |
+--------------+--------------+
Bormann (ed.) [Page 104]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A.1.3. UDP header fields
+------------------+-------------+-------------+
| Field | Size (bits) | Class |
+------------------+-------------+-------------+
| Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF |
| Length | 16 | INFERRED |
| Checksum | 16 | CHANGING |
+------------------+-------------+-------------+
Source and Destination ports
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are therefore
classified as STATIC-DEF.
Length
This field is redundant and is therefore classified as INFERRED.
Summarizing the bits corresponding to the classes gives:
+------------+--------------+
| Class | Size (octets)|
+------------+--------------+
| INFERRED | 2 |
| STATIC-DEF | 4 |
| CHANGING | 2 |
+------------+--------------+
Bormann (ed.) [Page 105]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A.1.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-DEF |
| CSRC | 0(-480) | CHANGING |
+-----------------+-------------+----------------+
Version
There exists only one working RTP version and that is version 2.
The field is therefore classified as STATIC-KNOWN.
Padding
The use of this field depends on the application, but when payload
padding is used it is likely to be present in all packets. The
field is therefore classified as STATIC.
Extension
If RTP extensions is used by the application, it is likely to be an
extension present in all packets (but use of extensions is very
uncommon). However, for safety's sake this field is classified as
STATIC and not STATIC-KNOWN.
SSRC
This field is part of the definition of a stream and must thus be
constant for all packets in the stream. The field is therefore
classified as STATIC-DEF.
Bormann (ed.) [Page 106]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Summarizing the bits corresponding to the classes gives:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| STATIC | 2 bits |
| STATIC-DEF | 4 |
| STATIC-KNOWN | 2 bits |
| CHANGING | 7.5(-67.5) |
+--------------+--------------+
A.1.5. Summary for IP/UDP/RTP
If we summarize this for IP/UDP/RTP we get:
+----------------+--------------+--------------+
| Class \ IP ver | IPv6 (octets)| IPv4 (octets)|
+----------------+--------------+--------------+
| INFERRED | 4 | 6 |
| STATIC | 2 bits | 3 bits |
| STATIC-DEF | 42.5 | 16 |
| STATIC-KNOWN | 1 +6 bits | 4 +1 bit |
| CHANGING | 11.5(-71.5) | 13.5(-73.5) |
+----------------+--------------+--------------+
| Total | 60(-120) | 40(-100) |
+----------------+--------------+--------------+
Bormann (ed.) [Page 107]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A.2. Analysis of change patterns of header fields
To design suitable mechanisms for efficient compression of all header
fields, their change patterns must be analyzed. For this reason, an
extended classification is done based on the general classification
in A.1, considering the fields which were labeled CHANGING in that
classification. Different applications will use the fields in
different ways, which may affect their behavior. When this is the
case, typical behavior for conversational audio and video will be
discussed.
The CHANGING fields are separated into five different subclasses:
STATIC These are fields that were classified as
CHANGING on a general basis, but are classified
as STATIC here due to certain additional
assumptions.
SEMISTATIC These fields are STATIC most of the time.
However, occasionally the value changes but
reverts to its original value after a known
number of packets.
RARELY-CHANGING (RC) These are fields that change their values
occasionally and then keep their new values.
ALTERNATING These fields alternate between a small number
of different values.
IRREGULAR These, finally, are the fields for which no
useful change pattern can be identified.
To further expand the classification possibilities without increasing
complexity, the classification can be done either according to the
values of the field and/or according to the values of the deltas for
the field.
When the classification is done, other details are also stated
regarding possible additional knowledge about the field values and/or
field deltas, according to the classification. For fields classified
as STATIC or SEMISTATIC, the case could be that the value of the
field is not only STATIC but also well KNOWN a priori (two states for
SEMISTATIC fields). For fields with non-irregular change behavior, it
could be known that changes usually are within a LIMITED range
compared to the maximal change for the field. For other fields, the
values are completely UNKNOWN.
Table A.1 classifies all the CHANGING fields based on their expected
change patterns, especially for conversational audio and video.
Bormann (ed.) [Page 108]
INTERNET-DRAFT Robust Header Compression June 29, 2000
+------------------------+-------------+-------------+-------------+
| Field | Value/Delta | Class | Knowledge |
+========================+=============+=============+=============+
| Sequential | Delta | STATIC | KNOWN |
| -----------+-------------+-------------+-------------+
| IPv4 Id: Seq. jump | Delta | RC | LIMITED |
| -----------+-------------+-------------+-------------+
| Random | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP TOS / Tr. Class | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP TTL / Hop Limit | Value | ALTERNATING | LIMITED |
+------------------------+-------------+-------------+-------------+
| Disabled | Value | STATIC | KNOWN |
| UDP Checksum: ---------+-------------+-------------+-------------+
| Enabled | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| No mix | Value | STATIC | KNOWN |
| RTP CSRC Count: -------+-------------+-------------+-------------+
| Mixed | Value | RC | LIMITED |
+------------------------+-------------+-------------+-------------+
| RTP Marker | Value | SEMISTATIC | KNOWN/KNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Payload Type | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Sequence Number | Delta | STATIC | KNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Timestamp | Delta | RC | LIMITED |
+------------------------+-------------+-------------+-------------+
| No mix | - | - | - |
| RTP CSRC List: -------+-------------+-------------+-------------+
| Mixed | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
Table A.1 : Classification of CHANGING header fields
The following subsections discuss the various header fields in
detail. Note that table A.1 and the discussions below do not consider
changes caused by loss or reordering before the compression point.
Bormann (ed.) [Page 109]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A.2.1. IPv4 Identification
The Identification field (IP ID) of the IPv4 header is there to
identify which fragments constitute a 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.
Sequential
This assignment policy keeps a separate counter for each outgoing
packet stream and thus the IP ID value will increment by one for
each packet in the stream. Therefore, the delta value of the
field is constant and well known a priori. When RTP is used on
top of UDP and IP, the IP ID value follows the RTP sequence
number. This assignment policy is the most desirable for header
compression purposes but its usage is not as common as it should
be. The reason is that it can be realized only if UDP and IP are
implemented together so that UDP, which separates packet streams
by the port identification, can make IP use separate ID counters
for each packet stream.
Sequential jump
This is the most common assignment policy in today's IP stacks.
The difference from the sequential method is that only one
counter is used for all connections. When the sender is running
more than one packet stream simultaneously, the IP ID can
increase by more than one. 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 packet streams and sending frequencies) will
usually be limited.
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.
It should be noted that the ID is an IPv4 mechanism and is therefore
not needed at all in IPv6 profiles. For IPv4 the ID could be handled
in three different ways. Firstly, we have the inefficient but
Bormann (ed.) [Page 110]
INTERNET-DRAFT Robust Header Compression June 29, 2000
reliable solution where the ID field is sent as-is in all packets,
increasing the compressed headers with two octets. This is the best
way to handle the ID field if the sender uses random assignment of
the ID field. Secondly, there can be solutions with more flexible
mechanisms requiring less bits for the ID handling as long as
sequential jump assignment is used. Such solutions will probably
require even more bits if random assignment is used by the sender.
Knowledge about the sender's assignment policy could therefore be
useful when choosing between the two solutions above. Finally, even
for IPv4, header compression could be designed without any additional
information for the ID field included in compressed headers. To use
such schemes, it must be known that the sender makes use of the pure
sequential assignment policy for the ID field. That might not be
possible to know, which implies that the applicability of such
solutions is very uncertain. However, designers of IPv4 stacks for
cellular terminals SHOULD use the sequential policy.
A.2.2. IP Traffic-Class / Type-Of-Service
The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected
to be constant during the lifetime of a packet stream or to change
relatively seldom.
A.2.3. IP Hop-Limit / Time-To-Live
The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
constant during the lifetime of a packet stream or to alternate
between a limited number of values due to route changes.
A.2.4. UDP Checksum
The UDP checksum is optional. If disabled, its value is constantly
zero and could be compressed away. If enabled, its value depends on
the payload, which for compression purposes is equivalent to it
changing randomly with every packet.
A.2.5. RTP CSRC Counter
This is a counter indicating the number of CSRC items present in the
CSRC list. This number is expected to be almost constant on a packet-
to-packet basis and change by small amount. As long as no RTP mixer
is used, the value of this field is zero.
Bormann (ed.) [Page 111]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A.2.6. RTP Marker
For audio the marker bit should be set only in the first packet of a
talkspurt while for video it should be set in the last packet of
every picture. This means that in both cases the RTP marker is
classified as SEMISTATIC with well-known values for both states.
A.2.7. RTP Payload Type
Changes of the RTP payload type within a packet stream are expected
to be rare. Applications could adapt to congestion by changing
payload type and/or frame sizes, but that is not expected to happen
frequently.
A.2.8. RTP Sequence Number
The RTP sequence number will be incremented by one for each packet
sent.
A.2.9. RTP Timestamp
In the audio case:
As long as there are no pauses in the audio stream, the RTP
timestamp will be incremented by a constant delta, corresponding
to the number of samples in the speech frame. It will thus mostly
follow the RTP sequence number. 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. However, the
increment will probably be within a relatively limited range.
In the video case:
The timestamp change between two consecutive packets will either
be zero or increase by a multiple of a fixed value corresponding
to the picture clock frequency. The timestamp can also decrease
by a multiple of the fixed value if B-pictures are used. The
delta interval, expressed as a multiple of the picture clock
frequency, is in most cases very limited.
A.2.10. RTP Contributing Sources (CSRC)
The participants in a session, which are identified by the CSRC
fields, are expected to be almost the same on a packet-to-packet
basis with relatively few additions or removals. As long as RTP
mixers are not used, no CSRC fields are present at all.
Bormann (ed.) [Page 112]
INTERNET-DRAFT Robust Header Compression June 29, 2000
A.3. Header compression strategies
This section elaborates on what has been done in previous sections.
Based in the classifications, recommendations are given on how to
handle the various fields in the header compression process. Seven
different actions are possible and these are listed together with the
fields to which each action applies.
A.3.1. Do not send at all
The fields that have well known values a priori do not have to be
sent at all. These are:
- IP Version
- IPv6 Payload Length
- IPv6 Next Header
- IPv4 Header Length
- IPv4 Reserved Flag
- IPv4 Last Fragment Flag
- IPv4 Fragment Offset
- IPv4 Protocol
- UDP Checksum (if disabled)
- RTP Version
A.3.2. Transmit only initially
The fields that are constant throughout the lifetime of the packet
stream have to be transmitted and correctly delivered to the
decompressor only once. These are:
- IP Source Address
- IP Destination Address
- IPv6 Flow Label
- IPv4 May Fragment Flag
- UDP Source Port
- UDP Destination Port
- RTP Padding Flag
- RTP Extension Flag
- RTP SSRC
A.3.3. Transmit initially, but be prepared to update occasionally
The fields that are changing only occasionally must be transmitted
initially but there must also be a way to update these fields with
new values if they change. These fields are:
- IPv6 Traffic Class
- IPv6 Hop Limit
Bormann (ed.) [Page 113]
INTERNET-DRAFT Robust Header Compression June 29, 2000
- IPv4 Type Of Service (TOS)
- IPv4 Time To Live (TTL)
- RTP CSRC Counter
- RTP Payload Type
- RTP CSRC List
A.3.4. Be prepared to update or send as-is frequently
For fields that normally are either constant or whose values can be
deduced from some other field but frequently diverge from that
behavior, there must be an efficient way to update the field value or
send it as-is in some packets. Those fields are:
- IPv4 Identification (if not sequentially assigned)
- RTP Marker
- RTP Timestamp
A.3.5. Guarantee continuous robustness
Fields that behave like a counter with a fixed delta for ALL packets,
the only requirement on the transmission encoding is that packet
losses between compressor and decompressor must be tolerable. If more
than one such field exists, all these can be communicated together.
Such fields can also be used to interpret the values for fields
listed in the previous section. Fields that have this counter
behavior are:
- IPv4 Identification (if sequentially assigned)
- RTP Sequence Number
A.3.6. Transmit as-is in all packets
Fields that have completely random values for each packet must be
included as-is in all compressed headers. Those fields are:
- IPv4 Identification (if randomly assigned)
- UDP Checksum (if enabled)
A.3.7. Establish and be prepared to update delta
Finally, there is a field that is usually increasing by a fixed delta
and is correlated to another field. For this field it would make
sense to make that delta part of the context state. The delta must
then be possible to initiate and update in the same way as the fields
listed in A.3.3. The field to which this applies is:
- RTP Timestamp
Bormann (ed.) [Page 114]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Appendix COMPLIST
Editor's Note: This is too long and not quite in style to be added to
encoding section. Also, I believe this is too complicated.
1. Compression of Item List
An Item List specifies a set of items that is order sensitive. A
generic structure of an item list is as follows.
+--------+--------+--------+--------+
item list: | item 1 | item 2 | ...... | item n |
+--------+--------+--------+--------+
The items on an item list may or may not have the same structure.
An example of the first case is the CSRC list in the RTP header or
the Address list in Type 0 IPv6 Routing Header. An example of the
second case is IPv6 extension headers. Note that an item itself could
be a list.
The compression of a current item list (curr_list) is based on a
reference item list (ref_list) that is previously sent by the
compressor and received by the decompressor. The difference between
the curr_list and ref_list is encoded and sent in the compressed
list. The reference may be chosen by various means. One approach is
based on acknowledgement, i.e., the compressor chooses the latest
item list that is acknowledged by the decompressor as the reference.
The decompressor retrieves the reference item list, based on which
items are to be decompressed in the new item list. To identify the
reference used for the compression, a reference identifier (ref_id)
needs to be carried inside the compressed list. An example of ref_id
is RTP sequence number.
1.1. Item Compression
A given item in curr_list can be classified as belonging to one of
the following transformation cases.
* Transformation Case A: The given item is also in the ref_list,
and the content of these two items is the same, while the position in
the list may or may not have changed.
* Transformation Case B: There is an item in the ref_list with a
similar structure, but the contents of these two items are not
identical. The position in the list may or may not be the same.
* Transformation Case C: The given item in the curr_list is not in
the ref_list.
Bormann (ed.) [Page 115]
INTERNET-DRAFT Robust Header Compression June 29, 2000
For the given item in curr_list, the compressor determines which
transformation case applies. Depending on the transformation case,
the correspondent encoding technique is used.
1.2. List Compression
Seven encoding schemes are defined below. To identify the
encoding scheme used for the list compression, an encoding type field
(ET) is included in the compressed list.
1.2.1. Generic Scheme
The generic encoding scheme addresses the case where the items
belong to a mixture of transformation cases. For example, item 1 in
curr_list belongs to transformation case B, item 2 belongs to
transformation case C, while item 3 belongs to transformation case A.
Using this scheme, the structure of a compressed item list is
defined as follows.
compressed list:
+----------+--------+--------------+----------+------+----------
+
| ET = 000 | ref_id | c_item count | c_item 1 | .... | c_item n
|
+----------+--------+--------------+----------+------+----------
+
* The encoding type (ET) is "000".
* The ref_id is defined at the beginning of section 1. One
example is the RTP sequence number.
* The c_item count specifies the number of c_items in the c_item
list (c_item 1, ..., c_item n). The length of c_item count is defined
based on the context of the application.
* Each c_item (c_item i) corresponds to one of the item (item i)
in the curr_list; thus the order of the c_items represents the order
of the items in the curr_list. The structure of c_item is defined as
follows.
Each c_item consists of C_item Code (CC) and C_item Data.
+-------------+-------------+
c_item: | c_item code | c_item data |
+-------------+-------------+
For different c_item codes, the content of the c_item data is
different. Three types of c_item codes and their respective c_item
data are defined as follow.
Bormann (ed.) [Page 116]
INTERNET-DRAFT Robust Header Compression June 29, 2000
* C_item Code "0" is used for an item classified as belonging
to transformation case A. The structure of the c_item is as follows.
+----------+-----+
c_item: | CC = "0" | pos |
+----------+-----+
- The "pos" field indicates the position of the item in the
ref_list.
Note that "pos" starts from 0, i.e., the position of the
first item in the list is 0. Since the "pos" field in the c_item data
field indicates the position of the item in the ref_list, the length
of "pos" field depends on the actual number of items in the ref_list.
Assuming that there are 'k' items in the ref_list, then the number of
bits used for "pos" field is ceiling(log2(k)). Since k is known to
both the compressor and decompressor, the length of "pos" field
doesn't need to be carried in the compressed list.
When the decompressor receives this c_item, it retrieves the
item at position "pos" in the ref_list, and copies it into the
curr_list.
* C_item Code "10" is used for an item classified as belonging
to transformation case B. The structure of the c_item is as follows.
+-----------+-----+::::::::::::::::::::+------------
-----+
c_item: | CC = "10" | pos | type-specific data | compressed
data |
+-----------+-----+::::::::::::::::::::+------------
-----+
- The "pos" field is defined as above.
- The "compressed data" field carries compressed value of
the item in the curr_list, using the item at position "pos" in the
ref_list as the reference. The compression technique is dependent on
the item and should be predefined.
- The optional "type-specific data" field contains
additional information used to reconstruct the item list. The
presence and the content of the "type-specific data" depend on the
item and should be predefined.
When the decompressor receives this c_item, it retrieves the
item at the position "pos" in the ref_list and uses it as the
reference to decompress the "compressed data". If the item itself is
a list, the compression scheme described here applies to compress the
item.
Bormann (ed.) [Page 117]
INTERNET-DRAFT Robust Header Compression June 29, 2000
* C_item Code "11" is used for an item classified as belonging
to transformation case C or transformation case B in the case that
the length of the compressed value of an item is even larger than the
length of the uncompressed value due to too many changes. The
structure of the c_item is as follows.
+-----------+::::::::::::::::::::+------------------
-+
c_item: | CC = "11" | type-specific data | uncompressed data
|
+-----------+::::::::::::::::::::+------------------
-+
- The optional "type-specific data" field is defined as
above.
- The "uncompressed data" field contains the original value
of the item in the curr_list.
When the decompressor receives this c_item, it copies the
uncompressed data field into curr_list.
1.2.2. Insertion Only Scheme
This scheme only addresses the case where all the items are
classified as belonging to either transformation case A or C. The
structure of the compressed item list is as follows.
+----------+--------+--------------+-----+
compressed list: | ET = 001 | ref_id | u_item count | aft |
+----------+--------+--------------+-----+
-----------------+----------+----+----------+
insertion order | u_item 1 |....| u_item m |
-----------------+----------+----+----------+
* The encoding type (ET) is "001".
* The ref_id is defined as before.
* The u_item count field carries the number of u_items in the
following u_item list (u_item 1,., u_item m). The length of u_item
count is defined based on the context of the application.
* Each u_item carries the uncompressed value of the new item in
the curr_list when comparing it with the ref_list.
+-------------------+
u_item: | uncompressed data |
+-------------------+
Bormann (ed.) [Page 118]
INTERNET-DRAFT Robust Header Compression June 29, 2000
* The aft field specifies the format used in insertion order
field.
0 - bit mask format
1 - position list format
* The insertion order field specifies the positions of the
inserted items. Two formats can be used.
** Bit Mask Format: In this format, a bit mask is include.
To construct the bit mask and the u_item list, the following
steps are taken.
*** A list of '0' and an empty u_item list are generated as
the starting point. The number of '0's in the '0' list equals the
number of items in the ref_list. The position of each '0' in the '0'
list corresponds to the position of an item in the ref_list, i.e.,
the i-th '0' in the '0' list corresponds to the i-th item in the
ref_list.
*** Comparing the curr_list with the ref_list, if a new item
is inserted between the i-th item and the (i+1)-th item in the
ref_list, a '1' is inserted between the i-th '0' and (i+1)-th '0' in
the original '0' list. The u_item that carries the new item should be
added to the end of u_item list. This procedure is repeated until all
the added items have been processed.
Assuming the number of items in the ref_list is k, and the
number of new items is m, then the length of the bit mask is k+m.
Since k is known to both the compressor and decompressor, and m is
carried in "u_item count" field, the length of the bit mask can be
obtained by the compressor and decompressor and doesn't need to be
carried in the compressed item list.
When the decompressor receives the bit mask, it scans from
left to right. When a '0' is observed, the decompressor copies the
corresponding item in the ref_list into the curr_list; when an '1' is
observed, the decompressor adds the correspondent u_item into the
curr_list.
** Position List Format: In this format, a list of position
fields is carried. The structure of this format is as follows.
+-------+----+-------+
position list: | pos 1 |....| pos m |
+-------+----+-------+
The value of Pos i specifies the position of the item in the
ref_list, before which u_item i should be inserted. If two or more
u_items have the same position value, they are inserted in the order
they appear. A u_item is inserted after a previous inserted u_item.
Bormann (ed.) [Page 119]
INTERNET-DRAFT Robust Header Compression June 29, 2000
When the decompressor receives position list, it first
retrieves all the items in the ref_list. Then for each u_item, it
inserts it into the ref_list at the position indicated in the
corresponding pos field in the position list.
Note that the number of bits used for pos field is
ceiling(log2(k+1)), where k is the number of items in the ref_list.
Pos field = "k" means that the correspondent item should be inserted
to the end of the list.
Assuming the number of new items is m, then the total length
of the position list is m * ceiling(log2(k+1)).
The selection of these formats depends on the encoding
efficiency. In the case that the number of item in the ref_list is
large and only few items are inserted, the position list format is
favorable; otherwise the bit mask format is more efficient.
1.2.3. Removal Only Scheme
This scheme only addresses the case where certain items exist in
the ref_list but not in the curr_list. The structure of the
compressed item list is as follows.
+----------+--------+-----+---------------+
compressed list: | ET = 010 | ref_id | rft | removal order |
+----------+--------+-----+---------------+
* The encoding scheme type (ET) is "010".
* The ref_id is defined as before.
* The rft field specifies the format used in removal order
field.
0 - bit mask format
1 - position list format
* The removal order field specifies the positions of the items
to be removed. Two formats can be used.
** Bit mask format: In this format, a removal bit mask is
included. A '1' in the i-th bit in the removal bit mask means that
the i-th item in the ref_list is not included in the curr_list, while
a '0' means it is still present in the curr_list. Assuming the number
of items in the ref_list is k, then the length of the removal bit
mask is k. Since k is known to both the compressor and decompressor,
the length of the bit mask doesn't need to be carried in the
compressed list.
Bormann (ed.) [Page 120]
INTERNET-DRAFT Robust Header Compression June 29, 2000
** Position list format: In this format, a list of position
fields as well as a count field is included. The structure of this
format is as follows.
+-------+:::::::+::::+:::::::+
position list: | count | pos 1 |....| pos m |
+-------+:::::::+::::+:::::::+
- The count field carries the number of pos fields in the
position list. Count field = '0' has the special meaning that all the
items are removed and no pos field is included. Assuming the number
of items in the ref_list is k, then the length of count field is
ceiling(log2(k)).
- Each pos field carries the position of an item in the
ref_list, which no longer exists in the curr_list. The length of the
pos field is ceiling(log2(k)).
The length of the position list is (m + 1) *
ceiling(log2(k)).
The selection between these two formats depends on the
encoding efficiency. In the case that the number of items in the
ref_list is small and/or the number of items removed from the
ref_list is large, the bit mask format is favorable; otherwise the
position list format is more efficient.
1.2.4. Insertion and Removal Only Scheme
This scheme accommodates all the transformation cases addressed
in insertion only and removal only schemes. The structure of the
compressed item list is as follows.
+----------+--------+--------------+-----+
compressed list: | ET = 011 | ref_id | u_item count | rft |
+----------+--------+--------------+-----+
---------------+-----+-----------------+----------+----+--------
--+
removal order | aft | insertion order | u_item 1 |....| u_item
m |
---------------+-----+-----------------+----------+----+--------
--+
* The encoding scheme type (ET) is "011".
* The ref_id is defined as before.
* The remaining fields are defined in insertion only scheme and
removal only scheme. Unlike the insertion order field in the
insertion only case, the insertion order field in this scheme is
based on the items left in the ref_list after removal has been
Bormann (ed.) [Page 121]
INTERNET-DRAFT Robust Header Compression June 29, 2000
processed. When the decompressor receives such compressed list, it
applies the removal before the insertion.
1.2.5. Content Change Only Scheme
This scheme only addresses the case where the number of items in
the list and the ordering are not changed, but the content of one or
more item is changed. The structure of the compressed item list is as
follows.
compressed list:
+----------+--------+-----+--------------+-----------+----+-----
------+
| ET = 100 | ref_id | cft | change order | uc_item 1 |....|
uc_item m |
+----------+--------+-----+--------------+-----------+----+-----
------+
* The encoding type (ET) is "100".
* The ref_id is defined as before.
* The cft field specifies the format used in change order field.
0 - bit mask format
1 - position list format
* The change order field specifies the position of the items
whose content is changed. Two formats can be used.
** Bit mask format: In this format, a change bit mask is
included. A '1' in the i-th bit in the change bit mask means that the
i-th item in the ref_list is not identical to the i-th item in the
curr_list, while a '0' means they are the same. Assuming the number
of items in the ref_list is k, then the length of the change bit mask
equals k. Since k is known to both the compressor and the
decompressor, it doesn't need to be sent in the compressed list.
** Position list format: In this format, a list of position
fields as well as a count field is included. The structure of this
format is as follows.
+-------+-------+----+-------+
position list: | count | pos 1 |....| pos m |
+-------+-------+----+-------+
- The count field carries the number of pos fields in the
position list. Value '0' in count field has the special meaning that
all the items are changed and no pos field is included. Assuming the
number of items in the ref_list is k, then the length of count field
is ceiling(log2(k)).
Bormann (ed.) [Page 122]
INTERNET-DRAFT Robust Header Compression June 29, 2000
- Each pos field carries the position of an item in the
ref_list, whose value is not identical with the item at the same
position in the curr_list.
The length of position list is (m + 1) * ceiling(log2(k)).
The selection between these two formats depends on the
encoding efficiency. In the case that the number of items that have
content change is small, the bit mask format is favorable; otherwise
the position list format is more efficient.
* Each uc_item in the uc_item list corresponds to the item whose
content is changed when comparing it with the item at the same
position in the ref_list. Their positions in curr_list is indicated
in the change order field. When position list format is used in
change order field and the count field is '0', the order of the
uc_item is the same as the item order in ref_list. The structure of
uc_item is as follows.
+---+---------------------------------+
uc_item: | C | compressed or uncompressed data |
+---+---------------------------------+
C bit specifies the format of the compressed or uncompressed
data field. A '0' in C bit indicates the uncompressed value of the
item is sent, while a '1' indicates the compressed value of the item
is carried. The item in the curr_list is compressed using the item at
the same position in ref_list as the reference. The compression
technique is dependent on the item and should be predefined.
1.2.6. Insertion and Content Change Only Scheme
This scheme only addresses the case where 1) all the items in
the ref_list are also in the curr_list, 2) new items are added into
the curr_list, 3) the relative order of the items that are in both
ref_list and curr_list remains the same, and 4) the content of one or
more of these items have been changed. The structure of the
compressed item list is as follows.
compressed list:
+----------+--------+-----+--------------+-----------+----+-----
-------+
| ET = 101 | ref_id | cft | change order | uc_item 1 |....|
uc_item m1 |
+----------+--------+-----+--------------+-----------+----+-----
-------+
-----+-----------------+----------+----+-----------+
aft | insertion order | u_item 1 |....| u_item m2 |
-----+-----------------+----------+----+-----------+
* The encoding type (ET) is "101".
Bormann (ed.) [Page 123]
INTERNET-DRAFT Robust Header Compression June 29, 2000
* The ref_id is defined at the beginning of section 1.
* The remaining fields are defined in insertion only scheme and
content change only scheme. The change order field in this scheme is
based on the items in the ref_list and the items in the curr_list,
excluding the new inserted items. When the decompressor receives such
a compressed list, it applies the content change before the
insertion.
1.2.7. Removal and Content Change Only Scheme
This scheme only addresses the case where 1) some items in the
ref_list are not in the curr_list, and 2) the content of one or more
items that are in both ref_list and curr_list is changed, but the
relative order of these items remains the same. The structure of the
compressed item list is as follows.
compressed list:
+----------+--------+-----+---------------+-----+--------------+
| ET = 110 | ref_id | rft | removal order | cft | change order |
+----------+--------+-----+---------------+-----+--------------+
-----------+----+-----------+
uc_item 1 |....| uc_item m |
-----------+----+-----------+
* The encoding type (ET) is "110".
* The ref_id is defined at the beginning of section 1.
* The remaining fields are defined in the removal only scheme
and content change only scheme. The change order field in this scheme
is based on the items in the curr_list and the items in the ref_list
after the removal is processed. When the decompressor receives such a
compressed list, it applies the removal before the content change.
2. Examples
The examples below illustrate the operation of item list
compression under various transformation cases. We assume no type-
specific data is needed for the decompression.
Example 1. Insertion and Removal only
Assuming the items and the order of these items in the curr_list
and ref_list are as follow.
curr_list: A, B, C, D
ref_list: B, C, X
Bormann (ed.) [Page 124]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Comparing curr_list with ref_list, A and D are added into the
list and X is removed from the list. No change happens to the order
and the content for B and C. The format defined in the insertion and
removal only scheme can be used.
The compressed item list format for this case is as follow.
+----------+--------+--------------+-----+
compressed list: | ET = 011 | ref_id | u_item count | rft |
+----------+--------+--------------+-----+
---------------+-----+-----------------+--------------+---------
-----+
removal order | aft | insertion order | u_item for A | u_item
for D |
---------------+-----+-----------------+--------------+---------
-----+
* ref_id is defined in section 1.
* The u_item count equals 2.
* Assuming that the bit mask format is used for removal order,
then rft equals '0'.
* The removal order is "001" where the bits from left to right
correspond to B, C, X respectively. The '1' corresponds to X and
indicates that X is removed.
* Assuming that position list format is used for the insertion
order, then aft equals '1'.
* The insertion order is "0010". The first 2 bits "00" indicate
item A is added before the item at position "00" in the ref_list,
which is B. The following 2 bits "10" indicate item D is added
before position "10" in the ref_list after the removal process, which
is after item B.
* The u_item for A and u_item for D carry uncompressed A and D
respectively.
Example 2. Insertion, Removal, Change of Content and Reordering
Assuming the items and the order of these items in the curr_list
and ref_list are as follow.
curr_list: A, C, B', D
ref_list: B, C, X
Bormann (ed.) [Page 125]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Comparing curr_list with ref_list, A and D are added into the
list and X is removed from the list. The order of B and C is changed
and the content of B is changed as well. The generic item list
compression format is used to carry the change.
+----------+--------+--------------+
compressed list: | ET = 000 | ref_id | c_item count |
+----------+--------+--------------+
----------+----------+----------+----------+
c_item A | c_item C | c_item B | c_item D |
----------+----------+----------+----------+
* The c_item count equals 4.
+----+------------------------+
* c_item A: | 11 | A (uncompressed value) |
+----+------------------------+
+---+----+
* c_item C: | 0 | 01 |
+---+----+
"01" represents the position of C in the ref_list.
+----+----+---------------+
* c_item B: | 10 | 00 | compressed B' |
+----+----+---------------+
"00" represents the position of B in the ref_list. Compressed
B' carries the compressed value of B', using B in the ref_list as the
reference.
+----+------------------------+
* c_item D: | 11 | D (uncompressed value) |
+----+------------------------+
3. Optimization
The above description assumed that a given item in the curr_list
can be uniquely classified as belonging to one transformation case.
In reality, there are cases where there is more than one way to do
the classification. An example is given as follows.
For a given item (item X) in the curr_list, there is no item in
the ref_list which has an identical content, but one item (item Y) in
the ref_list has a similar structure to item X, therefore, item X can
be classified as belonging to either transformation case B or
transformation case C. An example of this type of list is the CSRC
list in RTP header.
Bormann (ed.) [Page 126]
INTERNET-DRAFT Robust Header Compression June 29, 2000
The compressor can decide to use the transformation case, for
which the encoding scheme will yield the highest compression
efficiency. For example, in the above example, let's assume item X
consists of L_x bits.
* If item X is classified as belonging to transformation case A
and c_item code "11" is used, the c_item for item X consists of (L_x
+ 2) bits.
* If item X is classified as belonging to transformation case B
and c_item code "10" is used, under the assumption that the length of
the pos field is L_pos and the length of compressed item X when using
item Y as the reference is D_xy, then the c_item for item X consists
of (L_pos + D_xy + 2) bits.
Thus, if (L_pos + D_xy) is larger than L_x, then
transformation case B is applied; otherwise transformation case A is
applied.
Bormann (ed.) [Page 127]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Appendix E _ Encoding Examples
E.1. Basic VLE
The examples below illustrate the operation of VLE under various
scenarios. The field values used in the examples could correspond to
any fields that we wish to compress. The examples illustrate the
scenario where the compressed field has resolution of one bit.
Example 1: Normal operation (no packet loss prior to compressor,
no reodering prior to compressor).
Suppose packets with header fields 279, 280, 281, 282, and 283
have been sent, and 279 and 283 are fields of potential reference
packets.
The current VLE window is {279, 283}.
and a packet with field value = 284 is received next, VLE computes
the following values
New Value VMax VMin r # LSBs
284 283 279 max[|284-279|,|284-283|]=5 4
The window is unmodified if we assuming the new packet {284} is
not a potential reference. The field is encoded using 4 bits in this
case, and the actual encoded value is the 4 least significant bits of
284 (10011100) which = 1100.
Example 2: Packet Loss prior to compressor.
Suppose packets with header fields 279, 280, 281, 282, and 283
have been sent, and 279 and 283 are fields of potential reference
packets such that the VSW is again {279, 283}.
If a packet with field value = 290 is received next, VLE computes
the following values
New Value VMax VMin r # LSBs
290 283 279 max[|290-283|,|290-279|]=11 5
So the field is encoded using 5 bits. Actual encoded value is the
5 LSBs of 290 (100100010) which = 00010.
If we assume the new value is a potential reference, the new VSW
is {279, 283, 290}.
Example 3: Packet Misordering prior to compressor.
Bormann (ed.) [Page 128]
INTERNET-DRAFT Robust Header Compression June 29, 2000
Suppose packets with header fields 279, 280, 281, 282, and 283
have been sent, and 279 and 283 are fields of potential reference
packets such that the VSW is again {279, 283}.
If a packet with field value = 278 is received next, VLE computes
the following values
New Value VMax VMin r # LSBs
278 283 279 max[|278-283|,|278-279|]=5 4
So the field is encoded using 4 bits. Actual encoded value is the
4 LSBs of 278 (10010110) which = 0110.
If we assume the new value is a potential reference, the new VSW
is {283, 290, 278}.
In any case, the VLE encoded fields must be accompanied by some
bits in order to identify the different possible encoded field sizes.
Sizes of this bit field can vary depending on the number of different
sizes one wishes to allow. The approach in ACE is to allow only a
few different sizes for byte-aligned header formats. Huffman coding
of the length is used to achieve some additional efficiency, based on
the expected frequency of needing the different sizes. 1 or 2
additional bits are actually sent in the ACE compressed header.
The decompressor behavior in all the example cases is the same- it
uses as a reference a specific decompressed header field value. The
header to use might be indicated by the presence of a checksum in the
compressed header packet, or by other means. They must by definition
be one of the values in the compressor's window.
For example let's assume that the last correctly decompressed
packet which qualifies as a reference was the packet with header
field = 291. Now suppose the encoded field value of 303 (10001111)
is received and = 01111. The two values closest values to 291 which
have LSBs = 01111 are 271 and 303. 303 is closest, therefore it is
correctly selected as the uncompressed field value.
E.2. Timer-Based VLE
As a an example of operation, consider the case of a voice codec
(20 mS), such that TS_stride = 160. Assume T_current and
p_TS_current are 357 and 351, respectively, and that we have sliding
window TSW which contains the following values 4 entries:
j T_j p_TS_j
1 9 7
2 8 6
Bormann (ed.) [Page 129]
INTERNET-DRAFT Robust Header Compression June 29, 2000
3 7 4
4 3 1
j above is the packet number.
In this case we have
Network_jitter(1)=|(357-9)-(351-7)|=4 (80 mS Network Jitter)
Network_jitter(2)=|(357-8)-(351-6)|=4 (80 mS Network Jitter)
Network_jitter(3)=|(357-7)-(351-4)|=3 (60 mS Network Jitter)
Network_jitter(4)=|(357-3)-(351-1)|=4 (80 mS Network Jitter)
So Max_Network_Jitter = 4.
We assume a maximum CD-CC jitter of 2 (40 mS); the total jitter to
be handled in this case is then
J = 4 + 2 + 2 = 8 packets (160 mS)
and k = 5 bits (since 2 * 5 + 1 < 2^5). The compressor sends the
5 LSBs of p_TS_current to the decompressor (351 = 101011111, so the
encoded TS value = 11111).
When the decompressor receives this value, it first attempts to
estimate the timestamp by computing the time difference between the
last reference established and the current packet
T_current - T_ref, where T_ref is the value of the wall
clock time at which the reference headers was received by the
decompressor
That value is added to p_TS_ref, the packed RTP TS of the
reference header, to get the estimate.
Assume that at the decompressor packet #3 is used as the
reference:
- T_current = 359
- T_ref = 7
- p_TS_ref = 4
Note:
T_current is picked here as any value; the difference between it
and T_ref represents the length of the silence interval as observed
at the decompressor. Then:
T_current - T_ref = 359 - 7 = 352
p_TS_current(estimate) = 352 + 4 = 356
Bormann (ed.) [Page 130]
INTERNET-DRAFT Robust Header Compression June 29, 2000
The decompressor searches for the closest value to 356 which has,
in this case, LSBs = 11111. The value in this case is 351, the
original p_TS.
If instead the compressor were to send the timestamp jump as
simply the difference in consecutive packed RTP Timestamps, that
value would be
p_TS_current - p_TS_ref = 351-4 = 347 = 101011011
So over twice as many bits would be sent for a silence interval of
347 (20 mS) = 6.94 seconds
Due to basic conversational real-time requirements, the cumulative
jitter in normal operation is expected to be at most only a few times
T stride for voice. For this reason, the FO payload formats in
section 4.3 are optimized (in terms of representing different k-
length encoded TS values) for the case of k=4 (handles up to 16
discrepencies in the timestamp). The remaining formats allow a wide
range of jitter conditions (outside of just voice) to be handled as
well.
Bormann (ed.) [Page 131]
INTERNET-DRAFT Robust Header Compression June 29, 2000
This Internet-Draft expires December 27, 2000.
Bormann (ed.) [Page 132]