RFC 3095
RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
5.8.5. Format of compressed lists in Extension 3
5.8.5.1. Format of IP Extension Header(s) field
In Extension 3 (section 5.7.5), there is a field called IP extension header(s). This section describes the format of that field. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | CL | ASeq| ESeq| Gseq| res | 1 octet +-----+-----+-----+-----+-----+-----+-----+-----+ : compressed AH Seq Number, 1 or 4 octets : if ASeq = 1 ----- ----- ----- ----- ----- ----- ----- ----- : compressed ESP Seq Number, 1 or 4 octets : if Eseq = 1 ----- ----- ----- ----- ----- ----- ----- ----- : compressed GRE Seq Number, 1 or 4 octets : if Gseq = 1 ----- ----- ----- ----- ----- ----- ----- ----- : compressed header list, variable length : if CL = 1 ----- ----- ----- ----- ----- ----- ----- ----- ASeq: indicates presence of compressed AH Seq Number ESeq: indicates presence of compressed ESP Seq Number GSeq: indicates presence of compressed GRE Seq Number CL: indicates presence of compressed header list res: reserved; set to zero when sending, ignored when received When Aseq, Eseq, or Gseq is set, the corresponding header item (AH, ESP, or GRE header) is compressed. When not set, the corresponding header item is sent uncompressed or is not present. The format of compressed AH, ESP and GRE Sequence Numbers can each be either of the following:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | LSB of sequence number | | 1 | |
+---+---+---+---+---+---+---+---+ +---+ +
| |
+ LSB of sequence number +
| |
+ +
| |
+---+---+---+---+---+---+---+---+
The format of the compressed header list field is described in
section 5.8.6.
5.8.5.2. Format of Compressed CSRC List
The Compressed CSRC List field in the RTP header part of an Extension
3 (section 5.7.5) is as in section 5.8.6.
5.8.6. Compressed list formats
This section describes the format of compressed lists. The format is
the same for CSRC lists and header lists. In CSRC lists, the items
are CSRC identifiers; in header lists, they are uncompressed or
compressed headers, as described in 5.8.4.2-4.
5.8.6.1. Encoding Type 0 (generic scheme)
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=0 |GP |PS | CC = m |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| XI 1, ..., XI m | m octets, or m * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+
| |
/ item 1, ..., item n / variable
| |
+---+---+---+---+---+---+---+---+
ET: Encoding type is zero.
PS: Indicates size of XI fields:
PS = 0 indicates 4-bit XI fields;
PS = 1 indicates 8-bit XI fields.
GP: Indicates presence of gen_id field.
CC: CSRC counter from original RTP header.
gen_id: Identifier for a sequence of identical lists. It is
present in U/O-mode when the compressor decides that it may use
this list as a future reference list.
XI 1, ..., XI m: m XI items. The format of an XI item is as
follows:
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Index |
+---+---+---+---+---+---+---+---+
X = 1 indicates that the item corresponding to the Index
is sent in the item 0, ..., item n list.
X = 0 indicates that the item corresponding to the Index is
not sent.
When 4-bit XI items are used and m > 1, the XI items are placed in
octets in the following manner:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| XI k | XI k + 1 |
+---+---+---+---+---+---+---+---+
Padding: A 4-bit padding field is present when PS = 0 and m is
odd. The Padding field is set to zero when sending and ignored
when receiving.
Item 1, ..., item n:
Each item corresponds to an XI with X = 1 in XI 1, ..., XI m.
5.8.6.2. Encoding Type 1 (insertion only scheme)
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | ET=1 |GP |PS | XI 1 | +---+---+---+---+---+---+---+---+ : gen_id : 1 octet, if GP = 1 +---+---+---+---+---+---+---+---+ | ref_id | +---+---+---+---+---+---+---+---+ / insertion bit mask / 1-2 octets +---+---+---+---+---+---+---+---+ | XI list | k octets, or (k - 1) * 4 bits / --- --- --- ---/ | : Padding : if PS = 0 and k is even +---+---+---+---+---+---+---+---+ | | / item 1, ..., item n / variable | | +---+---+---+---+---+---+---+---+ Unless explicitly stated otherwise, fields have the same meaning and values as for encoding type 0. ET: Encoding type is one (1). XI 1: When PS = 0, the first 4-bit XI item is placed here. When PS = 1, the field is set to zero when sending, and ignored when receiving. ref_id: The identifier of the reference CSRC list used when the list was compressed. It is the 8 least significant bits of the RTP Sequence Number in R-mode and gen_id (see section 5.8.2) in U/O-mode. insertion bit mask: Bit mask indicating the positions where new items are to be inserted. See Insertion Only scheme in section 5.8.3. The bit mask can have either of the following two formats:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 7-bit mask | bit 1 is the first bit
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 1 | | bit 1 is the first bit
+---+ 15-bit mask +
| | bit 7 is the last bit
+---+---+---+---+---+---+---+---+
XI list: XI fields for items to be inserted. When the insertion
bit mask has k ones, the total number of XI fields is k. When
PS = 1, all XI fields are in the XI list. When PS = 0, the
first XI field is in the XI 1 field, and the remaining k - 1
XI fields are in the XI list.
Padding: Present when PS = 0 and k is even.
item 1, ..., item n: One item for each XI field with the X bit
set.
5.8.6.3. Encoding Type 2 (removal only scheme)
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=2 |GP |res| Count |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| ref_id |
+---+---+---+---+---+---+---+---+
/ removal bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
Unless explicitly stated otherwise, fields have the same meaning
and values as in section 5.8.5.2.
ET: Encoding type is 2.
res: Reserved. Set to zero when sending, ignored when
received.
Count: Number of elements in ref_list.
removal bit mask: Indicates the elements in ref_list to be
removed in order to obtain the current list. See section
5.8.3. The removal bit mask has the same format as the
insertion bit mask of section 5.8.6.3.
5.8.6.4. Encoding Type 3 (remove then insert scheme)
See section 5.8.3 for a description of the Remove then insert
scheme.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=3 |GP |PS | XI 1 |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| ref_id |
+---+---+---+---+---+---+---+---+
/ removal bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
/ insertion bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
| XI list | k octets, or (k - 1) * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and k is even
+---+---+---+---+---+---+---+---+
| |
/ item 1, ..., item n / variable
| |
+---+---+---+---+---+---+---+---+
The fields in this header have the same meaning and formats as in
section 5.8.5.2, except when explicitly stated otherwise below.
ET: Encoding type is 3.
removal bit mask: See section 5.8.6.3.
5.8.7. CRC coverage for extension headers
All fields of extension headers are CRC-STATIC, with the following
exceptions which are CRC-DYNAMIC.
1) Entire AH header.
2) Entire ESP header.
3) Sequence number in GRE, Checksum in GRE
5.9. Header compression CRCs, coverage and polynomials
This chapter describes how to calculate the CRCs used in packet headers defined in this document. (Note that another type of CRC is defined for reconstructed units in section 5.2.5.)5.9.1. IR and IR-DYN packet CRCs
The CRC in the IR and IR-DYN packet is calculated over the entire IR or IR-DYN packet, excluding Payload and including CID or any Add-CID octet. For purposes of computing the CRC, the CRC field in the header is set to zero. The initial content of the CRC register is to be preset to all 1's. The CRC polynomial to be used for the 8-bit CRC is: C(x) = 1 + x + x^2 + x^85.9.2. CRCs in compressed headers
The CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner. The octets of the header are classified as either CRC-STATIC or CRC- DYNAMIC, and the CRC is calculated over: 1) the concatenated CRC-STATIC octets of the original header, placed in the same order as they appear in the original header, followed by 2) the concatenated CRC-DYNAMIC octets of the original header, placed in the same order as they appear in the original header. The intention is that the state of the CRC computation after 1) will be saved. As long as the CRC-STATIC octets do not change, the CRC calculation will then only need to process the CRC-DYNAMIC octets. In a typical RTP/UDP/IPv4 header, 25 octets are CRC-STATIC and 15 are CRC-DYNAMIC. In a typical RTP/UDP/IPv6 header, 49 octets are CRC- STATIC and 11 are CRC-DYNAMIC. This technique will thus reduce the computational complexity of the CRC calculation by roughly 60% for RTP/UDP/IPv4 and by roughly 80% for RTP/UDP/IPv6. Note: Whenever the CRC-STATIC fields change, the new saved CRC state after 1) is compared with the old state. If the states are identical, the CRC cannot catch the error consisting in the decompressor not having updated the static context. In U/O-mode the
compressor SHOULD then for a while use packet types with another CRC
length, for which there is a difference in CRC state, to ensure error
detection.
The initial content of the CRC register is preset to all 1's.
The polynomial to be used for the 3 bit CRC is:
C(x) = 1 + x + x^3
The polynomial to be used for the 7 bit CRC is:
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
The CRC in compressed headers is calculated over the entire original
header, before compression.
5.10. ROHC UNCOMPRESSED -- no compression (Profile 0x0000)
In ROHC, compression has not been defined for all kinds of IP
headers. Profile 0x0000 provides a way to send IP packets without
compressing them. This can be used for IP fragments, RTCP packets,
and in general for any packet for which compression of the header has
not been defined, is not possible due to resource constraints, or is
not desirable for some other reason.
After initialization, the only overhead for sending packets using
Profile 0x0000 is the size of the CID. When uncompressed packets are
frequent, Profile 0x0000 should be associated with a CID with size
zero or one octet. There is no need to associate Profile 0x0000 with
more than one CID.
5.10.1. IR packet
The initialization packet (IR packet) for Profile 0x0000 has the
following format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 |res|
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
: : (optional)
/ IP packet / variable length
: :
--- --- --- --- --- --- --- ---
res: Always zero.
Profile: 0.
CRC: 8-bit CRC, computed using the polynomial of section 5.9.1.
The CRC covers the first octet of the IR packet through the
Profile octet of the IR packet, i.e., it does not cover the
CRC itself or the IP packet.
IP packet: An uncompressed IP packet may be included in the IR
packet. The decompressor determines if the IP packet is
present by considering the length of the IR packet.
5.10.2. Normal packet
A Normal packet is a normal IP packet plus CID information. When the
channel uses small CIDs, and profile 0x0000 is associated with a CID
> 0, an Add-CID octet is prepended to the IP packet. When the
channel uses large CIDs, the CID is placed so that it starts at the
second octet of the Normal packet.
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| first octet of IP packet |
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| |
/ rest of IP packet / variable length
| |
+---+---+---+---+---+---+---+---+
Note that the first octet of the IP packet starts with the bit
pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any
reserved packet types. Hence, no bits in addition to the CID are
needed. The profile is reasonably future-proof since problems do not
occur until IP version 14.
5.10.3. States and modes
There are two modes in Profile 0x0000: Unidirectional mode and
Bidirectional mode. In Unidirectional mode, the compressor repeats
the IR packet periodically. In Bidirectional mode, the compressor
never repeats the IR packet. The compressor and decompressor always
start in Unidirectional mode. Whenever feedback is received, the
compressor switches to Bidirectional mode.
The compressor can be in either of two states: the IR state or the
Normal state. It starts in the IR state.
a) IR state: Only IR packets can be sent. After sending a small
number of IR packets (only one when refreshing), the compressor
switches to the Normal state.
b) Normal state: Only Normal packets can be sent. When in
Unidirectional mode, the compressor periodically transits back to
the IR state. The length of the period is implementation
dependent, but should be fairly long. Exponential backoff may be
used.
c) When feedback is received in any state, the compressor switches to
Bidirectional mode.
The decompressor can be in either of two states: NO_CONTEXT or
FULL_CONTEXT. It starts in NO_CONTEXT.
d) When an IR packet is received in the NO_CONTEXT state, the
decompressor first verifies the packet using the CRC. If the
packet is OK, the decompressor 1) moves to the FULL_CONTEXT state,
2) delivers the IP packet to upper layers if present, 3) MAY send
an ACK. If the packet is not OK, it is discarded without further
action.
e) When any other packet is received in the NO_CONTEXT state, it is
discarded without further action.
f) When an IR packet is received in the FULL_CONTEXT state, the
packet is first verified using the CRC. If OK, the decompressor
1) delivers the IP packet to upper layers if present, 2) MAY send
an ACK. If the packet is not OK, no action is taken.
g) When a Normal packet is received in the FULL_CONTEXT state, the
CID information is removed and the IP packet is delivered to upper
layers.
5.10.4. Feedback
The only kind of feedback in Profile 0x0000 is ACKs. Profile 0x0000
MUST NOT be rejected. Profile 0x0000 SHOULD be associated with at
most one CID. ACKs use the FEEDBACK-1 format of section 5.2. The
value of the profile-specific octet in the FEEDBACK-1 ACK is 0
(zero).
5.11. ROHC UDP -- non-RTP UDP/IP compression (Profile 0x0002)
UDP/IP headers do not have a sequence number which is as well-behaved
as the RTP Sequence Number. For UDP/IPv4, there is an IP-ID field
which may be echoed in feedback information, but when no IPv4 header
is present such feedback identification becomes problematic.
Therefore, in the ROHC UDP profile, the compressor generates a 16-bit
sequence number SN which increases by one for each packet received in
the packet stream. This sequence number is thus relatively well-
behaved and can serve as the basis for most mechanisms described for
ROHC RTP. It is called SN or UDP SN below. Unless stated otherwise,
the mechanisms of ROHC RTP are used also for ROHC UDP, with the UDP
SN taking the role of the RTP Sequence Number.
The ROHC UDP profile always uses p = -1 when interpreting the SN, since there will be no repetitions or reordering of the compressor- generated SN. The interpretation interval thus always starts with (ref_SN + 1).5.11.1. Initialization
The static context for ROHC UDP streams can be initialized in either of two ways: 1) By using an IR packet as in section 5.7.7.1, where the profile is two (2) and the static chain ends with the static part of an UDP packet. At the compressor, UDP SN is initialized to a random value when the IR packet is sent. 2) By reusing an existing context where the existing static chain contains the static part of a UDP packet, e.g., the context of a stream compressed using ROHC RTP (profile 0x0001). This is done with an IR-DYN packet (section 5.7.7.2) identifying profile 0x0002, where the dynamic chain corresponds to the prefix of the existing static chain that ends with the UDP header. UDP SN is initialized to the RTP Sequence Number if the earlier profile was profile 0x0001, and to a random number otherwise. For ROHC UDP, the dynamic part of a UDP packet is different from section 5.7.7.5: a two-octet field containing the UDP SN is added after the Checksum field. This affects the format of dynamic chains in IR and IR-DYN packets. Note: 2) can be used for packet streams which were initially assumed to be RTP streams, so that compression started with profile 0x0001, but were later found evidently not to be RTP streams.5.11.2. States and modes
ROHC UDP uses the same states and modes as ROHC RTP. Mode transitions and state logic are the same except when explicitly stated otherwise. Mechanisms dealing with fields in the RTP header (except the RTP SN) are not used. The decompressed UDP SN is never included in any header delivered to upper layers. The UDP SN is used in place of the RTP SN in feedback.
5.11.3. Packet types
The general format of a ROHC UDP packet is the same as for ROHC RTP (see beginning of section 5.7). Padding and CIDs are the same, as is the feedback packet type (5.7.6.1) and the feedback. IR and IR-DYN packets (5.7.7) are changed as described in 5.11.1. The general format of compressed packets is also the same, but there are differences in specific formats and extensions as detailed below. The differences are caused by removal of all RTP specific information except the RTP SN, which is replaced by the UDP SN. Unless explicitly stated below, the packet formats are as in sections 5.7.1-6. R-1 The TS field is replaced by an IP-ID field. The M flag has become part of IP-ID. The X bit has moved. The formats R-1-ID and R-1- TS are not used. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 | SN | +===+===+===+===+===+===+===+===+ | X | IP-ID | +---+---+---+---+---+---+---+---+ UO-1 The TS field is replaced by an IP-ID field. The M flag has become part of SN. Formats UO-1-ID and UO-1-TS are not used. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 | IP-ID | +===+===+===+===+===+===+===+===+ | SN | CRC | +---+---+---+---+---+---+---+---+ UOR-2
New format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 | SN |
+===+===+===+===+===+===+===+===+
| X | CRC |
+---+---+---+---+---+---+---+---+
5.11.4. Extensions
Extensions are as in 5.7.5, with the following exceptions:
Extension 0:
+---+---+---+---+---+---+---+---+
| 0 0 | SN | IP-ID |
+---+---+---+---+---+---+---+---+
Extension 1:
+---+---+---+---+---+---+---+---+
| 0 1 | SN | IP-ID |
+---+---+---+---+---+---+---+---+
| IP-ID |
+---+---+---+---+---+---+---+---+
Extension 2:
+---+---+---+---+---+---+---+---+
| 1 0 | SN | IP-ID2 |
+---+---+---+---+---+---+---+---+
| IP-ID2 |
+---+---+---+---+---+---+---+---+
| IP-ID |
+---+---+---+---+---+---+---+---+
IP-ID2: For outer IP-ID field.
Extension 3 is the same as Extension 3 in section 5.7.5, with the
following exceptions.
1) The initial flag octet has the following format:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 1 | S | Mode | I | ip | ip2 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Mode: Replaces R-TS and Tsc of 5.7.5. Provides mode information
as was earlier done in RTP header flags and fields.
ip2: Replaces rtp bit of 5.7.5. Moved here from the Inner IP
header flags octet.
2) The bit which was the ip2 flag in the Inner IP header flags in
5.7.5 is reserved. It is set to zero when sending and ignored
when receiving.
5.11.5. IP-ID
Treated as in ROHC RTP, but the offset is from UDP SN.
5.11.6. Feedback
Feedback is as for ROHC RTP with the following exceptions:
1) UDP SN replaces RTP SN in feedback.
2) The CLOCK option (5.7.6.6) is not used.
3) The JITTER option (5.7.6.7) is not used.
5.12. ROHC ESP -- ESP/IP compression (Profile 0x0003)
When the ESP header is being used with an encryption algorithm other
than NULL, subheaders after the ESP header are encrypted and cannot
be compressed. Profile 0x0003 is for compression of the chain of
headers up to and including the ESP header in this case. When the
NULL encryption algorithm is being used, other profiles can be used
and could give higher compression rates. See section 5.8.4.3.
This profile is very similar to the ROHC UDP profile. It uses the
ESP sequence number as the basis for compression instead of a
generated number, but is otherwise very similar to ROHC UDP. The
interpretation interval (value of p) for the ESP-based SN is as with
ROHC RTP (profile 0x0001). Apart from this, unless stated explicitly
below, mechanisms and formats are as for ROHC UDP.
5.12.1. Initialization
The static context for ROHC ESP streams can be initialized in either
of two ways:
1) by using an IR packet as in section 5.7.7.1, where the profile is
three (3) and the static chain ends with the static part of an ESP
header.
2) by reusing an existing context, where the existing static chain
contains the static part of an ESP header. This is done with an
IR-DYN packet (section 5.7.7.2) identifying profile 0x0003, where
the dynamic chain corresponds to the prefix of the existing static
chain that ends with the ESP header.
In contrast to ROHC UDP, no extra sequence number is added to the
dynamic part of the ESP header: the ESP sequence number is the only
element.
Note: 2) can be used for streams where compression has been initiated
under the assumption that NULL encryption was being used with ESP.
When it becomes obvious that an encryption algorithm other than NULL
is being used, the compressor may send an IR-DYN according to 2) to
switch to profile 0x0003 without having to send an IR packet.
5.12.2. Packet types
The packet types for ROHC ESP are the same as for ROHC UDP, except
that the ESP sequence number is used instead of the generated
sequence number of ROHC UDP. The ESP header is not part of any
compressed list in ROHC ESP.
6. Implementation issues
This document specifies mechanisms for the protocol and leaves many
details on the use of these mechanisms to the implementers. This
chapter is aimed to give guidelines, ideas and suggestions for
implementing the scheme.
6.1. Reverse decompression
This section describes an OPTIONAL decompressor operation to reduce
the number of packets discarded due to an invalid context.
Once a context becomes invalid (e.g., when more consecutive packet
losses than expected have occurred), subsequent compressed packets
cannot immediately be decompressed correctly. Reverse decompression
aims at decompressing such packets later instead of discarding them,
by storing them until the context has been updated and validated and
then attempting decompression.
Let the sequence of stored packets be i, i + 1, ..., i + k, where i
is the first packet and i + k is the last packet before the context
was updated. The decompressor will attempt to recover the stored
packets in reverse order, i.e., starting with i + k, and working back
toward i. When a stored packet has been reconstructed, its
correctness is verified using its CRC. Packets not carrying a CRC
must not be delivered to upper layers. Packets where the CRC
succeeds are delivered to upper layers in their original order, i.e.,
i, i + 1, ..., i + k.
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 is acceptable. For example, for video packets belonging to the
same video frame, the delay in packet arrivals does not cause
presentation time delay. Delay-insensitive streaming applications
can also be tolerant of such delay. If the decompressor cannot
determine whether the application can tolerate delay, it should not
perform reverse decompression.
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 proceeds to recover the last
packet stored. After decompression, the decompressor checks the
correctness of the reconstructed header using the CRC.
3. If the CRC indicates successful decompression, the decompressor
stores the complete packet and attempts to decompress the
preceding packet. In this way, the stored packets are recovered
in reverse order until no compressed packets are left. For each
packet, the decompressor checks the correctness of the
decompressed headers using the header compression CRC.
4. If the CRC indicates an incorrectly decompressed packet, the
reverse decompression attempt MUST be terminated and all remaining
uncompressed packets MUST be discarded.
5. Finally, the decompressor forwards all the correctly decompressed
packets to upper layers in their original order.
6.2. 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 one with the RTCP control information. The difference between the streams at the transport level is in the UDP port numbers: the RTP port number is always even, the RTCP port number is that number plus one and therefore always odd [RTP, section 10]. The ROHC header compressor implementation has several ways at hand to handle the RTCP stream: 1. One compressor/decompressor entity carrying both types of streams on the same channel, using CIDs to distinguish between them. For sending a single RTP stream together with its RTCP packets on one channel, it is most efficient to set LARGE_CIDS to false, send the RTP packets with the implied CID 0 and use the Add-CID mechanism to send the RTCP packets. 2. Two compressor/decompressor entities, one for RTP and another one for RTCP, carrying the two types of streams on separate channels. This means that they will not share the same CID number space. RTCP headers may simply be sent uncompressed using profile 0x0000. More efficiently, ROHC UDP compression (profile 0x0002) can be used.6.3. Implementation parameters and signals
A ROHC implementation may have two kinds of parameters: configuration parameters that are mandatory and must be negotiated between compressor and decompressor peers, and implementation parameters that are optional and, when used, stipulate how a ROHC implementation is to operate. Configuration parameters are mandatory and must be negotiated between compressor and decompressor, so that they have the same values at both compressor and decompressor, see section 5.1.1. Implementation parameters make it possible for an external entity to stipulate how an implementation of a ROHC compressor or decompressor should operate. Implementation parameters have local significance, are optional to use and are thus not necessary to negotiate between compressor and decompressor. Note that this does not preclude signaling or negotiating implementation parameters using lower layer functionality in order to set the way a ROHC implementation should operate. Some implementation parameters are valid only at either of compressor or decompressor. Implementation parameters may further be divided into parameters that allow an external entity to describe the way the implementation should operate and parameters that allow an external entity to trigger a specific event, i.e., signals.
6.3.1. ROHC implementation parameters at compressor
CONTEXT_REINITIALIZATION -- signal This parameter triggers a reinitialization of the entire context at the decompressor, both the static and the dynamic part. The compressor MUST, when CONTEXT_REINITIALIZATION is triggered, back off to the IR state and fully reinitialize the context by sending IR packets with both the static and dynamic chains covering the entire uncompressed headers until it is reasonably confident that the decompressor contexts are reinitialized. The context reinitialization MUST be done for all contexts at the compressor. This parameter may for instance be used to do context relocation at, e.g., a cellular handover that results in a change of compression point in the radio access network. NO_OF_PACKET_SIZES_ALLOWED -- value: positive integer This parameter may be set by an external entity to specify the number of packet sizes a ROHC implementation may use. However, the parameter may be used only if PACKET_SIZES is not used by an external entity. With this parameter set, the ROHC implementation at the compressor MUST NOT use more different packet sizes than the value this parameter stipulates. The ROHC implementation must itself be able to determine which packet sizes will be used and describe these to an external entity using PACKET_SIZES_USED. It should be noted that one packet size might be used for several header formats, and that the number of packet sizes can be reduced by employing padding and segmentation. NO_OF_PACKET_SIZES_USED _- value: positive integer This parameter is set by the ROHC implementation to indicate how many packet sizes it will actually use. It can be set to a large value to indicate that no particular attempt is made to minimize that number. PACKET_SIZES_ALLOWED -- value: list of positive integers (bytes) This parameter, if set, governs which packet sizes in bytes may be used by the ROHC implementation. Thus, packet sizes not in the set of values for this parameter MUST NOT be used. Hence, an external entity can mandate a ROHC implementation to produce packet sizes that fit pre-configured lower layers better. If this parameter is used to stipulate which packet sizes a ROHC implementation can use, the following rules apply: - A packet large enough to hold the entire IR header (both static and dynamic chain) MUST be part of the set of sizes, unless MRRU is set to a large enough value to allow segmentation. - The packet size likely to be used most frequently in the SO state SHOULD be part of the set.
- The packet size likely to be used most frequently in the FO state
SHOULD be part of the set.
PACKET_SIZES_USED -- values: set of positive integers (bytes)
This parameter describes which packet sizes a ROHC implementation
uses if NO_OF_PACKET_SIZES_ALLOWED or PACKET_SIZES_ALLOWED is used by
an external entity to stipulate how many packet sizes a ROHC
implementation should use. The information about used packet sizes
(bytes) in this parameter, may then be used to configure lower
layers.
PAYLOAD_SIZES -_ values: set of positive integer values (bytes)
This parameter is set by an external entity that wants to make use of
the PACKET_SIZES_USED parameter to indicate which payload sizes can
be expected.
When a ROHC implementation has a limited set of allowed packet sizes,
and the most preferable header format has a size that is not part of
the set, it has the following options:
- Choose the next larger header format from the allowed set. This is
probably the most efficient choice.
- Use the most preferable header format as if there were no
restrictions on size, and then add padding octets to complete a
packet of the next larger size in the allowed set.
- Use segmentation to fragment the packet into pieces that would make
up packets of sizes that are permissible (possibly after the
addition of padding to the last segment).
It should be noted that even if the two last parameters introduce the
possibility of restricting the number of packet sizes used, such
restrictions will have a negative impact on compression performance.
6.3.2. ROHC implementation parameters at decompressor
MODE -- values: [U-mode, O-mode, R-mode]
This parameter triggers a mode transition using the mechanism
described in chapter 5 when the parameter changes value, i.e., to U-
mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode) or
R-mode (Bidirectional Reliable mode). The mode transition is made
from the current mode to the new mode as signaled by the
implementation parameter. For example, if the current mode is
Bidirectional Optimistic mode, MODE should have the value O-mode. If
the MODE is changed to R-mode, a mode transition MUST be made from
Bidirectional Optimistic mode to Bidirectional Reliable mode. MODE
should not only serve as a trigger for mode transitions, but also
make it visible which mode ROHC operates in.
CLOCK_RESOLUTION -- value: nonnegative integer This parameter indicates the system clock resolution in units of milliseconds. A zero (0) value means that there is no clock available. If nonzero, this parameter allows the decompressor to use timer-based TS compression (section 4.5.4) and SN wraparound detection (section 5.3.2.2.4). In this case, its specific value is also significant for correctness of the algorithms. REVERSE_DECOMPRESSION_DEPTH -- value: nonnegative integer This parameter determines whether reverse decompression as described in section 6.1 should be used or not, and if used, to what extent. The value indicates the maximum number of packets that can be buffered, and thus possibly be reverse decompressed by the decompressor. A zero (0) value means that reverse decompression MUST NOT be used.6.4. Handling of resource limitations at the decompressor
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. It may, however, not be possible for the decompressor to accurately predict when it will run out of resources. ROHC allows the negotiated number of contexts to be larger than could be accommodated in the worst case. Then, as context resources are consumed, an attempt to set up a new context may be rejected by the decompressor, using the REJECT option of the feedback payload. Upon reception of a REJECT option, the compressor SHOULD wait for a while before attempting to compress additional streams destined for the rejecting node.6.5. Implementation structures
This section provides some explanatory material on data structures that a ROHC implementation will have to maintain in one form or another. It is not intended to constrain the implementations.6.5.1. Compressor context
The compressor context consists of a static part and a dynamic part. The content of the static part is the same as the static chain defined in section 5.7.7. The dynamic part consists of multiple elements which can be categorized into four types. a) Sliding Window (SW) b) Translation Table (TT) c) Flag d) Field
These elements may be common to all modes or mode specific. The
following table summarizes all these elements.
+--------+---------------------------+-------------+----------------+
| | Common to | Specific to | Specific to |
| | all modes | R-mode | U/O-mode |
+--------+---------------------------+-------------+----------------+
| SWs | GSW | R_CSW | UO_CSW |
| | | R_IESW | UO_IESW |
+--------+---------------------------+-------------+----------------+
| TTs | | R_CTT | UO_CTT |
| | | R_IETT | UO_IETT |
+--------+---------------------------+-------------+----------------+
| Flags | UDP Chksum | | ACKED |
| | TSS, TIS | | |
| | RND, RND2 | | |
| | NBO, NBO2 | | |
+--------+---------------------------+-------------+----------------+
| Fields | Profile | | CSRC_REF_ID |
| | C_MODE | | CSRC_GEN_ID |
| | C_STATE | | CSRC_GEN_COUNT |
| | C_TRANS | | IPEH_REF_ID |
| | TS_STRIDE (if TSS = 1) | | IPEH_GEN_ID |
| | TS_OFFSET (if TSS = 1) | | IPEH_GEN_COUNT |
| | TIME_STRIDE (if TIS = 1) | | |
| | CURR_TIME (if TIS = 1) | | |
| | MAX_JITTER_CD (if TIS = 1)| | |
| | LONGEST_LOSS_EVENT(O) | | |
| | CLOCK_RESOLUTION(O) | | |
| | MAX_JITTER(O) | | |
+--------+---------------------------+-------------+----------------+
1) GSW: Generic W_LSB Sliding Window
Each element in GSW consists of all the dynamic fields in the
dynamic chain (defined in section 5.7.7) plus the fields specified
in a) but excluding the fields specified in b).
a) Packet Arrival Time (if TIS = 1)
Scaled RTP Time Stamp (if TSS = 1) (optional)
Offset_i (if RND = 0) (optional)
b) UDP Checksum, TS Stride, CSRC list, IPv6 Extension Headers
2) R_CSW: CSRC Sliding Window in R-mode
R_IESW: IPv6 Extension Header Sliding Window in R-mode
UO_CSW: CSRC Sliding Window in U/O-mode
UO_IESW: IPv6 Extension Header Sliding Window in U/O-mode
Each element in R_CSW, R_IESW, UO_CSW and UO_IESW is defined in
section 6.5.3.
3) R_CTT: CSRC Translation Table in R-mode
R_IETT: IPv6 Extension Header Translation Table in U/O-mode
UO_CTT: CSRC Translation Table in U/O-mode
UO_IETT: IPv6 Extension Header Translation Table in U/O-mode
Each element in R_CTT and R_IETT is defined in section 5.8.1.1.
Each element in UO_CTT and UO_IETT is defined in section 5.8.1.2.
4) ACKED: Indicates whether or not the decompressor has ever acked
5) CURR_TIME: The current time value (used for context relocation
when timer-based timestamp compression is used)
6) All the other flags and fields are defined elsewhere in the ROHC
document.
6.5.2. Decompressor context
The decompressor context consists of a static part and a dynamic
part. The content of the static part is the same as the static chain
defined in section 5.7.7. The dynamic part consists of multiple
elements, one of which is the nonstatic reference header that
includes all the nonstatic fields. These nonstatic fields are the
fields in the dynamic chain defined in section 5.7.7, excluding UDP
Checksum and TS_Stride. All the remaining elements can be
categorized into four types:
a) Sliding Window (SW)
b) Translation Table (TT)
d) Flag
e) Field
These elements may be mode specific or common to all modes. The
following table summarizes all these elements.
+--------+---------------------------+-------------+----------------+
| | Common to | Specific to | Specific to |
| | all modes | R-mode | U/O-mode |
+--------+---------------------------+-------------+----------------+
| SWs | | R_CSW | UO_CSW |
| | | R_IESW | UO_IESW |
+--------+---------------------------+-------------+----------------+
| TTs | | R_CTT | UO_CTT |
| | | R_IETT | UO_IETT |
+--------+---------------------------+-------------+----------------+
| Flags | UDP Checksum | | ACKED |
| | TSS, TIS | | |
| | RND, RND2 | | |
| | NBO, NBO2 | | |
+--------+---------------------------+-------------+----------------+
| Fields | Profile | | CSRC_GEN_ID |
| | D_MODE | | IPEH_GEN_ID |
| | D_STATE | | PRE_SN_V_REF |
| | D_TRANS | | |
| | TS_STRIDE (if TSS = 1) | | |
| | TS_OFFSET (if TSS = 1) | | |
| | TIME_STRIDE (if TIS = 1) | | |
| | PKT_ARR_TIME (if TIS = 1) | | |
| | LONGEST_LOSS_EVENT(O) | | |
| | CLOCK_RESOLUTION(O) | | |
| | MAX_JITTER(O) | | |
+--------+---------------------------+-------------+----------------+
1) ACKED: Indicates whether or not ACK has ever been sent.
2) PKT_ARR_TIME: The arrival time of the packet that most recently
decompressed and verified using CRC.
PRE_SN_V_REF: The sequence number of the packet verified before
the most recently verified packet.
CSRC_GEN_ID: The CSRC gen_id of the most recently received packet.
IPEH_GEN_ID: The IPv6 Extension Header gen_id of the most recently
received packet.
3) The remaining elements are as defined in the compressor context.
6.5.3. List compression: Sliding windows in R-mode and U/O-mode
In R-mode list compression (see section 5.8.2.1), each entry in the
sliding window, both at the compressor side and at the decompressor
side, has the following structure:
+---------------------+--------+------------+ | RTP Sequence Number | icount | index list | +---------------------+--------+------------+ The table index list contains a list of index. Each of these index corresponds to the item in the original list carried in the packet identified by the RTP Sequence Number. The mapping between the index and the item is identified in the translation table. The icount field carries the number of index in the following index list. In U/O-mode list compression, each entry in the sliding window at both the compressor side and decompressor side has the following structure. +--------+--------+------------+ | Gen_id | icount | index list | +--------+--------+------------+ The icount and index list fields are the same as defined in R-mode. Instead of using the RTP Sequence Number to identify each entry, the Gen_id is included in the sliding window in U/O-mode.7. Security Considerations
Because encryption eliminates the redundancy that header compression schemes try to exploit, there is some inducement to forego encryption of headers in order to enable 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. ROHC compression is transparent with regard to the RTP Sequence Number and RTP Timestamp fields, so the values of those fields can be used as the basis of payload encryption schemes (e.g., for computation of an initialization vector). 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 also valid UDP checksums. Such corruption may be detected with end-to-end authentication and integrity mechanisms which will not be affected by the compression. Moreover, this header compression scheme uses an internal checksum for verification of reconstructed 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.8. IANA Considerations
The ROHC profile identifier is a non-negative integer. In many negotiation protocols, it will be represented as a 16-bit value. Due to the way the profile identifier is abbreviated in ROHC packets, the 8 least significant bits of the profile identifier have a special significance: Two profile identifiers with identical 8 LSBs should be assigned only if the higher-numbered one is intended to supersede the lower-numbered one. To highlight this relationship, profile identifiers should be given in hexadecimal (as in 0x1234, which would for example supersede 0x0A34). Following the policies outlined in [IANA-CONSIDERATIONS], the IANA policy for assigning new values for the profile identifier shall be Specification Required: values and their meanings must be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. In the 8 LSBs, the range 0 to 127 is reserved for IETF standard-track specifications; the range 128 to 254 is available for other specifications that meet this requirement (such as Informational RFCs). The LSB value 255 is reserved for future extensibility of the present specification. The following profile identifiers are already allocated: Profile Document Usage identifier 0x0000 RFCthis ROHC uncompressed 0x0001 RFCthis ROHC RTP 0x0002 RFCthis ROHC UDP 0x0003 RFCthis ROHC ESP
9. Acknowledgments
Earlier header compression schemes described in [CJHC], [IPHC], and [CRTP] have been important sources of ideas and knowledge. The editor would like to extend his warmest thanks to Mikael Degermark, who actually did a lot of the editing work, and Peter Eriksson, who made a copy editing pass through the document, significantly increasing its editorial consistency. Of course, all remaining editorial problems have then been inserted by the editor. Thanks to Andreas Jonsson (Lulea University), who supported this work by his study of header field change patterns. Finally, this work would not have succeeded without the continual advice in navigating the IETF standards track, garnished with both editorial and technical comments, from the IETF transport area directors, Allison Mankin and Scott Bradner.10. Intellectual Property Right Claim Considerations
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
11. References
11.1. Normative References
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [HDLC] Simpson, W., "PPP in HDLC-like framing", STD 51, RFC 1662, July 1994. [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998. [NULL] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With Ipsec", RFC 2410, November 1998. [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [MINE] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [GRE1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [GRE2] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, August 2000. [ASSIGNED] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
11.2. Informative References
[VJHC] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999. [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [CRTPC] Degermark, M., Hannu, H., Jonsson, L.E., Svanbro, K., "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine, Volume 7, number 4, pp. 20-25, August 2000. [REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, June 2001. [LLG] Svanbro, K., "Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression", Work in Progress. [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
12. Authors' Addresses
Carsten Bormann, Editor Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany Phone: +49 421 218 7024 Fax: +49 421 218 7000 EMail: cabo@tzi.org Carsten Burmeister Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany Phone: +49-6103-766-263 Fax: +49-6103-766-166 EMail: burmeister@panasonic.de Mikael Degermark The University of Arizona Dept of Computer Science P.O. Box 210077 Tucson, AZ 85721-0077, USA Phone: +1 520 621-3498 Fax: +1 520 621-4642 EMail: micke@cs.arizona.edu Hideaki Fukushima Matsushita Electric Industrial Co., Ltd006, Kadoma, Kadoma City, Osaka, Japan Phone: +81-6-6900-9192 Fax: +81-6-6900-9193 EMail: fukusima@isl.mei.co.jp
Hans Hannu Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Phone: +46 920 20 21 84 Fax: +46 920 20 20 99 EMail: hans.hannu@ericsson.com Lars-Erik Jonsson Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 EMail: lars-erik.jonsson@ericsson.com Rolf Hakenberg Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany Phone: +49-6103-766-162 Fax: +49-6103-766-166 EMail: hakenberg@panasonic.de Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134, USA Phone: +1 408-527-6169 EMail: tmima@cisco.com
Khiem Le 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Phone: +1-972-894-4882 Fax: +1 972 894-4589 EMail: khiem.le@nokia.com Zhigang Liu 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Phone: +1 972 894-5935 Fax: +1 972 894-4589 EMail: zhigang.liu@nokia.com Anton Martensson Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm, Sweden Phone: +46 8 404 3881 Fax: +46 8 757 5550 EMail: anton.martensson@era.ericsson.se Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan Phone: +81-6-6900-9192 Fax: +81-6-6900-9193 EMail: akihiro@isl.mei.co.jp
Krister Svanbro Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Phone: +46 920 20 20 77 Fax: +46 920 20 20 99 EMail: krister.svanbro@ericsson.com Thomas Wiebke Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany Phone: +49-6103-766-161 Fax: +49-6103-766-166 EMail: wiebke@panasonic.de Takeshi Yoshimura NTT DoCoMo, Inc. 3-5, Hikarinooka Yokosuka, Kanagawa, 239-8536, Japan Phone: +81-468-40-3515 Fax: +81-468-40-3788 EMail: yoshi@spg.yrp.nttdocomo.co.jp Haihong Zheng 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Phone: +1 972 894-4232 Fax: +1 972 894-4589 EMail: haihong.zheng@nokia.com
(next page on part 7)
