Network Working Group L-E. Jonsson
INTERNET-DRAFT P. Kremer
Expires: January 2006 Ericsson
July 18, 2005
ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-13.txt>
Status of this memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, each author accepts the provisions
of Section 3 of BCP 78.
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 to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract
This document clarifies common misinterpretations and some ambiguous
points of RFC 3095, which defines the framework and four profiles of
the robust and efficient header compression scheme (ROHC). It also
addresses minor interpretation details of RFC 3241 (ROHC over PPP),
RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles).
These issues have been identified by members of the ROHC working
group, during implementation and at interoperability test events.
Jonsson, et al. [Page 1]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
Table of Contents
1. Introduction.....................................................3
2. CRC calculation and coverage issues..............................4
2.1. CRC calculation.............................................4
2.2. Padding octet in CRC........................................4
2.3. CRC coverage in CRC feedback options........................4
2.4. CRC coverage of the ESP NULL header.........................4
3. Enhanced mode transition procedures..............................4
3.1. Modified transition logic for enhanced transitions..........5
3.2. Transition from Reliable to Optimistic mode.................6
3.3. Transition to Unidirectional mode...........................6
4. Timestamp encoding considerations................................7
4.1. Encoding used for compressed TS bits........................7
4.2. (De)compression of TS without transmitted TS bits...........7
4.3. Interpretation intervals for TS encoding....................8
4.4. TS_STRIDE for scaled timestamp encoding.....................8
4.5. TS wraparound with scaled timestamp encoding................9
4.6. Recalculating TS_OFFSET.....................................9
4.7. TS_STRIDE and the Tsc flag in Extension 3..................10
4.8. Using timer-based compression..............................10
5. List compression issues.........................................11
5.1. Generic extension header list..............................11
5.2. CSRC list items in RTP dynamic chain.......................11
5.3. RTP dynamic chain..........................................11
5.4. Compressed lists in UO-1-ID packets........................11
5.5. Bit masks in list compression..............................12
5.6. Headers compressed with list compression...................12
5.7. ESP NULL header list compression...........................12
6. Updating properties.............................................13
6.1. Implicit updates...........................................13
6.2. Updating properties of UO-1*...............................13
7. Context management and CID/context re-use.......................14
7.1. Compressor and decompressor MUST keep MAX_CID contexts.....14
7.2. CID/context re-use.........................................14
7.2.1. Re-using a CID/context with the same profile..........14
7.2.2. Re-using a CID/context with a different profile.......15
7.3. Context updating properties for IR packets.................15
8. Other protocol clarifications...................................16
8.1. Meaning of NBO.............................................16
8.2. IP-ID......................................................16
8.3. Extension-3 in UO-1-ID packets.............................16
8.4. Extension-3 in UOR-2* packets..............................17
8.5. Multiple SN options in one feedback packet.................17
8.6. Multiple CRC options in one feedback packet................17
8.7. Packet decoding during mode transition.....................17
8.8. How to respond to lost feedback links?.....................18
8.9. What does "presumed zero if absent" mean on page 88?.......18
8.10. UOR-2 in profile 2 (UDP)..................................18
8.11. Sequence number LSB's in IP extension headers.............18
8.12. Expecting UOR-2 ACKs in O-mode............................18
Jonsson, et al. [Page 2]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
8.13. Compression of SN in AH and GRE extension headers.........19
9. ROHC negotiation clarifications.................................20
10. PROFILES suboption in ROHC-over-PPP............................20
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......20
12. Test configuration.............................................21
13. Security considerations........................................21
14. IANA considerations............................................21
15. Acknowledgment.................................................22
16. References.....................................................22
16.1. Normative References......................................22
16.2. Informative References....................................22
17. Authors' Addresses.............................................22
Appendix A - Sample CRC algorithm..................................23
Appendix B - Potential improvements in updated profiles............25
1. Introduction
ROHC [1] defines a robust and efficient header compression algorithm,
and its description is rather long and complex. During the
implementation and the interoperability tests of the algorithm some
unclear areas have been identified. This document tries to collect
and clarify these points. A few minor interpretation details of RFC
3241 [2] (ROHC over PPP), RFC 3843 [3] (ROHC IP-only profile), and
RFC 4019 [5] (ROHC UDP-Lite profiles) are also addressed in this
document (chapter 10-11). Note that all section and chapter
references in this document refer to [1], where not stated otherwise.
Jonsson, et al. [Page 3]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
2. CRC calculation and coverage issues
2.1. CRC calculation
ROHC uses CRC checksum in order to provide some protection against
bit errors. CRC is used in the segmentation protocol and in the
compressed packets, as well.
Section 5.2.5.2 describes the segmentation protocol and refers to
[3], which describes a well-defined CRC algorithm for 32 bit
checksums. Although, Section 5.9 only defines the polynomials for 3,
7 and 8-bit long checksum, the same algorithm can be used in these
cases as well.
A PERL implementation of the algorithm (written by Carsten Bormann)
can be found in Appendix A.
2.2. Padding octet in CRC
According to Section 5.9.1, in case of IR and IR-DYN packets the CRC
"is calculated over the entire IR or IR-DYN packet, excluding Payload
and including CID or Add-CID octet". Padding isn't meant to be
meaningful part of a packet and not included in CRC calculation. As
a result, CRC doesn't cover the Add-CID octet for CID 0, either.
2.3. CRC coverage in CRC feedback options
Section 5.7.6.3 states "The CRC option contains an 8-bit CRC computed
over the entire feedback payload, without the packet type and code
octet, but including any CID fields, using the polynomial of section
5.9.1". However, it does not mention how the "size" field is handled,
if present. Since the "size" field can be considered an extension of
the "code" field, it must be treated as the "code" field, i.e. the
"size" field is not covered by the CRC.
2.4. CRC coverage of the ESP NULL header
Section 5.8.7 gives the CRC coverage of the ESP NULL header as
"Entire ESP header". This should be interpreted as being only the
initial part of the header (i.e. SPI and Sequence number), and not
the trailer part at the end of the payload. Therefore, the ESP NULL
header will have the same CRC coverage as the ESP header used in the
ESP profile (section 5.7.7.7).
3. Enhanced mode transition procedures
To reduce transmission overhead and computational complexity
(including CRC calculation) associated with feedback packets sent for
each decompressed packet during mode transition, a decompressor can
be implemented with slightly modified mode transition procedures,
compared to those defined in [1].
Jonsson, et al. [Page 4]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
These modifications affect transitions to Optimistic and
Unidirectional modes of operation, i.e. the transitions described in
sections 5.6.5 and 5.6.6 of [1], and make those transition diagrams
more consistent with the diagram describing the transition to R-mode.
However, the differences between the original diagrams of [1] were
motivated by robustness concerns for mode transitions to Optimistic
and Unidirectional modes. To avoid deadlock situations in mode
transitions, these aspects must be addressed also when a decompressor
implements the enhanced transition procedures, and that is done by
following a slightly modified definition of the decompressor
transition states. All aspects related to implementation of the
enhanced transition procedures are described in subsequent chapters.
Note that these modified operations should be seen only as an
improved decompressor implementation, since interoperability is not
at all affected. A decompressor implemented according to the
optimized procedures would be able to interoperate with an RFC3095
compressor, as well as a decompressor implemented according to the
procedures described in RFC3095 would do.
3.1. Modified transition logic for enhanced transitions
The intent with these enhanced transition procedures is to allow the
decompressor to stop sending feedback packets for all packets
decompressed during the second half of the transition procedure, i.e.
after an appropriate IR/IR-DYN/UOR-2 packet has been received from
the compressor. In the transition diagrams, sections 3.2 and 3.3
below, this is realized by allowing the decompressor transition
parameter (D_TRANS) to be set to P (Pending) at that stage. However,
as mentioned above, there are robustness concerns related to this
optimization, and to avoid deadlock situations with never completed
transitions as a result of feedback losses, the decompressor must
continue to send feedback at least periodically, also when in Pending
transition state. That would be the equivalence of enhancing the
D_TRANS parameter definition in section 5.6.1 of [1], to include a
definition of Pending state operation.
- D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode
transition can be initiated only when D_TRANS is D. While D_TRANS
is I, the decompressor sends a NACK or ACK carrying a CRC option
for each packet received. When D_TRANS is set to P, the
decompressor do not have to send a NACK or ACK for each packet
received, but it MUST continue to send feedback on a regular
basis, and all feedback packets sent MUST include the CRC option.
This ensures that all mode transitions will be completed also in
case of feedback losses.
Jonsson, et al. [Page 5]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
3.2. Transition from Reliable to Optimistic mode
The enhanced procedure for transition from Reliable to Optimistic
mode is shown below:
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
3.3. Transition to Unidirectional mode
The enhanced procedure for transition to Unidirectional mode is shown
on the following figure:
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN/UOR-2(SN,U) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| | D_MODE= U
Jonsson, et al. [Page 6]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
4. Timestamp encoding considerations
4.1. Encoding used for compressed TS bits
RTP Timestamp values (TS) are always encoded using W-LSB encoding,
both when sent scaled and when sent unscaled. For TS values sent in
Extension 3, W-LSB encoded values are sent using the self-describing
variable-length format (section 4.5.6), and this applies to both
scaled and unscaled values.
4.2. (De)compression of TS without transmitted TS bits
RFC 3095 explains that SO-state provides the most efficient
compression within ROHC RTP. In this state, apart from packet type
identification and the error detection CRC, only RTP sequence number
(SN) bits have to be transmitted in RTP compressed headers. All other
fields are then omitted either because they are unchanged or because
they can be reconstructed through a function from the SN (i.e. by
combining the transmitted SN bits with state information from the
context). Although it is never spelled out explicitly what fields are
inferred from the SN in this way, one should be able to figure out
that this principle applies to the IP Identification (IP-ID) field
and the RTP Timestamp (TS) field.
IP-ID compression and decompression, both with and without
transmitted IP-ID bits in the compressed header, are well defined in
section 4.5.5 (see section 8.2 of this document). However, for TS it
is only defined how to decompress based on actual TS bits in the
compressed header, either scaled or unscaled, but not how to infer
the TS from the SN, i.e. the SO-state operation. Although the general
idea is simple, the actual operation must be clearly defined to
ensure interoperability. There are also inconsistent text pieces that
might confuse an implementer and result in non-interoperable
implementations. This section therefore provides the necessary
clarifications to SN-to-TS decompression, i.e. decompression of TS
(scaled or unscaled) when no TS bits are transmitted in the
compressed header.
When no TS bits are transmitted in the compressed header, the encoded
TS value (scaled or unscaled) is to be decompressed assuming a linear
extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope.
Section 5.7 defines the potential values for default-slope as:
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see section 4.5.3), and default-slope(TS) = 1.
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE).
Jonsson, et al. [Page 7]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
What must be noted here is that no slope value is used other than the
default-slope value, as defined in section 5.7. There is confusing
text in section 5.5.1.2 that might mistakenly be interpreted as if
the slope can have different values and be "learned", which is
incorrect. The default-slope from 5.7 is always the value used when
decompressing TS based on SN.
4.3. Interpretation intervals for TS encoding
Section 4.5.4 defines the interpretation interval, p, for timer-based
compression of the RTP timestamp. However, Section 5.7 defines a
different interpretation interval, which is defined as the
interpretation interval to use for all TS values. It is thus unclear
which p-value to use, at least for timer-based compression.
The way this should be interpreted is that the p-value differs
depending on whether timer-based compression is enabled or not. For
timer-based compression, the interpretation interval of section
4.5.4, p = 2^(k-1) - 1, is used for TS. Otherwise, the interval of
section 5.7, p = 2^(k-2) - 1, is used for TS with regular W-LSB
encoding.
Since two different p-values are used, the compressor must take this
into account during the process of enabling timer-based compression.
Before timer-based compression can be used, the decompressor will
have to inform the compressor (on a per-channel basis) about its
clock resolution. Further, the compressor has to send (on a per-
context basis) a non-zero TIME_STRIDE to the decompressor.
When the compressor is confident that the decompressor has received
the TIME_STRIDE value, it can switch to timer-based compression.
During this transition from window-based compression to timer-based
compression, it is necessary that the compressor keep k large enough
to cover both interpretation intervals.
4.4. TS_STRIDE for scaled timestamp encoding
The timestamp stride (TS_STRIDE) is defined as the expected increase
in the timestamp value between two RTP packets with consecutive
sequence numbers. TS_STRIDE is set by the compressor and explicitly
communicated to the decompressor, and it is used either as the
scaling factor for scaled TS encoding, or constitutes the default-
slope used when decompressing an unscaled TS through a linear
extrapolation from the SN (see also section 4.2 above).
The relation between TS and TS_SCALED, given by the following
equality in section 4.5.3, defines the mathematical meaning of
TS_STRIDE:
TS = TS_SCALED * TS_STRIDE + TS_OFFSET
Jonsson, et al. [Page 8]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
In the compression step explained following this core equality of
section 4.5.3, TS_SCALED is incorrectly written as TS / TS_STRIDE.
This formula is incorrect both because it excludes TS_OFFSET, and
because it would prevent a TS_STRIDE value of 0. If "/" were a
generally unambiguously defined operation meaning "the integral part
of the result from dividing X by Y", the absence of TS_OFFSET could
be explained, but the formula still lacks a proper output for
TS_STRIDE equal to 0. As the core equality above does not prevent
setting TS_STRIDE to 0, and there is no reason not to allow a
compressor to do that, the formula of "2. Compression" should not be
read as having any formal meaning.
4.5. TS wraparound with scaled timestamp encoding
In the scaled timestamp encoding section, 4.5.3, it is said in point
4 and 5 that the compressor is not required to initialize TS_OFFSET
at wraparound, but that it is required to increase the number of bits
sent for the scaled TS value when there is a TS wraparound. The
decompressor is also required to detect and cope with TS wraparound,
including updating TS_OFFSET. This has been found to be non-trivial
to do, as well as hard to make interoperable and robust. The gain is
also insignificant, as TS wraparound happens very seldom.
It is therefore recommended not to follow point 4-5 of section 4.5.3,
and instead the compressor is recommended to reinitialize TS_OFFSET
upon TS wraparound, by sending unscaled TS. This is equivalent of
replacing point 4-5 with:
4. Offset at wraparound: If the value of TS_STRIDE is not equal
to a power of two, wraparound of the unscaled 32-bit TS will
change the value of TS_OFFSET. When this happens, the
compressor must reinitialize TS_OFFSET by sending unscaled TS,
as in 1 above.
It should be noted that by following this recommendation for the
compressor to reinitialize TS_OFFSET at wraparound, there will be no
problems interacting with a decompressor that still tries to follow
4.5.3 points 4-5. For a decompressor that assumes the compressor will
follow the above recommendation, there is a risk of the decompressor
context becoming invalid. Considering the size if the TS number
space, and thus the number of packets between each TS wraparound, the
potential cost of this is considered negligible.
4.6. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the
established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
To ensure correct decompression of subsequent packets, the
decompressor should therefore always recalculate the RTP TS modulo,
TS_OFFSET, when a packet with an unscaled TS value is received.
Jonsson, et al. [Page 9]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
4.7. TS_STRIDE and the Tsc flag in Extension 3
The Tsc flag in Extension 3 indicates whether TS is scaled or not. It
must be noted that the Tsc value apply to all TS bits, also if there
are no TS bits in the extension itself.
Note also that if Tsc=1, TS is scaled using context(TS_STRIDE), not
value(TS_STRIDE) as is said in the legend for Extension 3 in section
5.7.5.
When a compressor uses Extension 3 to re-establish a new value for
TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some
packets until decompressor confidence is obtained. When the TS_STRIDE
field is present in Extension 3, the Tsc flag must thus be set to 0.
4.8. Using timer-based compression
Timer-based compression of the RTP timestamp, as described in section
4.5.4, may be used to reduce the number of transmitted timestamp bits
(bytes) needed when the timestamp can not be inferred from the SN. It
should thus be noted that timer-based compression has no influence on
decompression of packets where no timestamp bits are sent, in that
case the timestamp is just linearly inferred from the SN (see section
4.2 of this document).
Whether to use timer-based compression or not is controlled by the
TIME_STRIDE control field, which can be set either by an IR, an IR-
DYN, or by a compressed packet with extension 3. The compressor turns
on timer-based compression by setting TIME_STRIDE to a value > 0, but
that can be done first after the decompressor has declared its clock
resolution, which is done by sending a CLOCK feedback option for any
CID on the channel.
Jonsson, et al. [Page 10]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
5. List compression issues
5.1. Generic extension header list
Section 5.7.7.4 defines the static and dynamic parts of the IPv4
header. This section indicates a 'Generic extension header list'
field in the dynamic chain, which has a variable length. The
detailed description of this field can be found in Section 5.8.6.1.
The generic extension header list starts with an octet that is always
present, so its length is one octet, at least. If the 'GP' bit in
the first octet is set to 1 then the length of the list is two
octets, even if the list is empty.
5.2. CSRC list items in RTP dynamic chain
Section 5.7.7.6 defines the static and dynamic parts of the RTP
header. This section indicates a 'Generic CSRC list' field in the
dynamic chain, which has a variable length. This field uses the same
encoding rules as the 'Generic extension header list' in the IPv4
header, so the same rules apply to its length.
5.3. RTP dynamic chain
Section 5.7.7.6 defines the static and dynamic parts of the RTP
header. In the dynamic part, a 'CC' field indicates the number of
CSRC items present in the 'Generic CSRC list'. A 'CC' field can also
be found within the 'Generic CSRC list' (when present), and these
fields would then have the same meaning. In order to decode a
compressed packet correctly it's necessary to know the 'CC' value
because it has serious impact on the packet's length. In normal
case, the values of the fields are equal.
Proposed behavior if the values are different:
Both fields are within the RTP dynamic part but only the second
'CC' field resides inside the 'Generic CSRC list' together with
the XI items. Since the 'CC' value determines the number of XI
items in the CSRC list and isn't used otherwise, the first CC
field should be ignored and only the second field (inside the CSRC
list) should be used for incoming packets. For outgoing packets
both fields should be set to the same value.
5.4. Compressed lists in UO-1-ID packets
This section describes the situation when a UO-1-ID packet carries a
compressed list. Compressed lists are encoded using Encoding Type 0
(section 5.7.5 and 5.8.6.1) and every list may have a unique
identifier (gen_id). The identifier is present in U/O-mode when the
compressor decides that it may use this list as a future reference.
Jonsson, et al. [Page 11]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
On one hand, the decompressor shouldn't save the list because UO-1-ID
packets doesn't update the context. On the other hand, the
decompressor updates its translation table whenever an (Index, item)
pair is received (section 5.8.1). The decompressor must be able to
handle such a packet, thus it has to behave as described in the
latter case. According to section 5.8.1.2, the compressor must
increment Counter by 1.
5.5. Bit masks in list compression
A 7-bit or 15-bit mask may be used in the insertion and/or removal
schemes for compressed lists. It should be noted that even if a list
has more than 7 items, a 7-bit mask could be used as long as changes
are only applied in the first part of the reference list, and items
with an index not covered by the 7-bit mask are thus kept unchanged.
5.6. Headers compressed with list compression
In section 5.8, it is stated that headers which can be part of
extension header chains INCLUDE AH, null ESP, minimal encapsulation
(MINE), GRE, and IPv6 extensions. This list of headers which can be
compressed is correct, but the word INCLUDE should not be there,
since only the header types listed can actually be handled. It should
further be noted that for the Minimal Encapsulation (MINE) header,
there is no explicit discussion of how to compress it, as the header
is either sent uncompressed or fully compressed away.
5.7. ESP NULL header list compression
Due to the offset of the fields in the trailer part of the ESP
header, a compressor must only compress packets containing at most
one NULL ESP header.
Jonsson, et al. [Page 12]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
6. Updating properties
6.1. Implicit updates
If an updating packet (e.g. R-0-CRC or UO-0) contains information
about a specific field X (compressed RTP sequence number, typically),
then X is updated according to the content of that packet. But this
packet implicitly updates all other inferred fields (i.e. RTP
timestamp) according to the current mode and the appropriate mapping
function of the updated and the inferred fields.
An updating packet thus updates the reference values of all header
fields, either explicitly or implicitly, with an exception for the
UO-1-ID packet, which only updates TS, SN, IP-ID, and sequence
numbers of IP extension headers (see 5.7.3). In UO-mode, all packets
are updating packets, while in R-mode all packets with a CRC are
updating packets.
For example, a UO-0 packet contains the compressed RTP sequence
number (SN). Such a packet also implicitly updates RTP timestamp,
IPv4 ID, and sequence numbers of IP extension headers.
6.2. Updating properties of UO-1*
In section 5.7.3, the updating properties of UO-1* are stated:
"Values provided in extensions, except those in other SN, TS,
or IP-ID fields, do not update the context."
However, also sequence number fields of extension headers must be
updated, which means the updating properties should be rephrased as:
"The only values provided in extensions that update the context are
the additional bits for the SN, TS, or IP-ID fields. Other values
provided in extensions do not update the context. Note that
sequence number fields of extension headers are also updated."
Jonsson, et al. [Page 13]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
7. Context management and CID/context re-use
7.1. Compressor and decompressor MUST keep MAX_CID contexts
As part of the negotiated channel parameters, compressor and
decompressor have through the MAX_CID parameter agreed on the highest
context identification (CID) number to be used. By agreeing on
MAX_CID, both compressor and decompressor also agrees to provide
memory resources to host at least MAX_CID+1 contexts, and an
established context with CID within this negotiated space MUST be
kept by both compressor and decompressor until either the CID gets
re-used, or the channel is taken down or re-negotiated.
7.2. CID/context re-use
As part of the channel negotiation, the maximal number of active
contexts supported is negotiated between the compressor and the
decompressor through the MAX_CID parameter. The value of MAX_CID can
of course vary enormously between different link scenarios, as well
as the load in terms of actual packet streams to compress. Depending
on link technology, the ROHC channel lifetime will also vary from
almost permanent to rather short-lived. However, in general it is not
expected that resources will be allocated for more contexts than what
can reasonably be expected to be active concurrently over the link.
As a consequence hereof, context identifiers (CIDs) and context
memory are resources that will have to be re-used by the compressor
as part of what can be considered normal operation.
How context resources are re-used is in RFC 3095 [1] and subsequent
ROHC standards basically left unspecified and up to implementation.
However, re-using a CID and its allocated memory is not always as
simple as initiating a contexts with a previously unused CID. Because
some profiles can be operating in various modes where packet formats
vary depending on current mode, care has to be taken to ensure that
the old context data will be completely and safely overwritten,
eliminating the risk of undesired side effects from interactions
between old and new context data.
On a high level, CID/context re-use can be of two kinds, either re-
use for a new context based on the same profile as the old context,
or for a new context based on a different profile. These cases, are
discussed separately in the following two subsections.
7.2.1. Re-using a CID/context with the same profile
For multi-mode profiles, such as those defined in RFC 3095 [1], when
a CID/context is re-used for a new context based on the same profile
as the old context, the current mode of operation MUST be inherited
from the old to the new context. The reason for this is that there is
no reliable way for the compressor to inform the decompressor that a
CID/context re-use is happening. The decompressor can thus not be
Jonsson, et al. [Page 14]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
expected to flush the context memory for the CID, and there is no way
to trigger a safe mode switching, which requires a decompressor-
initiated handshake procedure, as defined in section 5.6 of [1].
It should be noted that the rule of mode inheritance applies also
when the CONTEXT_REINITIALIZATION signal is used to reinitiate an
entire context.
7.2.2. Re-using a CID/context with a different profile
When a CID is re-used for a new context based on a different profile
than the old context, operation with that context MUST start in the
initial mode of the profile (if it is a multi-mode profile). This
applies both to IR-initiated new contexts and profile downgrades with
IR-DYN (e.g. the IP/UDP/RTP->IP/UDP downgrade in [1] section 5.11.1).
A CID for an R-mode operating context SHOULD NOT be re-used for a new
context based on a different profile than the old context, because of
the R-0/R-1 misinterpretation risk (these packets have no CRC). If a
compressor still wants or has to do this, the compressor must be very
careful to minimize the misinterpretation risk, e.g. by not using
packets of types beginning with 00 or 10 before the compressor is
highly confident that the new context has successfully been initiated
at the decompressor.
7.3. Context updating properties for IR packets
It should be noted that an IR does not flush the whole context, but
updates all fields carried in the IR header. Similarly, an IR without
a dynamic chain simply updates the static part of the context, while
the rest of the context is left unchanged.
Jonsson, et al. [Page 15]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
8. Other protocol clarifications
8.1. Meaning of NBO
In general, an unset flag indicates the normal operation and a set
flag indicates unusual behavior. However, in IPv4 dynamic part
(Section 5.7.7.4), if the 'NBO' bit is set, it means that network
byte order is used.
8.2. IP-ID
According to Section 5.7 IP-ID means the compressed value of the IPv4
header's 'Identification' field. Compressed packets contain this
compressed value (IP-ID), while IR packets with dynamic chain and IR-
DYN packets transmit the original, uncompressed Identification field
value. The IP-ID field always represents the Identification value of
the innermost IPv4 header whose corresponding RND flag is not 1.
If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent
as 16-bit original Identification value(s) at the end of the
compressed base header, according to the IP-ID description (see the
beginning of section 5.7). When there is no compressed IP-ID, i.e.
for IPv6 or when all IP Identification information is sent as-is (as
indicated by RND/RND2 being set to 1), the decompressor ignores IP-ID
bits sent within compressed base headers.
It should be noted that when RND*=0, IP-ID is always compressed, i.e.
expressed as an SN offset and byte-swapped if NBO=0. This is the case
even when 16 bits of IP-ID is sent in extension 3.
When RND=0 but no IP-ID bits are sent in the compressed header, the
SN offset for IP-ID stays unchanged, meaning that Offset_m equals
Offset_ref, as described in Section 4.5.5. This is further expressed
in a slightly different way (with the same meaning) in Section 5.7,
where it is said that "default-slope(IP-ID offset) = 0", meaning that
if no bits are sent for IP-ID, its SN offset slope defaults to 0.
8.3. Extension-3 in UO-1-ID packets
Extension-3 is applied to give values and indicate changes to fields
other than SN, TS and IP-ID in IP header(s) and RTP header. In case
of UO-1-ID packets, it should be noted that values provided in
extensions do not update the context, with an exception for SN, TS
and IP-ID fields, which always update the context (Section 5.7.3.).
It should also be noted that a UO-1-ID packet with Extension 3 must
never be sent with RND flags that changes the packet interpretation,
i.e. that would violate the base condition for UO-1-ID (at least one
RND value must be 0).
Besides, usage of Extension-3 in UO-1-ID can be useful to compress a
transient change in a packet stream. For example, if a field's value
Jonsson, et al. [Page 16]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
changes in the current packet but in the next packet it returns to
its regular behavior. E.g. changes in TTL.
8.4. Extension-3 in UOR-2* packets
If Extension-3 is used in a UOR-2* packet then the information of the
extension updates the context (Section 5.7.4). Some flags of the IP
header in the extension (e.g. NBO or RND) changes the interpretation
of fields in UOR-2* packets. In these cases, when a flag changes in
Extension-3, a decompressor should re-parse the UOR-2* packet.
8.5. Multiple SN options in one feedback packet
The length of the sequence number field in the original ESP header is
32 bits. A decompressor can't send back all the 32 bits in a
feedback packet unless it uses multiple SN options in one feedback
packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet can
contain variable number of feedback options and the options can
appear in any order.
A compressor should be able to process multiple SN options in one
feedback packet.
8.6. Multiple CRC options in one feedback packet
Although it is never required to have more than one single CRC option
in a feedback packet, having multiple CRC options is still allowed.
If multiple CRC options are included, all such CRC options will be
identical, as they will be calculated over the same header.
8.7. Packet decoding during mode transition
Each ROHC profile defines its own set of packet formats, and also its
own feedback packets. The use of various operational modes is also
defined by each specific profile. A decompressor can therefore not
initiate a mode transfer request before at least one packet of a new
context has been correctly decompressed, establishing the context
based on one specific profile (as specified in IR packets). First
then the context has been established, the decompressor knows the
profile used, which modes are defined by that profile, and the
feedback packet formats available.
If the transition procedures in sections 5.6.5 and 5.6.6 of [1] are
followed (and not the enhanced procedures described in section 3 of
this document), it is important to note that type 0 or type 1 packets
may be received by the decompressor during the first half of the
transition procedure, and these packets must not mistakenly be
interpreted as the packets sent by the compressor to indicate
completed transition. The decompressor side must therefore keep track
of the transition status, e.g. with an additional parameter. If the
enhanced transition procedures described in section 3 of this
Jonsson, et al. [Page 17]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
document are used, the D_TRANS parameter can serve this purpose since
its definition and usage is slightly modified.
8.8. How to respond to lost feedback links?
One potential issue that might have to be considered, depending on
link technology, is whether feedback links might get lost, and in
such cases how this is handled. When the compressor is notified that
the feedback channel is down, the compressor must be able to handle
it by restarting compression with creating a new context. Creating a
new context also implies to use a new CID value.
Generally, feedback links are not expected to disappear when once
present, but it should be noted that this might be the case for
certain link technologies.
8.9. What does "presumed zero if absent" mean on page 88?
On page 88, RFC 3095 says that R-P contains the absolute value of RTP
Padding bit and it's presumed zero if absent. It could be absent
from RTP header flags and fields, from the extension type 3 or from
the ROHC packet. It's been agreed that the RTP padding bit is
presumed zero if absent from the RTP header flags.
8.10. UOR-2 in profile 2 (UDP)
One single new format is defined for UOR-2 in profile 2, which
replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile
1. The same UOR-2 format is thus used independent of if there are IP
headers with a corresponding RND=1 or not.
8.11. Sequence number LSB's in IP extension headers
In section 5.8.5, formats are defined for compression of IP extension
header fields. These include compressed sequence number fields, and
it is said that these fields contain "LSB of sequence number". This
means these sequence numbers are not "LSB-encoded" as e.g. the RTP
sequence number with an interpretation interval, but are actually
just the LSB's of the uncompressed fields.
8.12. Expecting UOR-2 ACKs in O-mode
It should be noted that the use of UOR-2 ACKs in O-mode, as discussed
in section 5.4.1.1.2, is indeed optional, and a decompressor can send
ACKs for other purposes than actually acking the UOR-2, without then
having to continue sending them for all UOR-2. Similarly, compressor
implementations can totally ignore UOR-2 ACKs for the purpose of
adapting the optimistic approach strategies. Current implementation
experience also suggests using that approach, and the recommendation
is thus to not make use of the optional ACK mechanism in O-mode,
neither in compressor nor in decompressor implementations.
Jonsson, et al. [Page 18]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
For implementers who still want to make use of the optional O-mode
acks, the following clarifications should be taken into account.
Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in O-mode,
and explains a conceptual algorithm for a compressor to determine
whether such ACKs can be expected from the decompressor, simply using
a condition based on unspecified parameters k_3 and n_3. However,
what is not clearly pointed out is the importance of being very
careful when implementing this confidence algorithm, as using an
incorrect expectation on UOR-2 ACKs as a basis for compressor
behavior will significantly degrade the compression performance. If a
compressor implementation wants to adapt its optimistic approach
behavior on potential UOR-2 ACK usage, the confidence algorithm for
determining UOR-2 ACK usage must be carefully designed, with k_3 and
n_3 having values much larger than 1, as UOR-2 ACKs can be sent from
a decompressor for other purposes than to actually acknowledge the
UOR-2 packet, e.g. to send feedback data such as clock resolution, or
to initiate a mode transfer. Before adapting a compressor to the
potential use of UOR-2 ACKs, the implementer must ensure all aspects
are considered by the confidence algorithm.
8.13. Compression of SN in AH and GRE extension headers
The AH and GRE sequence numbers are compressed exactly as the ESP
sequence number. Specifically, the principle for when to include or
exclude the AH and GRE sequence numbers is the same as for ESP, i.e.
the following rule applies to all these sequence numbers:
Sequence Number: Not sent when the offset from the sequence number
of the compressed header is constant. When the
offset is not constant, the sequence number is
compressed by sending LSBs. See 5.8.4.
Jonsson, et al. [Page 19]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
9. ROHC negotiation clarifications
According to section 4.1, the link layer must provide means to
negotiate e.g. the channel parameters listed in section 5.1.1. One
of these parameters is the PROFILES parameter, which is said to be a
set of non-negative integers where each integer indicates a profile
supported by the decompressor. This can be interpreted as if it is
sufficient to have a mechanism to announce profile support from
decompressor to compressor. However, things are a little bit more
complicated than that.
Each profile is identified by a 16-bit value, where the 8 LSB bits
indicate the actual profile, and the 8 MSB bits indicate the variant
of that profile (see chapter 8). In the ROHC headers sent over the
link, the profile used is identified only with the 8 LSB bits, which
means that the compressor and decompressor must have agreed on which
variant to use for each profile. This can be done in various ways,
but the negotiation protocol must provide means to do it.
In conclusion, the negotiation protocol must be able to communicate
to the compressor the set of profiles supported by the decompressor,
and when multiple variants of the same profile are available, also
provide means for the decompressor to know which variant will be used
by the compressor. This basically means that the PROFILES set after
negotiation must not include more than one variant of the same
profile.
10. PROFILES suboption in ROHC-over-PPP
The logical union of suboptions for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [2], can not be used for the PROFILES
suboption, as the whole union would then have to be considered within
each of the two IPCP negotiations, to avoid getting an ambiguous
profile set. An implementation of RFC 3241 must therefore make sure
the same profile set is negotiated for both IPv4 and IPv6 (IPCP and
IPV6CP).
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles
In the ROHC IP-only profile, section 3.3 of RFC 3843 [3], a mechanism
for encoding of a constant Identification value in IPv4 (constant IP-
ID) is defined. This mechanism is also used by the ROHC UDP-Lite
profiles, RFC 4019 [5].
It should be noted that the "Constant IP-ID" mechanism applies to
both the inner and the outer IP header, when present , meaning that
there will be both a SID and a SID2 context value.
Jonsson, et al. [Page 20]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
12. Test configuration
ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus
every ROHC implementation has an interface that can send and receive
IP packets (i.e. Ethernet). On the other hand, there must be an
interface (a serial link for example) or other means of transport (an
IP/UDP flow), which can transmit ROHC packets. Having these two
interfaces several configurations can be set up. The figure below
shows sample configurations that can be used for testing a ROHC
implementation:
IP/UDP/RTP +------------+ ROHC +--------------+ IP/UDP/RTP
packets | ROHC | packets | ROHC | packets
---------->| Compressor |-----> ----->| Decompressor |---------->
+------------+ +--------------+
Unfortunately, comparing the IP/UDP/RTP packets at the endpoints can
only show whether the reconstructed stream differs from the original
or not. In order to identify the place of the error more detailed
tests are needed. The next figure shows another possible scenario:
IP/UDP/RTP +------------+ ROHC ROHC +--------------+ IP/UDP/RTP
packets | ROHC | packets packets | ROHC | packets
+----->| Compressor |----->+ +----->| Decompressor |----->+
| +------------+ | | +--------------+ |
| | | |
| +------------+ | | +------------+ |
| | Test | | | | Test | |
+<-----| Equipment |<-----+ +<------| Equipment |<------+
+------------+ +------------+
In the first case, the test equipment generates the RTP stream and
also acts as a ROHC decompressor. The tester must recognize if the
original RTP stream was compressed in a bad way and gives an alarm.
In the second case, it is the test equipment that sends the
compressed ROHC packets and the Decompressor reconstructs the RTP
stream. Since the tester knows the ROHC packets and the
reconstructed RTP stream it can detect if the Decompressor makes a
mistake.
13. Security considerations
This document provides a number of clarifications to [1], but it does
not make any changes or additions to the protocol. As a consequence,
the security considerations of [1] apply without additions.
14. IANA considerations
This document does not require any IANA actions.
Jonsson, et al. [Page 21]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
15. Acknowledgment
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann,
Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees,
Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and
Remi Pelland for their contributions and comments.
16. References
16.1. Normative References
[1] C. Bormann, et al., "RObust Header Compression (ROHC) Framework
and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[2] C. Bormann, "Robust Header Compression (ROHC) over PPP",
RFC 3241, April 2002.
[3] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC):
A Compression Profile for IP", RFC 3843, June 2004.
[4] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.
16.2. Informative References
[5] G. Pelletier, "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[6] G. Pelletier, L-E. Jonsson, and K. Sandlund, "ROHC over Channels
that can Reorder Packets", internet-draft (work in progress),
February 2005. <draft-ietf-rohc-over-reordering-02.txt>
17. Authors' Addresses
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com
Peter Kremer
Conformance and Software Test Laboratory
Ericsson Hungary
H-1300 Bp. 3., P.O. Box 107, HUNGARY
Phone: +36 1 437 7033
EMail: peter.kremer@ericsson.com
Jonsson, et al. [Page 22]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
Appendix A - Sample CRC algorithm
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the three types of CRC in use in RFC 3095,
# the robust header compression standard. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
Jonsson, et al. [Page 23]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
}
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies this is complemented like for PPP
# (this differs from 8, 7, and 3-bit CRC)
#
# C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);
Jonsson, et al. [Page 24]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
Appendix B - Potential improvements in updated profiles
B.1. General improvements
B.1.1. Editorial restructuring
Experience has shown that the structure of RFC3095 could had been
much better, and normative specifications could have been less
fragmented. One goal should thus be to do proper restructuring to
make the documentation easier to take in. One fundamental editorial
restructuring is to explicitly define and specify the ROHC framework
in a separate document. The profiles will then be specified in their
own document(s), and will most probably incorporate the updated
profiles from both RFC3095 and the "add-on" specifications ROHC IP-
only and ROHC UDP-Lite into one profile set documentation.
B.1.2. List compression should not be used for IP extension headers
RFC 3095 defines list compression as a generic mechanism ([1],
section 5.8) that is used for both RTP CSRC lists ([1], section
5.8.6) and IP extension headers ([1], section 5.8.4-5.8.5). In the
former case, list compression is indeed very suitable, as the scheme
maps very well to the expected behavior of CSRC items. However, using
list compression for IP extension headers is really hard to justify,
and makes ROHC unnecessary complex. Instead, extension headers should
be treated like all other headers, with static and dynamic chains.
This is the approach taken for ROHC-TCP, and should be applied also
to an updated RFC 3095.
B.1.3. List compression should only use the generic scheme
List compression ([1], section 5.8) defines four different encoding
schemes to be used for compressed lists. There is one generic
encoding scheme, and then three additional optimization schemes based
on reference-based list compression. Implementers have noticed that
using reference-based schemes implies unreasonable decompressor
memory demands and implementation complexity, while the potential
gain is realistically none. The use of the type field in compressed
lists should thus be deprecated and only type 0 encoding should be
allowed.
B.1.4. Multiple operating modes should be avoided, as in ROHC-TCP
RFC 3095 uses several operating modes with complicated transition
procedures to safeguard against incorrect packet interpretation, as
packet formats differ between modes. The multi-mode approach of RFC
3095 has made the specification unnecessary complex, and experience
has shown that this was not a preferable approach. By streamlining
the protocol to one single mode, the number of different packet
formats will be reduced, the compression and decompression control
logic needed will be significantly simplified, mode transition
Jonsson, et al. [Page 25]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
procedures can be eliminated, non-updating packets can be avoided,
etc. When developing the ROHC TCP profile, the ROHC WG has already
concluded that the RFC 3095 mode concept is not to be used again.
Consequently, there are no explicit modes in ROHC-TCP, but only one
consistent logic is used exclusively, both for unidirectional and
bidirectional operation. An updated version of the RFC 3095 profiles
should follow that approach.
B.1.5. UO-1-ID should not be allowed to carry extension 3
UO-1-ID is the only UO-1 format that can carry an extension (see
section 5.7.3 and 5.7.5 of [1]). The updating properties of UO-1 is
also so that when carrying an extension 3, all fields except SN, TS,
and IP-ID are non-updating, which is a fundamental exception to
normal UO operation. The usefulness of partially updating UO packets
is really questionable. This "feature" is also only available for
contexts with a non-random IP-ID, and is thus mainly a useless
inconsistency. In an updated RTP profile, which is the only profile
using this packet type, UO-1-ID should thus not be allowed to carry
extension 3.
B.1.6. No sequential compression for outer IP-ID
The ROHC 3095 profiles define a mechanism for compression of the IP-
ID, not just for the innermost IP header, but also for a potential
outer (second innermost) IP header (see section 5.7 of [1]). It is
however really unrealistic to expect the outer header IP-ID to be
compressible from the sequence number of the RTP header or a
compressor-generated sequence number, while a ROHC-RTP decompressor
must still be implemented to handle such a case if it indeed happens.
This is extremely far-fetched, and the compressor should instead
simply have to identify an outer IP-ID as either random or constant
(for constant IP-ID handling, see section 3.3 of [3]).
B.1.7. ESP NULL-encryption compression should not compress trailer
The ESP NULL-encryption compression mechanism defined for ROHC
compresses not just the header, but also the trailer of the packet.
Apart from being a conceptual exception in the sense that it does not
only compress the header but also tampers with the payload, the
scheme makes assumptions that reduces its applicability, which is
already very limited, to a single corner case. Considering the
relative complexity of implementing it along with the small gain and
limited applicability, this mechanism should be significantly
simplified. The ESP NULL-encryption compression mechanism is defined
in section 5.8.4.3 of [1].
Jonsson, et al. [Page 26]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
B.2. Minor improvements
B.2.1. Meaning of CC=0 for CSRC list presence
Regarding the CC field and CSRC list, the following interpretation
has been proposed as an improvement:
"It should be noted that when the value of this CC field is equal to
zero, there is no Generic CSRC list present in the dynamic chain,
i.e. the field comment should have said "variable length, present if
CC > 0". "
B.2.2. Size of list compression table for RTP CSRC
List compression formats are defined with 3 or 7 bit list item index
identifiers (see section 5.8.6.1 of [1]). As there is no additional
explicit restriction on the maximal number of list items, up to 128
items must be supported, which implies a significant memory demand
for an extreme corner-case. One RTP packet can have up to 15 CSRC
items, and that is probably a well over-provisioned number. Since
items can always be re-assigned, it is therefore suggested to have an
upper limit on the number of CSRC list item index identifiers, with a
max value of either 16 or 32.
B.2.3. The p-value for 5-bit SN
For the RFC 3095 RTP profile, p-values for SN fields are defined in
the beginning of section 5.7 of [3], as follows:
p = 1 if bits(SN) <= 4
p = 2^(bits(SN)-5) - 1 if bits(SN) > 4
This would mean p=1 for bits(SN)=4, p=1 for bits(SN)=6, p>1 for bits
(SN)>6, but for bits(SN)=5, p would then be 0. This is illogical, and
obviously a mistake. One reason it was not noticed might be that the
RTP profile does not have any packet format with 5 bits of SN.
However, the ESP profile refer to the RTP profile for p values
(section 5.12 of [1]), and in the ESP profile there are packet
formats with 5 bits of SN. The p-values should thus be redefined as
follows:
p = 1 if bits(SN) <= 5
p = 2^(bits(SN)-5) - 1 if bits(SN) > 5
It should be noted that the UDP profile has a fixed p-value of -1,
motivated by the use of a compressor-generated SN (section 5.11 of
[1]), and is thus not affected by the incorrectly specified p-value,
although the USP profile has packet formats with 5 bits of SN. Note
however the recommendation in section B.2.4.
Jonsson, et al. [Page 27]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
B.2.4. The UDP profile should have same p-value as other profiles
Since the UDP profile makes use of a compressor-generated SN instead
of an SN taken from an uncompressed header field, it has in section
5.11 of [1] been given a fixed p-value of -1. This made sense, as one
design assumption was in-order delivery from compressor to
decompressor. However, as the interest in using ROHC also over
channels that can not guarantee in-order delivery has gained
momentum, this design choice becomes less appropriate, as described
in [6]. In an updated version of the UDP profile, it should thus be
given the same p-vales as for RTP and ESP, i.e. as outlined in B.2.3,
potentially with an increased' reordering-tolerance, see further
section B.4.
B.2.5. Local repair should be completely optional
In section 5.3.2.2.3-5.3.2.2.5 of [1], possibilities to do local
decompressor repair attempts upon decompression failures are
discussed, and example procedures are described. Section 5.3.2.2.3
says:
A. "First, attempt to determine whether SN LSB wraparound (case 3)
is likely, and if so, attempt a correction. For this, the
algorithm of section 5.3.2.2.4 MAY be used."
and it continues:
B. "Second, if the previous step did not attempt a correction, a
repair should be attempted under the assumption that the
reference SN has been incorrectly updated. For this, the
algorithm of section 5.3.2.2.5 MAY be used."
These are good examples of potential implementation improvements, and
the procedures are described as optional, i.e. with the use of "MAY".
However, both these paragraphs then take one step further and
actually mandates local repair procedures by saying:
C. "If another algorithm is used, it MUST have at least as high a
rate of correct repairs as the one in 5.3.2.2.4 (or 5.3.2.2.5,
respectively).
This should be a local decompressor implementation option, and it is
therefore suggested to exclude the mandating text C.
B.3. Improvements already applied to the IP-only and UPL-Lite profiles
B.3.1. Handling Multiple Levels of IP Headers
The profiles in RFC 3095 can only handle compression of packet
streams with at most two IP headers. The IP-only profile defines a
generic way of handling multiple IP headers (see section 3.2 of [3]).
Jonsson, et al. [Page 28]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
B.3.2. The CONTEXT_MEMORY Feedback Option
To provide means for a decompressor implementation to have an upper
limit on its available context memory size, the IP-only profile
defines an additional feedback option to use (see section 3.7 of
[3]). The CONTEXT_MEMORY option informs the compressor that the
decompressor does not have sufficient memory resources to handle the
context of the packet stream, as the stream is currently compressed.
B.3.3. Compression of constant IP-ID (IPv4 only)
Most IPv4 stacks assign an IP-ID according to the value of a counter,
increasing by one for each outgoing packet. ROHC-RTP therefore
compresses the IP-ID field using offset IP-ID encoding based on the
RTP SN. For stacks generating IP-ID values using a pseudo-random
number generator, the field is not compressed and is sent as-is in
its entirety as additional octets after the compressed header.
Cases have also been found where an IPv4 stack uses a constant value
for the IP Identifier. When the IP-ID field is constant, it cannot
be compressed using offset IP-ID encoding and the field must be sent
in its entirety, although it is completely static and could had been
completely omitted in compressed headers. The IP-only profile
addresses this problem and defines an additional mechanism to cope
efficiently with constant IP-ID (see section 3.3 of [3]).
B.4. Adding tolerance to reordering between compressor and decompressor
RFC 3095 was written based on the assumption of in-order packet
delivery between compressor and decompressor. Since the publication
of RFC 3095, is has been clear that using ROHC would be desirable
also in environments where in-order delivery can not be guaranteed.
The challenges associated with such usage have been analyzed in an
informational ROHC WG document "ROHC over channels that can reorder
packets" [6], and the finding of that document should be used as a
basis when developing an enhanced ROHC that can tolerate a certain
amount of reordering, possibly a configurable reordering tolerance.
B.5. Implementation stuff that should go out of the spec.
There is a significant amount of implementation ideas given in
chapter 6 of, both potential implementation enhancement,
implementation API parameters, as well as data structures. It is
sometimes useful to have such material being provided in an appendix,
as it can help implementers. However, in this case it has been clear
that in the way these things were included in RFC 3095, more concerns
than benefits were created. There are several reasons for this, one
is that these parts were not included as an appendix, but actually
part of the specification itself. Also, the size and overall
Jonsson, et al. [Page 29]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
structure of the whole RFC can easily make an implementer confused
about what is actually part of the standard.
In general, it is thus suggested that an update of RFC 3095 should
have larger implementation example material, if any, in an appendix
to make it clearer that it is not part of the actual standard.
Further, reducing the amount of material would be desirable, to make
the whole documentation more concise.
What to do with the various subsections of chapter 6 is discussed
below, along with other informational parts or concepts that can be
questioned.
B.5.1. Reverse decompression
Reverse decompression is described in section 6.1. This is a very
questionable implementation enhancement, and should preferably be
removed, or at least be put in an appendix.
B.5.2. Implementation parameters and signals
In section 6.3, various potential API parameters are defined,
although only informatively, as they are not at all necessary from a
ROHC protocol point of view. Unfortunately, the way this section is
written might make implementer's believe this is actually part of the
standard, as it even makes use of RFC 2119 keywords.
This section should thus be revised, simplified, and it should be
made clear that it is an API parameter proposal, nothing more,
nothing less. The result could potentially be put in an appendix of
the profiles specification.
B.5.3. Decompressor resource limitations
Section 6.4 of discusses how to handle resource limitations at the
decompressor. This is typical implementation guidelines that fits
very well in an "implementation issues" section, and should thus be
kept. Note that the addition of the CONTEXT_MEMORY feedback option
(see B.3.2) affects this discussion, which would have to be updated
accordingly.
B.5.4. Implementation structures
Section 6.5 provides some explanatory material on data structures
that a ROHC implementation will have to maintain in one form or
another. The section explicitly states the explanatory nature of it,
and points out that it is not intended to constrain implementations.
However, it is far from clear whether this material is actually
useful. It should therefore be revised, potentially removed, or at
least put in an appendix.
Jonsson, et al. [Page 30]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
B.5.5. The state concept
The concept of states (FO/SO), as used in a normative manner
throughout RFC 3095, should be removed from the spec or at least
rewritten so that it becomes clear that this is a descriptive concept
and not at all normative. Mentioning of implementation parameters,
such as k_2/n_2 and k_3/n_3 should be dropped, or it should at least
be made clear that these are just example parameters in example
algorithms. Probably the entire state concept can be dropped, since
it really describes implementation choices. It can be used
informatively, but that should then be made clear.
Jonsson, et al. [Page 31]
INTERNET-DRAFT ROHC Implementer's Guide July 18, 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires January 18, 2006.
Jonsson, et al. [Page 32]