Request for Comments: 4019 Ericsson AB
Category: Standards Track April 2005
RObust Header Compression (ROHC):
Profiles for User Datagram Protocol (UDP) Lite
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines Robust Header Compression (ROHC) profiles for
compression of Real-Time Transport Protocol, User Datagram Protocol-
Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-
Lite/IP. These profiles are defined based on their differences with
the profiles for UDP as specified in RFC 3095.
Table of Contents
1. Introduction.................................................. 2
2. Terminology................................................... 3
3. Background.................................................... 3
3.1. Overview of the UDP-Lite Protocol....................... 3
3.2. Expected Behaviours of UDP-Lite Flows................... 5
3.2.1. Per-Packet Behavior............................. 5
3.2.2. Inter-Packet Behavior........................... 5
3.2.3. Per-Flow Behavior............................... 5
3.3. Header Field Classification............................. 5
4. Rationale behind the Design of ROHC Profiles for UDP-Lite..... 6
4.1. Design Motivations...................................... 6
4.2. ROHC Considerations..................................... 6
5. ROHC Profiles for UDP-Lite.................................... 6
5.1. Context Parameters...................................... 7
5.2. Initialization.......................................... 8
5.2.1. Initialization of the UDP-Lite Header [1]....... 8
5.2.2. Compressor and Decompressor Logic............... 9
5.3. Packet Formats.......................................... 9
5.3.1. General Packet Format........................... 9
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)... 10
5.3.2.1. Properties of CCE():.................. 11
5.3.2.2. Properties of CCE(ON):................ 11
5.3.2.3. Properties of CCE(OFF):............... 12
5.4. Compressor Logic........................................ 12
5.5. Decompressor Logic...................................... 12
5.6. Additional Mode Transition Logic........................ 13
5.7. The CONTEXT_MEMORY Feedback Option...................... 13
5.8. Constant IP-ID.......................................... 13
6. Security Considerations....................................... 14
7. IANA Considerations........................................... 14
8. Acknowledgments............................................... 15
9. References.................................................... 15
9.1. Normative References.................................... 15
9.2. Informative References.................................. 15
Appendix A. Detailed Classification of Header Fields............. 17
Appendix B. Detailed Format of the CCE Packet Type............... 20
Author’s Address.................................................. 22
Full Copyright Statement.......................................... 23
1. Introduction
The ROHC WG has developed a header compression framework on top of
which various profiles can be defined for different protocol sets or
compression strategies. Due to the demands of the cellular industry
for an efficient way to transport voice over IP over wireless, ROHC
[2] has mainly focused on compression of IP/UDP/RTP headers, which
are generous in size, especially compared to the payloads often
carried by packets with these headers.
ROHC RTP has become a very efficient, robust, and capable compression
scheme, able to compress the headers down to a total size of one
octet only. Also, transparency is guaranteed to an extremely high
extent, even when residual bit errors are present in compressed
headers delivered to the decompressor.
UDP-Lite [4] is a transport protocol similar to the UDP protocol [7].
UDP-Lite is useful for applications designed with the capability to
tolerate errors in the payload, for which receiving damaged data is
better than dealing with the loss of entire packets. This may be
particularly suitable when packets are transported over link
technologies in which data can be partially damaged, such as wireless
links.
Although these transport protocols are very similar, ROHC profiles
must be defined separately for robust compression of UDP-Lite headers
because UDP-Lite does not share the same protocol identifier with
UDP. Also, the UDP-Lite Checksum Coverage field does not share the
semantics of the corresponding UDP Length field, and as a consequence
it cannot always be inferred anymore.
This document defines two ROHC profiles for efficient compression of
UDP-Lite headers. The objective of this document is to provide
simple modifications to the corresponding ROHC profiles for UDP,
specified in RFC 3095 [2]. In addition, the ROHC profiles for UDP-
Lite support some of the mechanisms defined in the profile for
compression of IP headers [3] (ROHC IP-Only). This specification
includes support for compression of multiple IP headers and for
compressing IP-ID fields with constant behavior, as well as improved
mode transition logic and a feedback option for decompressors with
limited memory resources.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
ROHC RTP : RTP/UDP/IP profile 0x0001 defined in RFC 3095 [2].
ROHC UDP : UDP/IP profile 0x0002 defined in RFC 3095 [2].
ROHC UDP-Lite : UDP-Lite/IP profile defined in this document.
ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document.
3. Background
3.1. Overview of the UDP-Lite Protocol
UDP-Lite is a transport protocol defined as an independent variant of
the UDP transport protocol. UDP-Lite is very similar to UDP, and it
allows applications that can tolerate errors in the payload to use a
checksum with an optional partial coverage. This is particularly
useful with IPv6 [6], in which the use of the transport-layer
checksum is mandatory.
UDP-Lite replaces the Length field of the UDP header with a Checksum
Coverage field. This field indicates the number of octets covered by
the 16-bit checksum, which is applied on a per-packet basis. The
coverage area always includes the UDP-Lite header and may cover the
entire packet, in which case UDP-Lite becomes semantically identical
to UDP. UDP-Lite and UDP do not share the same protocol identifier.
The UDP-Lite header format:
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
Like the UDP checksum, the UDP-Lite checksum is an end-to-end
mechanism against erroneous delivery of error sensitive data. This
checksum is mandatory with IPv6 [5] for both protocols. However,
unlike its UDP counterpart, the UDP-Lite checksum may not be
transmitted as all zeroes and cannot be disabled for IPv4 [5]. For
UDP, if the checksum is disabled (IPv4 only), the Checksum field
maintains a constant value and is normally not sent by the header
compression scheme. If the UDP checksum is enabled (mandatory for
IPv6), such an unpredictable field cannot be compressed and is sent
uncompressed. The UDP Length field, however, is always redundant and
can be provided by the IP module. Header compression schemes do not
normally transmit any bits of information for this field, as its
value can be inferred from the link layer.
For UDP-Lite, the checksum also has unpredictable values, and this
field must always be included as-is in the compressed header for both
IPv4 and IPv6. Furthermore, as the UDP Length field is redefined as
the Checksum Coverage field by UDP-Lite, this leads to different
properties for this field from a header-compression perspective.
The following summarizes the relationship between UDP and UDP-Lite:
- UDP-Lite and UDP have different protocol identifiers.
- The UDP-Lite checksum cannot be disabled for IPv4.
- UDP-Lite redefines the UDP Length field as the Checksum Coverage
field, with different semantics.
- UDP-Lite is semantically equivalent to UDP when the Checksum
Coverage field indicates the total length of the packet.
The next section provides a more detailed discussion of the behavior
of the Checksum Coverage field of UDP-Lite in relation to header
compression.
3.2. Expected Behaviours of UDP-Lite Flows
3.2.1. Per-Packet Behavior
As mentioned in the previous section, the checksum coverage value is
applied independently of other packets that may belong to the same
flow. Specifically, the value of the checksum coverage may indicate
that the UDP-Lite packet is either entirely covered by the checksum
or covered up to some boundary less than the packet size but
including the UDP-Lite header.
3.2.2. Inter-Packet Behavior
In relation to each other, UDP-Lite packets may exhibit one of three
possible change patterns, where within a sequence of packets the
value of the Checksum Coverage field is
1. changing, while covering the entire packet;
2. unchanging, covering up to a fixed boundary within the packet; or
3. changing, but it does not follow any specific pattern.
The first pattern above corresponds to the semantics of UDP, when the
UDP checksum is enabled. For this case, the checksum coverage field
varies according to the packet length and may be inferred from the IP
header, as is the UDP Length field value.
The second pattern corresponds to the case where the coverage is the
same from one packet to another within a particular sequence. For
this case, the Checksum Coverage field may be a static value defined
in the context, and it does not have to be sent in the compressed
header. For the third case, no useful change pattern can be
identified from packet to packet for the value of the checksum
coverage field, and it must be included in the compressed header.
3.2.3. Per-Flow behavior
It can be expected that any one of the above change patterns for
sequences of packets may be predominant at any time during the
lifetime of the UDP-Lite flow. A flow that predominantly follows the
first two change patterns described above may provide opportunities
for compressing the Checksum Coverage field for most of the packets.
3.3. Header Field Classification
In relation to the header field classification of RFC 3095 [2], the
first two patterns represent the case where the value of the Checksum
Coverage field behavior is fixed and may be either INFERRED (pattern
1) or STATIC (pattern 2). Pattern 3 is for the case where the value
varies unpredictably, the field is CHANGING, and the value must be
sent along with every packet.
Additional information regarding the analysis of the behavior of the
UDP-Lite fields may be found in Appendix A.
4. Rationale behind the Design of ROHC Profiles for UDP-Lite
4.1. Design Motivations
Simplicity is a strong motivation for the design of the UDP-Lite
header compression profiles. The profiles defined for UDP-Lite
should entail only a few simple modifications to the corresponding
profiles defined for UDP in RFC 3095 [2]. In addition, it is
desirable to include some of the improvements found in the ROHC IP-
Only profile [3]. Finally, whenever UDP-Lite is used in a manner
that is semantically identical to UDP, the compression efficiency
should be similar.
4.2. ROHC Considerations
The simplest approach to the definition of ROHC profiles for UDP-Lite
is to treat the Checksum Coverage field as an irregular value, and to
send it uncompressed for every packet. This may be achieved simply
by adding the field to the definition of the general packet format
[2]. However, then the compression efficiency would always be less
than for UDP.
Some care should be given to achieve compression efficiency for UDP-
Lite similar to that for UDP when the Checksum Coverage field behaves
like the UDP Length field. This requires the possibility to infer
the Checksum Coverage field when it is equal to the length of the
packet. Otherwise, this would put the UDP-Lite protocol at a
disadvantage over links where header compression is used, when its
behavior is made similar to the semantics of UDP.
A mechanism to detect the presence of the Checksum Coverage field in
compressed headers is thus needed. This is achieved by defining a
new packet type with the identifiers left unused in RFC 3095 [2].
5. ROHC Profiles for UDP-Lite
This section defines two ROHC profiles:
- RTP/UDP-Lite/IP compression (profile 0x0007)
- UDP-Lite/IP compression (profile 0x0008)
These profiles build on the specifications found in RFC 3095 [2],
with as little modification as possible. Unless it is explicitly
stated otherwise, the profiles defined herein follow the
specifications of ROHC UDP and ROHC RTP, respectively.
Note also that this document reuses the notation found in [2].
5.1. Context Parameters
As described in [2], information about previous packets is maintained
in a context. This includes information describing the packet stream
and compression parameters. Although the UDP and UDP-Lite protocols
share many commonalities, the differences in semantics as described
earlier render the following parameter inapplicable:
The parameter context(UDP Checksum)
The UDP-Lite checksum cannot be disabled, as opposed to UDP. The
parameter context(UDP Checksum) defined in [2] (section 5.7) is
therefore not used for compression of UDP-Lite.
In addition, the UDP-Lite checksum is always sent as-is in every
compressed packet. However, the Checksum Coverage field may not
always be sent in each compressed packet, and the following context
parameter is used to indicate whether the field is sent:
The parameter context(UDP-Lite Coverage Field Present)
Whether the UDP-Lite Checksum Coverage field is present or not in
the general packet format (see section 5.3.1) is controlled by the
value of the Coverage Field Present (CFP) flag in the context.
If context(CFP) is nonzero, the Checksum Coverage field is not
compressed, and it is present within compressed packets. If
context(CFP) is zero, the Checksum Coverage field is compressed,
and it is not sent. This is the case when the value of the
Checksum Coverage field follows a stable inter-packet change
pattern; the field has either a constant value or it has a value
equal to the packet length for most packets in a sequence (see
section 3.2).
Finally, the following context parameter is needed to indicate
whether the field should be inferred or taken from a value previously
saved in the context:
The parameter context(UDP-Lite Coverage Field Inferred)
When the UDP-Lite Checksum Coverage field is not present in the
compressed header (CFP=0), whether it is inferred is controlled by
the value of the Coverage Field Inferred (CFI) flag in the context.
If context(CFI) is nonzero, the Checksum Coverage field is inferred
from the packet length, similarly as for the UDP Length field in
ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is
decompressed by using context(UDP-Lite Checksum Coverage).
Therefore, when context(CFI) is updated to a nonzero value, the
value of the Checksum Coverage field stored in the context must
also be updated.
5.2. Initialization
Unless it is stated otherwise, the mechanisms of ROHC RTP and ROHC
UDP found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC
UDP-Lite profiles, respectively.
In particular, the considerations of ROHC UDP regarding the UDP SN
taking the role of the RTP Sequence Number apply to ROHC UDP-Lite.
Also, the static context for ROHC UDP-Lite may be initialized by
reusing an existing context belonging to a stream compressed by using
ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.
5.2.1. Initialization of the UDP-Lite Header [1]
The structure of the IR and IR-DYN packets and the initialization
procedures are the same as for the ROHC profiles for UDP [2], with
the exception of the dynamic part as specified for UDP. A 2-octet
field containing the checksum coverage is added before the Checksum
field. This affects the format of dynamic chains in both IR and IR-
DYN packets.
Dynamic part:
+---+---+---+---+---+---+---+---+
/ Checksum Coverage / 2 octets
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5 - 8).
CRC-STATIC: All other fields (octets 1 - 4).
5.2.2. Compressor and Decompressor Logic
The following logic must be used by both the compressor and the
decompressor for assigning values to the parameters context(CFP) and
context(CFI) during initialization:
Context(CFP)
During context initialization, the value of context(CFP) MUST be
set to a nonzero value if the Checksum Coverage field differs from
the length of the UDP-Lite packet, for any one IR or IR-DYN packet
sent (compressor) or received (decompressor); otherwise, the value
MUST be set to zero.
Context(CFI)
During context initialization, the value of context(CFI) MUST be
set to a nonzero value if the Checksum Coverage field is equal to
the length of the UDP-Lite packet within an IR or an IR-DYN packet
sent (compressor) or received (decompressor); otherwise, the value
MUST be set to zero.
5.3. Packet Formats
The general packet format, as defined in RFC 3095 [2], is modified to
include an additional field for the UDP-Lite checksum coverage. A
packet type is also defined to handle the specific semantics and
characteristics of this field.
5.3.1. General Packet Format
The general packet format of a compressed ROHC UDP-Lite header is
similar to the compressed ROHC RTP header ([2], section 5.7), with
modifications to the Checksum field, as well as additional fields for
handling multiple IP headers and for the UDP-Lite checksum coverage:
--- --- --- --- --- --- --- ---
: List of : variable, given by static chain
/ dynamic chains / (does not include SN)
: for additional IP headers : see also [3], section 3.2.
--- --- --- --- --- --- --- ---
: : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CCE (see 5.3.2)
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum + 2 octets
: :
--- --- --- --- --- --- --- ---
The list of dynamic header chains carries the dynamic header part for
each IP header in excess of the initial two, if there is any (as
indicated by the presence of corresponding header parts in the static
chain). Note that there is no sequence number at the end of the
chain, as SN is present within compressed base headers.
The order of the fields following the optional extension of the
general ROHC packet format is the same as the order between the
fields in the uncompressed header.
When the CRC is calculated, the Checksum Coverage field is CRC-
DYNAMIC.
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)
The ROHC profiles for UDP-Lite define a packet type to handle the
various possible change patterns of the checksum coverage. This
packet type may be used to manipulate the context values that control
the presence of the Checksum Coverage field within the general packet
format (i.e., context(CFP)) and how the field is decompressed (i.e.,
context(CFI)). The 2-octet Checksum Coverage field is always present
within the format of this packet (see section 5.3.1).
This type of packet is named Checksum Coverage Extension, or CCE, and
its updating properties depend on the final two bits of the packet
type octet (see format below). A naming scheme of the form
CCE(<some_property>) is used to uniquely identify the properties of a
particular CCE packet.
Although this packet type defines its own format, it may be
considered as an extension mechanism for packets of type 2, 1, or 0
[2]. This is achieved by substitution of the packet type identifier
of the first octet of the base header (the "outer" identifier) with
one of the unused packet types from RFC 3095 [2]. The substituted
identifier is then moved to the first octet of the remainder of the
base header (the "inner" identifier).
The format of the ROHC UDP-Lite CCE packet type is as follows:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+
: : (with inner type identifier)
/ Inner Base header / variable number of bits, given by
: : the inner packet type identifier
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
Updating properties: The updating properties of the inner packet
type carried within any of the CCE packets are always
maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend
R-0 and R-1* headers. In addition, CCE(ON) always updates
context(CFP); CCE(OFF) always updates context(CFP),
context(CFI), and context(UDP-Lite Checksum Coverage).
Appendix B provides an expanded view of the resulting format of the
CCE packet type.