draft-ietf-rohc-rtp-impl-guide-18.txt   draft-ietf-rohc-rtp-impl-guide-19.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT K. Sandlund INTERNET-DRAFT K. Sandlund
Expires: August 2006 G. Pelletier TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362 G. Pelletier
P. Kremer Expires: November 2006 P. Kremer
Ericsson Ericsson
February 1, 2006 May 22, 2006
The RFC 3095 Implementer's Guide RObust Header Compression (ROHC):
<draft-ietf-rohc-rtp-impl-guide-18.txt> Corrections and Clarifications to RFC 3095
<draft-ietf-rohc-rtp-impl-guide-19.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, each author accepts the provisions By submitting this Internet-Draft, each author accepts the provisions
of Section 3 of BCP 78. of Section 3 of BCP 78.
skipping to change at page 1, line 44 skipping to change at page 1, line 45
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org. directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
RFC 3095 defines the RObust Header Compression (ROHC) framework and RFC 3095 defines the RObust Header Compression (ROHC) framework and
profiles for IP, UDP, RTP, and ESP. This document clarifies profiles for IP, UDP, RTP, and ESP. Some parts of the specification
ambiguities and common misinterpretations of RFC 3095, and it also are unclear or contain errors that may lead to misinterpretations
corrects some actual errors in the specification. The corrections and that may impair interoperability between different implementations.
clarifications provided herein must be followed to get interoperable This document provides corrections, additions and clarifications to
implementations, i.e. this document updates RFC 3095. Further, minor RFC 3095; this document thus updates RFC 3095. In addition, other
interpretation details of RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP
profile) and RFC 4109 (ROHC UPD-Lite profiles) are also addressed. profile) and RFC 4109 (ROHC UPD-Lite profiles) are also provided.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction and terminology.....................................3
2. CRC calculation and coverage issues..............................3 2. CRC calculation and coverage.....................................4
2.1. CRC calculation.............................................3 2.1. CRC calculation.............................................4
2.2. Padding octet in CRC........................................4 2.2. Padding octet and CRC calculations..........................4
2.3. CRC coverage in CRC feedback options........................4 2.3. CRC coverage in CRC feedback options........................4
2.4. CRC coverage of the ESP NULL header.........................4 2.4. CRC coverage of the ESP NULL header.........................5
3. Enhanced mode transition procedures..............................4 3. Mode transition..................................................5
3.1. Modified transition logic for enhanced transitions..........5 3.1. Feedback during mode transition to U- and O-mode............5
3.2. Transition from Reliable to Optimistic mode.................6 3.1.1. Mode transition procedures allowing sparse feedback....5
3.3. Transition to Unidirectional mode...........................6 3.1.2. Transition from Reliable to Optimistic mode............6
4. Timestamp encoding considerations................................7 3.1.3. Transition to Unidirectional mode......................7
4.1. Encoding used for compressed TS bits........................7 3.2. Feedback during mode transition.............................7
4.2. (De)compression of TS without transmitted TS bits...........7 3.3. Packet decoding during mode transition......................8
4.3. Interpretation intervals for TS encoding....................8 4. Timestamp encoding...............................................8
4.4. TS_STRIDE for scaled timestamp encoding.....................8 4.1. Encoding used for compressed TS bits........................8
4.5. TS wraparound with scaled timestamp encoding................9 4.2. (De)compression of TS without transmitted TS bits...........9
4.6. Recalculating TS_OFFSET.....................................9 4.3. Interpretation intervals for TS encoding...................10
4.7. TS_STRIDE and the Tsc flag in Extension 3..................10 4.4. TS_STRIDE for scaled timestamp encoding....................10
4.8. Using timer-based compression..............................10 4.5. TS wraparound with scaled timestamp encoding...............11
5. List compression issues.........................................10 4.6. Recalculating TS_OFFSET....................................12
5.1. Generic extension header list..............................10 4.7. TS_STRIDE and the Tsc flag in Extension 3..................12
5.2. CSRC list items in RTP dynamic chain.......................11 4.8. Using timer-based compression..............................13
5.3. RTP dynamic chain..........................................11 5. List compression................................................13
5.4. Compressed lists in UO-1-ID packets........................11 5.1. CSRC list items in RTP dynamic chain.......................13
5.5. Bit masks in list compression..............................11 5.2. Multiple occurrences of the CC field.......................14
5.6. Headers compressed with list compression...................12 5.3. Bit masks in list compression..............................14
5.7. ESP NULL header list compression...........................12 5.4. Headers compressed with list compression...................14
5.8. Translation tables and indexes for IP extension headers....12 5.5. ESP NULL header list compression...........................15
5.9. Reference list.............................................12 5.6. Translation tables and indexes for IP extension headers....15
6. Updating properties.............................................13 5.7. Reference list.............................................15
6.1. Implicit updates...........................................13 5.8. Compression of AH and GRE sequence numbers.................16
6.2. Updating properties of UO-1*...............................13 6. Updating properties.............................................17
7. Context management and CID/context re-use.......................14 6.1. Implicit updates...........................................17
7.1. The decompressor MUST keep MAX_CID contexts................14 6.2. Updating properties of UO-1*...............................17
7.2. CID/context re-use.........................................14 6.3. Context updating properties for IR packets.................18
7.2.1. Re-using a CID/context with the same profile..........14 6.4. RTP padding field (R-P) in extension 3.....................18
7.2.2. Re-using a CID/context with a different profile.......15 6.5. RTP eXtension bit (X) in dynamic part......................18
7.3. Context updating properties for IR packets.................15 7. Context management and CID/context re-use.......................19
8. Other protocol clarifications...................................15 7.1. Persistence of decompressor contexts.......................19
8.1. Meaning of NBO.............................................15 7.2. CID/context re-use.........................................19
8.2. IP-ID......................................................15 7.2.1. Re-using a CID/context with the same profile..........20
8.3. Extension-3 in UO-1-ID packets.............................16 7.2.2. Re-using a CID/context with a different profile.......20
8.4. Extension-3 in UOR-2* packets..............................16 8. Other protocol clarifications...................................21
8.5. Multiple SN options in one feedback packet.................16 8.1. Meaning of NBO.............................................21
8.6. Multiple CRC options in one feedback packet................17 8.2. IP-ID......................................................21
8.7. Packet decoding during mode transition.....................17 8.3. Extension-3 in UOR-2* packets..............................21
8.8. How to respond to lost feedback links?.....................17 8.4. Multiple occurrences of the M bit..........................21
8.9. What does "presumed zero if absent" mean on page 88?.......18 8.5. Multiple SN options in one feedback packet.................22
8.10. UOR-2 in profile 2 (UDP) and profile 3 (ESP)..............18 8.6. Multiple CRC options in one feedback packet................22
8.11. Sequence number LSB's in IP extension headers.............18 8.7. Responding to lost feedback links..........................22
8.12. Expecting UOR-2 ACKs in O-mode............................18 8.8. UOR-2 in profile 0x0002 (UDP) and profile 0x0003 (ESP).....23
8.13. Compression of SN in AH and GRE extension headers.........19 8.9. Sequence number LSB's in IP extension headers..............23
9. ROHC negotiation clarifications.................................19 8.10. Expecting UOR-2 ACKs in O-mode............................23
10. PROFILES suboption in ROHC-over-PPP............................20 9. ROHC negotiation................................................23
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......20 10. PROFILES suboption in ROHC-over-PPP............................24
12. Security considerations........................................20 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......24
13. IANA considerations............................................20 12. Security considerations........................................24
14. Acknowledgment.................................................20 13. IANA considerations............................................24
15. References.....................................................21 14. Acknowledgment.................................................24
15.1. Normative References......................................21 15. References.....................................................25
15.2. Informative References....................................21 15.1. Normative References......................................25
16. Authors' Addresses.............................................21 15.2. Informative References....................................25
Appendix A - Sample CRC algorithm..................................22 16. Authors' Addresses.............................................26
Appendix A - Sample CRC algorithm..................................27
1. Introduction 1. Introduction and terminology
RFC 3095 [1] defines the RObust Header Compression (ROHC) framework RFC 3095 [1] defines the RObust Header Compression (ROHC) framework
and profiles for IP, UDP, RTP, and ESP. During implementation and and profiles for IP, UDP, RTP, and ESP. During implementation and
interoperability testing of RFC 3095 some ambiguities and common interoperability testing of RFC 3095 some ambiguities and common
misinterpretations have been identified, as well as a few actual misinterpretations have been identified, as well as a few errors.
errors.
This document has been created to summarize all identified issues, This document summarizes identified issues and provides corrections
and provide the clarifications and corrections needed to make needed for implementations of RFC 3095 to interoperate, i.e. it
creation of interoperable implementations possible. It should thus be constitutes an update to RFC 3095. This document also provides other
noted that it is essential that implementers of RFC 3095 follow the clarifications related to common misinterpretations of the
corrections and clarifications provided herein, i.e. this document specification. When referring to RFC 3095, this document should
constitute an update to RFC 3095. When referring to RFC 3095, this therefore also be referenced.
document should therefore also be referenced.
A few minor interpretation details of RFC 3241 [2] (ROHC over PPP), In addition, some clarifications and corrections are also provided
RFC 3843 [3] (ROHC IP-only profile), and RFC 4019 [5] (ROHC UDP-Lite for RFC 3241 [2] (ROHC over PPP), RFC 3843 [4] (ROHC IP-only
profiles) are also addressed in this document (chapter 10-11). profile), and RFC 4019 [5] (ROHC UDP-Lite profiles), which are thus
also updated by this document. Furthermore, RFC 4362 [7] (ROHC Link-
Layer Assisted Profile) is implicitly updated by this document, since
also RFC 4362 is based on RFC 3095.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [6].
Note that all section and chapter references in this document refer When a section of this document makes formal corrections, additions
to [1], where not stated otherwise. or invalidations to text in RFC 3095, this is clearly summarized. The
text from RFC 3095 that is being addressed is given and labeled
"INCOMPLETE", "INCORRECT" or "INCORRECT AND INVALIDATED", followed by
the correct text labeled "CORRECTED", where applicable. When a formal
addition is provided, it is given with the label "FORMAL ADDITION".
2. CRC calculation and coverage issues In this document, a reference to a section or a chapter that is made
without an explicit mention of a specific document refers to a
section or a chapter in RFC 3095 [1], unless stated otherwise.
2. CRC calculation and coverage
2.1. CRC calculation 2.1. CRC calculation
ROHC uses CRC checksum in order to provide some protection against Section 5.9 defines polynomials for 3, 7 and 8-bit CRCs, but it does
bit errors. CRC is used in the segmentation protocol and in the not specify what algorithm is used. The 3, 7 and 8-bit CRCs are
compressed packets, as well. calculated using the CRC algorithm defined in [3].
Section 5.2.5.2 describes the segmentation protocol and refers to A PERL implementation of the algorithm can be found in Appendix A of
[3], which describes a well-defined CRC algorithm for 32 bit this document.
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) 2.2. Padding octet and CRC calculations
can be found in Appendix A of this document.
2.2. Padding octet in CRC Section 5.9.1 is incomplete, as it does not mention how to handle the
padding octet in CRC calculations for IR and IR-DYN packets. Padding
isn't meant to be a meaningful part of a packet and is not included
in the CRC calculation. As a result, the CRC does not cover the Add-
CID octet for CID 0, either.
According to Section 5.9.1, in case of IR and IR-DYN packets the CRC INCOMPLETE RFC 3095 TEXT (section 5.9.1):
"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 "The CRC in the IR and IR-DYN packet is calculated over the entire
meaningful part of a packet and MUST NOT be included in the CRC IR or IR-DYN packet, excluding Payload and including CID or any
calculation. As a result, the CRC MUST NOT cover the Add-CID octet Add-CID octet."
for CID 0, either.
CORRECTED TEXT:
"The CRC in the IR and IR-DYN packet is calculated over the entire
IR or IR-DYN packet, excluding Payload, Padding and including CID
or any Add-CID octet, except for the add-CID octet for CID 0."
2.3. CRC coverage in CRC feedback options 2.3. CRC coverage in CRC feedback options
Section 5.7.6.3 states "The CRC option contains an 8-bit CRC computed Section 5.7.6.3 is incomplete, as it does not mention how the "size"
over the entire feedback payload, without the packet type and code field is handled when calculating the 8-bit CRC used in the CRC
octet, but including any CID fields, using the polynomial of section feedback option. Since the "size" field can be considered an
5.9.1". However, it does not mention how the "size" field is handled, extension of the "code" field, it must be treated as the "code"
if present. Since the "size" field can be considered an extension of field.
the "code" field, it must be treated as the "code" field, i.e. the
"size" field MUST NOT be covered by the CRC. INCOMPLETE RFC 3095 TEXT (section 5.7.6.3):
"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."
CORRECTED TEXT:
"The CRC option contains an 8-bit CRC computed over the entire
feedback payload including any CID fields but excluding the
packet type, the 'Size' field and the 'Code' octet, using the
polynomial of section 5.9.1."
2.4. CRC coverage of the ESP NULL header 2.4. CRC coverage of the ESP NULL header
Section 5.8.7 gives the CRC coverage of the ESP NULL header as Section 5.8.7 gives the CRC coverage of the ESP NULL header as
"Entire ESP header". This must be interpreted as including only the "Entire ESP header". This must be interpreted as including only the
initial part of the header (i.e. SPI and Sequence number), and not 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 the trailer part at the end of the payload. Therefore, the ESP NULL
header MUST have the same CRC coverage as the ESP header used in the header has the same CRC coverage as the ESP header used in the ESP
ESP profile (section 5.7.7.7). profile (section 5.7.7.7).
3. Enhanced mode transition procedures 3. Mode transition
3.1. Feedback during mode transition to U- and O-mode
Section 5.6.1 states that during mode transitions, while the D_TRANS
parameter is I, the decompressor send feedback for each received
packet. This restrictive behavior prevents a decompressor from using
a sparse feedback algorithm during mode transitions.
To reduce transmission overhead and computational complexity To reduce transmission overhead and computational complexity
(including CRC calculation) associated with feedback packets sent for (including CRC calculation) associated with feedback packets sent for
each decompressed packet during mode transition, a decompressor MAY each decompressed packet during mode transition, a decompressor MAY
be implemented with slightly modified mode transition procedures, be implemented with slightly modified mode transition procedures
compared to those defined in [1]. compared to those defined in [1], as described in this section.
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, 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 These enhanced procedures should be considered only as a possible
improved decompressor implementation, since interoperability is not improvement to a decompressor implementation, since interoperability
at all affected. A decompressor implemented according to the is not affected in any way. A decompressor implemented according to
optimized procedures would be able to interoperate with an RFC3095 the optimized procedures will interoperate with an RFC3095
compressor, as well as a decompressor implemented according to the compressor, as well as a decompressor implemented according to the
procedures described in RFC3095 would do. procedures described in RFC3095 does.
3.1. Modified transition logic for enhanced transitions 3.1.1. Mode transition procedures allowing sparse feedback
The intent with these enhanced transition procedures is to allow the The purpose of these enhanced transition procedures is to allow the
decompressor to stop sending feedback packets for all packets decompressor to sparsely send feedback for packets decompressed
decompressed during the second half of the transition procedure, i.e. during the second half of the transition procedure, i.e. after an
after an appropriate IR/IR-DYN/UOR-2 packet has been received from appropriate IR/IR-DYN/UOR-2 packet has been received from the
the compressor. In the transition diagrams, sections 3.2 and 3.3 compressor. This is achieved by allowing the decompressor transition
below, this is realized by allowing the decompressor transition parameter (D_TRANS) to be set to P (Pending) at that stage, as shown
parameter (D_TRANS) to be set to P (Pending) at that stage. However, in the transition diagrams of sections 3.1.2 and 3.1.3 below.
as mentioned above, there are robustness concerns related to this
optimization, and to avoid deadlock situations with never completed This enhanced transition, where feedback need not be sent for every
transitions as a result of feedback losses, the decompressor MUST decompressed packet, does however introduce some considerations in
continue to send feedback at least periodically, also when in Pending case feedback messages would be lost. Specifically, there is a risk
transition state. That would be the equivalence of enhancing the for a deadlock situation when a transition from R-mode is performed
D_TRANS parameter definition in section 5.6.1, to include a in case no feedback message successfully reaches the compressor and
definition of Pending state operation. the transition is not complete. For transition between U-mode and O-
mode, there is also a small risk for reduced compression efficiency.
To avoid this, the decompressor MUST continue to send feedback at
least periodically, also when in Pending transition state. This is
equivalent to enhancing the definition of the D_TRANS parameter in
section 5.6.1, to include the definition of a Pending state:
- D_TRANS: - D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED, 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 (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 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 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 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 decompressor do not have to send a NACK or ACK for each packet
received, but it MUST continue to send feedback on a regular received, but it MUST continue to send feedback with some
basis, and all feedback packets sent MUST include the CRC option. periodicity, and all feedback packets sent MUST include the CRC
This ensures that all mode transitions will be completed also in option. This ensures that all mode transitions will be completed
case of feedback losses. also in case of feedback losses.
3.2. Transition from Reliable to Optimistic mode 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, and make those transition diagrams more
consistent with the diagram describing the transition to R-mode.
3.1.2. Transition from Reliable to Optimistic mode
The enhanced procedure for transition from Reliable to Optimistic The enhanced procedure for transition from Reliable to Optimistic
mode is shown below: mode is shown below:
Compressor Decompressor Compressor Decompressor
---------------------------------------------- ----------------------------------------------
| | | |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I | ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ | C_TRANS = P |-<-<-<-+ |
skipping to change at page 6, line 30 skipping to change at page 7, line 5
|->-.. | D_MODE = O |->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-| | ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ | C_TRANS = D |-<-<-<-+ |
| | | |
|->->->-+ UO-0, UO-1* | |->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ | | +->->->->->->->-+ |
| +->->->-| D_TRANS = D | +->->->-| D_TRANS = D
| | | |
3.3. Transition to Unidirectional mode 3.1.3. Transition to Unidirectional mode
The enhanced procedure for transition to Unidirectional mode is shown The enhanced procedure for transition to Unidirectional mode is shown
on the following figure: on the following figure:
Compressor Decompressor Compressor Decompressor
---------------------------------------------- ----------------------------------------------
| | | |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I | ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ | C_TRANS = P |-<-<-<-+ |
skipping to change at page 7, line 5 skipping to change at page 7, line 30
|->-.. | |->-.. |
| ACK(SN,U) +-<-<-<-| | ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ | C_TRANS = D |-<-<-<-+ |
| | | |
|->->->-+ UO-0, UO-1* | |->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ | | +->->->->->->->-+ |
| +->->->-| D_TRANS = D | +->->->-| D_TRANS = D
| | D_MODE= U | | D_MODE= U
4. Timestamp encoding considerations 3.2. Feedback during mode transition
Section 5.6.1 states that feedback is always used during mode
transitions. However, the text then continues by making concrete
applications of the rule in an inconsistent way, making it unclear
when CRC's are used. Further, the text does not define how the
compressor should act during mode transitions based on feedback not
protected by CRCs, i.e. whether to carry out mode transition actions
or not. The proper behavior from the compressor is to perform any
action related to mode transitions only when the feedback is
protected by the CRC option.
INCOMPLETE RFC 3095 TEXT (section 5.6.1):
"As a safeguard against residual errors, all feedback sent during
a mode transition MUST be protected by a CRC, i.e., the CRC
option MUST be used."
CORRECTED TEXT:
"As a safeguard against residual errors, all feedback sent by the
decompressor during a mode transition MUST be protected by a CRC,
i.e., the CRC option MUST be used. The compressor MUST ignore
feedback information related to mode transition if the feedback
is not protected by the CRC option."
One more related issue that requires clarifications comes from the
following text at the end of section 5.6.1:
"While D_TRANS is I, the decompressor sends a NACK or ACK carrying
a CRC option for each received packet."
However, Section 5.5.2.2 already stated that for R-mode, feedback is
never sent for packets that do not update the context, i.e. for
packets that do not carry a CRC such as R-0 and R-1* packets.
This means that when D_TRANS=I during mode transition, a decompressor
operating in R-mode sends an acknowledgement for each packet it
receives and MUST use the sequence number that corresponds to the
packet that last updated the context, i.e. the decompressor MUST NOT
use the sequence number of the R-0 or the R-1* packet."
3.3. 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 transition 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). The
context must be established before the decompressor can know the
profile used, which modes are defined by that profile, and the
feedback packet formats available. Mode transition can therefore not
be initiated by the decompressor before it has an established context
for the CID.
If the original transition procedures in sections 5.6.5 and 5.6.6 are
followed (and not the enhanced procedures described in section 3.1 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 be mistakenly
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
document are used, the D_TRANS parameter can serve this purpose since
its definition and usage is slightly modified.
4. Timestamp encoding
4.1. Encoding used for compressed TS bits 4.1. Encoding used for compressed TS bits
RTP Timestamp values (TS) are always encoded using W-LSB encoding, RTP Timestamp values (TS) are always encoded using W-LSB encoding,
both when sent scaled and when sent unscaled. For TS values sent in 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 Extension 3, W-LSB encoded values are sent using the self-describing
variable-length format (section 4.5.6), and this applies to both variable-length format (section 4.5.6), and this applies to both
scaled and unscaled values. scaled and unscaled values.
4.2. (De)compression of TS without transmitted TS bits 4.2. (De)compression of TS without transmitted TS bits
RFC 3095 explains that SO-state provides the most efficient When ROHC RTP operate using its most efficient packet types, apart
compression within ROHC RTP. In this state, apart from packet type from packet type identification and the error detection CRC, only RTP
identification and the error detection CRC, only RTP sequence number sequence number (SN) bits have to be transmitted in RTP compressed
(SN) bits have to be transmitted in RTP compressed headers. All other headers. All other fields are then omitted either because they are
fields are then omitted either because they are unchanged or because unchanged or because they can be reconstructed through a function
they can be reconstructed through a function from the SN (i.e. by from the SN (i.e. by combining the transmitted SN bits with state
combining the transmitted SN bits with state information from the information from the context). Fields that can be inferred from the
context). Although it is never spelled out explicitly what fields are SN are the IP Identification (IP-ID) and the RTP Timestamp (TS).
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 IP-ID compression and decompression, both with and without
transmitted IP-ID bits in the compressed header, are well defined in 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 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 is only defined how to decompress based on actual TS bits in the
compressed header, either scaled or unscaled, but not how to infer 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 the TS from the SN, i.e. in SO-state operation. This section
idea is simple, the actual operation must be clearly defined to specifies how the TS (scaled or unscaled) is decompressed when no TS
ensure interoperability. There are also inconsistent text pieces that bits are transmitted in the compressed header.
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 When no TS bits are transmitted in the compressed header, the encoded
TS value (scaled or unscaled) is to be decompressed assuming a linear TS value (scaled or unscaled) is decompressed assuming a linear
extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope. extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope,
where delta_SN and delta_TS are both signed integers. Section 5.7
defines the potential values for default-slope.
Section 5.7 defines the potential values for default-slope as: INCOMPLETE RFC 3095 TEXT (section 5.7):
"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)."
CORRECTED TEXT:
"When a compressed header with no TS bits is received, the encoded
TS value (scaled or unscaled) is decompressed assuming a linear
extrapolation from the SN, i.e. delta_TS = delta_SN * default-
slope.
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see section 4.5.3), and default-slope(TS) = 1. compression (see section 4.5.3), and default-slope(TS) = 1.
If value(Tsc) = 0, the Timestamp value is compressed as-is, and If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE). default-slope(TS) = value(TS_STRIDE)."
What must be noted here is that no slope value is used other than the INCORRECT AND INVALIDATED RFC 3095 TEXT (section 5.5.1.2):
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 "For example, in a typical case where the string pattern has the
the slope can have different values and be "learned", which is form of non-SN-field = SN * slope + offset, one ACK is enough if
incorrect. The default-slope from 5.7 is always the value used when the slope has been previously established by the decompressor
decompressing TS based on SN. (i.e., only the new offset needs to be synchronized). Otherwise,
two ACKs are required since the decompressor needs two headers to
learn both the new slope and the new offset."
Consequently, there is no other slope value than the default-slope,
as defined in section 5.7.
4.3. Interpretation intervals for TS encoding 4.3. Interpretation intervals for TS encoding
Section 4.5.4 defines the interpretation interval, p, for timer-based Section 4.5.4 defines the interpretation interval, p, for timer-based
compression of the RTP timestamp. However, Section 5.7 defines a compression of the RTP timestamp. However, Section 5.7 defines a
different interpretation interval, which is defined as the different interpretation interval, which is defined as the
interpretation interval to use for all TS values. It is thus unclear interpretation interval to use for all TS values. It is thus unclear
which p-value to use, at least for timer-based compression. which p-value to use, at least for timer-based compression.
The way this should be interpreted is that the p-value differs The way this should be interpreted is that the p-value differs
depending on whether timer-based compression is enabled or not. For depending on whether timer-based compression is enabled or not.
timer-based compression, the interpretation interval of section
4.5.4, p = 2^(k-1) - 1, MUST be used for TS. Otherwise, the interval
of section 5.7, p = 2^(k-2) - 1, MUST be used, i.e. for TS with
regular W-LSB encoding.
Since two different p-values are used, the compressor must take this For timer-based compression (TIME_STRIDE set to a non-zero value),
into account during the process of enabling timer-based compression. the interpretation interval is:
Before timer-based compression can be used, the decompressor will p = 2^(k-1) - 1 (as per section 4.5.4)
have to inform the compressor (on a per-channel basis) about its Otherwise, the interpretation interval is:
clock resolution. Further, the compressor has to send (on a per- p = 2^(k-2) - 1 (as per section 5.7)
context basis) a non-zero TIME_STRIDE to the decompressor.
When the compressor is confident that the decompressor has received Since two different p-values are used, the compressor must take this
the TIME_STRIDE value, it can switch to timer-based compression. into account throughout the process of enabling timer-based
During this transition from window-based compression to timer-based compression (see section 4.8 of this document). During transition
compression, it is necessary that the compressor keep k large enough from window-based compression to timer-based compression, it is thus
to cover both interpretation intervals. necessary that the compressor keep k large enough to cover both
interpretation intervals.
4.4. TS_STRIDE for scaled timestamp encoding 4.4. TS_STRIDE for scaled timestamp encoding
The timestamp stride (TS_STRIDE) is defined as the expected increase RFC 3095 defines the timestamp stride (TS_STRIDE) as the expected
in the timestamp value between two RTP packets with consecutive increase in the timestamp value between two RTP packets with
sequence numbers. TS_STRIDE is set by the compressor and explicitly consecutive sequence numbers. TS_STRIDE is set by the compressor and
communicated to the decompressor, and it is used either as the explicitly communicated to the decompressor, and it is used either as
scaling factor for scaled TS encoding, or constitutes the default- the scaling factor for scaled TS encoding, or constitutes the
slope used when decompressing an unscaled TS through a linear default-slope used when decompressing an unscaled TS through a linear
extrapolation from the SN (see also section 4.2 above). extrapolation from the SN (see also section 4.2 of this document).
The relation between TS and TS_SCALED, given by the following The relation between TS and TS_SCALED, given by the following
equality in section 4.5.3, defines the mathematical meaning of equality in section 4.5.3, defines the mathematical meaning of
TS_STRIDE: TS_STRIDE:
TS = TS_SCALED * TS_STRIDE + TS_OFFSET TS = TS_SCALED * TS_STRIDE + TS_OFFSET
In the compression step explained following this core equality of
section 4.5.3, TS_SCALED is incorrectly written as TS / TS_STRIDE. TS_SCALED is incorrectly written as TS / TS_STRIDE in the compression
This formula is incorrect both because it excludes TS_OFFSET, and step following the above core equality. This formula is incorrect
because it would prevent a TS_STRIDE value of 0. If "/" were a both because it excludes TS_OFFSET and because it would prevent a
generally unambiguously defined operation meaning "the integral part TS_STRIDE value of 0, which is an alternative not excluded by the
of the result from dividing X by Y", the absence of TS_OFFSET could core equality above. If "/" were a generally unambiguously defined
be explained, but the formula still lacks a proper output for operation meaning "the integral part of the result from dividing X by
TS_STRIDE equal to 0. As the core equality above does not prevent Y", the absence of TS_OFFSET could be explained, but the formula
setting TS_STRIDE to 0, and there is no reason not to allow a would still lack a proper output for TS_STRIDE equal to 0. The
compressor to do that, the formula of "2. Compression" should not be formula of "2. Compression" is thus invalid.
read as having any formal meaning.
INCORRECT RFC 3095 TEXT (section 4.5.3):
"2. Compression: After initialization, the compressor no longer
compresses the original TS values. Instead, it compresses the
downscaled values: TS_SCALED = TS / TS_STRIDE. The
compression method could be either W-LSB encoding or the
timer-based encoding described in the next section."
CORRECTED TEXT:
"2. Compression: After initialization, the compressor no longer
compresses the original TS values. Instead, it compresses the
downscaled values. The compression method could be either
W-LSB encoding or the timer-based encoding described in the
next section."
4.5. TS wraparound with scaled timestamp encoding 4.5. TS wraparound with scaled timestamp encoding
In the scaled timestamp encoding section, 4.5.3, it is said in point Section 4.5.3 states in point 4 and 5 that the compressor is not
4 and 5 that the compressor is not required to initialize TS_OFFSET required to initialize TS_OFFSET at wraparound, but that it is
at wraparound, but that it is required to increase the number of bits required to increase the number of bits sent for the scaled TS value
sent for the scaled TS value when there is a TS wraparound. The when there is a TS wraparound. The decompressor is also required to
decompressor is also required to detect and cope with TS wraparound, detect and cope with TS wraparound, including updating TS_OFFSET.
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, This method is not interoperable and not robust. The gain is also
and instead the compressor SHOULD reinitialize TS_OFFSET upon TS insignificant, as TS wraparound happens very seldom. Therefore, the
wraparound, by sending unscaled TS. This is equivalent of replacing compressor reinitializes TS_OFFSET upon TS wraparound, by sending
point 4-5 with: unscaled TS.
4. Offset at wraparound: If the value of TS_STRIDE is not equal INCORRECT RFC 3095 TEXT (section 4.5.3):
"4. Offset at wraparound: Wraparound of the unscaled 32-bit TS
will invalidate the current value of TS_OFFSET used in the
equation above. For example, let us assume TS_STRIDE = 160 =
0xA0 and the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50
= 80. Then if the next RTP TS = 0x00000130 (i.e., the
increment is 160 * 2 = 320), the new TS_OFFSET should be
0x00000130 modulo 0xA0 = 0x90 = 144. The compressor is not
required to re-initialize TS_OFFSET at wraparound. Instead,
the decompressor MUST detect wraparound of the unscaled TS
(which is trivial) and update TS_OFFSET to
TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE
CORRECTED TEXT:
"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 to a power of two, wraparound of the unscaled 32-bit TS will
change the value of TS_OFFSET. When this happens, the change the value of TS_OFFSET. When this happens, the
compressor SHOULD reinitialize TS_OFFSET by sending unscaled compressor SHOULD reinitialize TS_OFFSET by sending unscaled
TS, as in 1 above. TS, as in 1 above."
It should be noted that by following this recommendation for the INCORRECT AND INVALIDATED RFC 3095 TEXT (section 4.5.3):
compressor to reinitialize TS_OFFSET at wraparound, there will be no
problems interacting with a decompressor that still tries to follow The entire point 5, i.e. the entire text starting from "5.
4.5.3 points 4-5. For a decompressor that assumes the compressor will Interpretation interval at wraparound ...", down to and including
follow the above recommendation, there is a risk of the decompressor the block of text that starts with "Let a be the number of LSBs"
context becoming invalid. Considering the size if the TS number and that ends with "...interpretation interval is b." is incorrect
space, and thus the number of packets between each TS wraparound, the and is thus invalid.
potential cost of this is considered negligible.
4.6. Recalculating TS_OFFSET 4.6. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the 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. established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
To ensure correct decompression of subsequent packets, the To ensure correct decompression of subsequent packets, the
decompressor MUST therefore always recalculate the RTP TS modulo, decompressor MUST therefore always recalculate TS_OFFSET (RTP TS
TS_OFFSET, when a packet with an unscaled TS value is received. modulo TS_STRIDE) when a packet with an unscaled TS value is
received.
4.7. TS_STRIDE and the Tsc flag in Extension 3 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 The Tsc flag in Extension 3 indicates whether TS is scaled or not.
must be noted that the Tsc value apply to all TS bits, also if there The value of the Tsc flag thus applies to all TS bits, also if there
are no TS bits in the extension itself. are no TS bits in the extension itself. When TS is scaled, it is
always scaled using context(TS_STRIDE). The legend for Extension 3 in
section 5.7.5 incorrectly states that value(TS_STRIDE) is used for
scaled TS, which is incorrect.
When a compressor uses Extension 3 to re-establish a new value for If TS_STRIDE is present in Extension 3, as indicated by the Tss flag
TS_STRIDE, it MUST send unscaled TS together with TS_STRIDE for some being set, the TS field in the compressed header SHOULD contain
packets until decompressor confidence is obtained. unscaled TS bits, i.e. the Tsc flag SHOULD NOT be set when Tss is set
since an unscaled TS is needed together with TS_STRIDE to recalculate
the TS_OFFSET. If TS_STRIDE is included in a compressed header with
scaled TS, the decompressor must ignore and discard field(TS_STRIDE).
When Tsc=1, TS MUST be scaled using context(TS_STRIDE) and not INCORRECT RFC 3095 TEXT (section 4.5.3):
value(TS_STRIDE), which is incorrectly stated in the legend for
Extension 3 in section 5.7.5. Instead, if the decompressor receives "Tsc: Tsc = 0 indicates that TS is not scaled;
an Extension 3 with TS_STRIDE included while Tsc=1, the decompressor Tsc = 1 indicates that TS is scaled according to section
would simply ignore/discard value(TS_STRIDE). Since an unscaled TS is 4.5.3, using value(TS_STRIDE).
needed together with TS_STRIDE to recalculate TS_OFFSET, it is thus Context(Tsc) is always 1. If scaling is not desired, the
meaningless to include TS_STRIDE in Extension 3 if Tsc is set to 1. compressor will establish TS_STRIDE = 1."
CORRECTED TEXT:
"Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to section
4.5.3, using context(TS_STRIDE).
Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1.
If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is
present in the extension), field(TS_STRIDE) MUST be ignored
and discarded."
When the compressor re-establishes a new value for TS_STRIDE using
Extension-3, it should send unscaled TS bits together with TS_STRIDE.
4.8. Using timer-based compression 4.8. Using timer-based compression
Timer-based compression of the RTP timestamp, as described in section 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 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 (bytes) needed when the timestamp can not be inferred from the SN.
should thus be noted that timer-based compression has no influence on Timer-based compression is only used for decompression of compressed
decompression of packets where no timestamp bits are sent, in that headers that contains a TS field, otherwise when no timestamp bits
case the timestamp is just linearly inferred from the SN (see section are present the timestamp is linearly inferred from the SN (see
4.2 of this document). section 4.2 of this document).
Whether to use timer-based compression or not is controlled by the 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- 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 DYN, or by a compressed packet with extension 3. Before timer-based
on timer-based compression by setting TIME_STRIDE to a value > 0, but compression can be used, the decompressor has to inform the
that can be done first after the decompressor has declared its clock compressor (on a per-channel basis) about its clock resolution by
resolution, which is done by sending a CLOCK feedback option for any sending a CLOCK feedback option for any CID on the channel. The
CID on the channel. compressor can then initiate timer-based compression by sending (on a
per-context basis) a non-zero TIME_STRIDE to the decompressor. First
5. List compression issues when the compressor is confident that the decompressor has received
the TIME_STRIDE value, it can switch to timer-based compression.
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 5. List compression
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 5.1. CSRC list items in RTP dynamic chain
Section 5.7.7.6 defines the static and dynamic parts of the RTP 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 header. This section indicates a 'Generic CSRC list' field in the
dynamic chain, which has a variable length. This field uses the same dynamic chain, which has a variable length (see section 5.8.6). This
encoding rules as the 'Generic extension header list' in the IPv4 field is always at least one octet in size, even if the list is empty
header, so the same rules apply to its length. (as opposed to the CSRC list in the uncompressed RTP header, which is
not present when the RTP CC field is set to 0).
5.3. RTP dynamic chain 5.2. Multiple occurrences of the CC field
Section 5.7.7.6 defines the static and dynamic parts of the RTP The static and the dynamic parts of the RTP header are defined in
header. In the dynamic part, a 'CC' field indicates the number of Section 5.7.7.6. In the dynamic part, a CC field indicates the number
CSRC items present in the 'Generic CSRC list'. A 'CC' field can also of CSRC items present in the 'Generic CSRC list'. Another CC field
be found within the 'Generic CSRC list' (when present), and these also appears within the 'Generic CSRC list' (section 5.8.6.1),
fields would then have the same meaning. In order to decode a because Encoding Type 0 is always used in the dynamic chain. Both CC
compressed packet correctly it's necessary to know the 'CC' value fields have the same meaning: the value of the CC field determines
because it has serious impact on the packet's length. In normal the number of XI items in the CSRC list for Encoding Type 0, and it
case, the values of the fields are equal. is not used otherwise. Therefore, the following applies:
Proposed behavior if the values are different: FORMAL ADDITION TO RFC 3095:
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 the second field (inside the CSRC
list) MUST be used when decompressing packets. For outgoing
packets both fields SHOULD be set to the same value.
5.4. Compressed lists in UO-1-ID packets "The first octet in the dynamic part of the RTP header contains a
CC field, as defined in section 5.7.7.6. A second occurrence
appears in the 'Generic CSRC list', which is also in the dynamic
part of the RTP header, where Encoding Type 0 is used according
to the format defined in 5.8.6.1.
This section describes the situation when a UO-1-ID packet carries a The compressor MUST set both occurrences of the CC field to the
compressed list. Compressed lists are encoded using Encoding Type 0 same value.
(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.
On one hand, the decompressor shouldn't save the list because UO-1-ID The decompressor MUST use the value of the CC field from the
packets doesn't update the context. On the other hand, the Encoding Type 0 within the Generic CRSC list, and it MUST thus
decompressor updates its translation table whenever an (Index, item) ignore the first occurrence of the CC field."
pair is received (section 5.8.1). The decompressor must be able to
handle such a packet, thus it MUST follow section 5.8.1 and update
its translation table whenever an (Index, item) pair is received.
The compressor MUST also increment Counter by 1 (section 5.8.1.2).
5.5. Bit masks in list compression 5.3. Bit masks in list compression
A 7-bit or 15-bit mask may be used in the insertion and/or removal The insertion and/or removal schemes, described in sections 5.8.6.2 -
schemes for compressed lists. It should be noted that even if a list 5.8.6.4, use bit masks to indicates insertion or removal positions
has more than 7 items, a 7-bit mask MAY be used as long as changes within the reference list. The size of the bit mask can be 7-bit or
are only applied in the first part of the reference list, and items 15-bit.
with an index not covered by the 7-bit mask MUST stay unchanged.
5.6. Headers compressed with list compression The compressor MAY use a 7-bit mask, even if the reference list has
more than 7 items, provided that changes to the list are only applied
to items within the first 7 items of the reference list, leaving
items with an index not covered by the 7-bit mask unchanged.
The decompressor MUST NOT modify items with an index not covered by
the 7-bit mask, when a 7-bit mask is received for a reference list
that contains more than 7 items.
5.4. Headers compressed with list compression
In section 5.8, it is stated that headers which can be part of In section 5.8, it is stated that headers which can be part of
extension header chains INCLUDE AH, null ESP, minimal encapsulation extension header chains "include" AH, null ESP, minimal encapsulation
(MINE), GRE, and IPv6 extensions. This list of headers which can be (MINE), GRE, and IPv6 extensions. This list of headers which can be
compressed is correct, but the word INCLUDE should not be there, compressed is correct, but the word "include" should not be there,
since only the header types listed can actually be handled. It should since only the header types listed can actually be handled. It should
further be noted that for the Minimal Encapsulation (MINE) header, further be noted that for the Minimal Encapsulation (MINE) header,
there is no explicit discussion of how to compress it, as the header there is no explicit discussion of how to compress it, as the header
is either sent uncompressed or fully compressed away. is either sent uncompressed or fully compressed away.
5.7. ESP NULL header list compression 5.5. ESP NULL header list compression
Due to the offset of the fields in the trailer part of the ESP Due to the offset of the fields in the trailer part of the ESP
header, a compressor MUST NOT compress packets containing more than header, a compressor MUST NOT compress packets containing more than
one NULL ESP header. one NULL ESP header, unless the second-outermost header is treated as
a regular ESP header and the packets are compressed using profile
0x0003.
5.8. Translation tables and indexes for IP extension headers 5.6. Translation tables and indexes for IP extension headers
Section 5.8.4 aims at describing how list indexes are associated to Section 5.8.4 describes how list indexes are associated to list items
list items and how table lists are built for IP extension headers. and how table lists are built for IP extension headers. The text
However, the text is not very clear, and it is actually wrong to just incorrectly states that one index per type is used, since the same
say that an index per type is used, since the same type can appear type can appear several times with different content in one single
several times with different content in one single chain. chain.
In IP extension header list compression, an index is associated with In IP extension header list compression, an index is associated with
each individual extension header of an extension header chain. When each individual extension header of an extension header chain. When
there are multiple occurrences of the same extension type (Protocol there are multiple non-identical occurrences of the same extension
Number) within a header chain, each MUST be given its own index type (Protocol Number) within a header chain, each MUST be given its
(assuming they are not identical). When content of extension headers own index.
changes, an implementation can choose to either initiate a new index,
or update the existing one. Note that some extensions can be In the case where there are multiple identical occurrences of the
compressed away also when some fields change, as there are other same extension type, the compressor can associate them to the same
means to explicitly or implicitly convey the changes. index. When the value of an item whose index occurs more than once in
the list is updated, the compressor MUST send the value for each
occurrence of that index in the list.
When content of extension headers changes, an implementation can
choose to either use a different index, or update the existing one.
Some extensions can be compressed away also when some fields change,
as those changes can be conveyed to the decompressor implicitly (e.g.
sequence numbers in extension headers that can be inferred from the
RTP SN) or explicitly (e.g. as part of the 'IP extension header(s)'
field in extension 3).
When there is more than one IP header, there is more than one list of When there is more than one IP header, there is more than one list of
extension headers, and a translation table is maintained for each extension headers, and a translation table is maintained for each
list independently of one another. list independently of one another.
5.9. Reference list 5.7. Reference list
A list compressed using encoding type 1 (insertion), type 2 (removal) A list compressed using encoding type 1 (insertion), type 2 (removal)
or type 3 (removal/insertion) uses a coding scheme that is based on or type 3 (removal/insertion) uses a coding scheme that is based on
the use of a reference list in the context (identified as ref_id). the use of a reference list in the context (identified as ref_id).
It is noted that while it could seem a fair choice to send a type 1 While it could seem a fair choice to send a type 1 list when ref_id
list when ref_id is an empty list, there is no gain in doing so with is an empty list, there is no gain in doing so with respect to using
respect to using a type 0 list. Sending a type 2 list when ref_id is a type 0 list. Sending a type 2 list when ref_id is an empty list
an empty list would lead to a failure, while sending a type 3 list would lead to a failure, while sending a type 3 list has very little
has very little meaning. All these alternatives could be seen as meaning. All these alternatives could be seen as possible, based on
possible, based on how list compression is specified in RFC 3095. how list compression is specified in RFC 3095.
If these alternatives were allowed, a decompressor would become If these alternatives were allowed, a decompressor would become
required to maintain a sliding window of ref_id lists in R-mode, even required to maintain a sliding window of ref_id lists in R-mode, even
for the case where no items are sent as compressed list. To avoid for the case where no items are sent in the compressed list, and this
this, the sending of type 1, 2, and 3 compressed list using an empty is not a desirable requirement. Using list encoding type 1, type 2,
reference list is disallowed. Therefore empty lists are not needed to and type 3 is therefore only allowed for non-empty reference lists.
be stored in the sliding window in the decompressor.
More specifically, when the compressor uses list encoding of type 1, FORMAL ADDITION TO RFC 3095:
type 2, and type 3, the ref_id used MUST refer to a non-empty
reference list, regardless of the operating mode. "Regardless of the operating mode, for list encoding of type 1,
type 2, and type 3 lists, ref_id MUST refer to a non-empty list."
5.8. Compression of AH and GRE sequence numbers
Section 5.8.4.2 and section 5.8.4.4 describes how to compress the
Authentication Header (AH) and the Generic Routing Encapsulation
(GRE) header. Both these sections present a possibility to omit the
AH/GRE sequence number in the compressed header, under certain
circumstances. However, the specific conditions for omitting the
AH/GRE sequence number, as well as the concrete compression and
decompression procedures to apply, are not clearly defined to
guarantee robustness and facilitate interoperable implementation.
Proper rules are provided for the ESP case, i.e.:
"Sequence Number: Not sent when the offset from the sequence
number of the compressed header is constant, when the compressor
has confidence that the decompressor has established the correct
offset. When the offset is not constant, the sequence number may
be compressed by sending LSBs"
The same logic applies to the AH/GRE sequence numbers.
INCORRECT RFC 3095 TEXT (section 5.8.4.2):
"If the sequence number in the AH linearly increases as the RTP
Sequence Number increases, and the compressor is confident that
the decompressor has obtained the pattern, the sequence number in
AH need not be sent. The decompressor applies linear
extrapolation to reconstruct the sequence number in the AH."
CORRECTED TEXT:
"The AH sequence number can be omitted from the compressed header
when the offset from the sequence number (SN) of the compressed
header is constant, when the compressor has confidence that
the decompressor has established the correct offset."
INCORRECT RFC 3095 TEXT (section 5.8.4.4):
"If the sequence number in the GRE header linearly increases as
the RTP Sequence Number increases and the compressor is confident
that the decompressor has received the pattern, the sequence
number in GRE need not be sent. The decompressor applies linear
extrapolation to reconstruct the sequence number in the GRE
header."
CORRECTED TEXT:
"The GRE sequence number can be omitted from the compressed header
when the offset from the sequence number (SN) of the compressed
header is constant, when the compressor has confidence that the
decompressor has established the correct offset."
6. Updating properties 6. Updating properties
6.1. Implicit updates 6.1. Implicit updates
A context updating packet that contains compressed sequence number A context updating packet that contains compressed sequence number
information may also carry information about other fields; in such information may also carry information about other fields; in such
case, these fields are updated according to the content of the case, these fields are updated according to the content of the
packet. The updating packet also implicitly updates inferred fields packet. The updating packet also implicitly updates inferred fields
(e.g. RTP timestamp) according to the current mode and the (e.g. RTP timestamp) according to the current mode and the
appropriate mapping function of the updated and the inferred fields. appropriate mapping function of the updated and the inferred fields.
An updating packet thus updates the reference values of all header An updating packet thus updates the reference values of all header
fields, either explicitly or implicitly, with an exception for the fields, either explicitly or implicitly, with an exception for the
UO-1-ID packet, which only updates TS, SN, IP-ID, and sequence UO-1-ID packet (see section 6.2 of this document). In UO-mode, all
numbers of IP extension headers (see 5.7.3). In UO-mode, all packets packets are updating packets, while in R-mode all packets with a CRC
are updating packets, while in R-mode all packets with a CRC are are updating packets.
updating packets.
For example, a UO-0 packet contains the compressed RTP sequence For example, a UO-0 packet contains the compressed RTP sequence
number (SN). Such a packet also implicitly updates RTP timestamp, number (SN). Such a packet also implicitly updates RTP timestamp,
IPv4 ID, and sequence numbers of IP extension headers. IPv4 ID, and sequence numbers of IP extension headers.
6.2. Updating properties of UO-1* 6.2. Updating properties of UO-1*
In section 5.7.3, the updating properties of UO-1* are stated: Section 5.7.3 states that the values provided in extensions carried
by a UO-1-ID packet do not update the context, except for SN, TS, or
IP-ID fields. However, section 5.8.1 correctly states that the
translation table in the context is updated whenever an (Index, item)
pair is received, something that is contradicted by the statement in
5.7.3 because the UO-1-ID packet can carry extension 3 with (Index,
item) pair items within the 'Compressed CSRC list' field. In addition
to this contradiction, the text does not mention what to do with the
other sequence numbers inferred from the SN, which are also to be
implicitly updated. The updating properties of UO-1* as stated by
section 5.7.3 are thus incomplete.
INCOMPLETE RFC 3095 TEXT (section 5.7.3):
"Values provided in extensions, except those in other SN, TS, "Values provided in extensions, except those in other SN, TS,
or IP-ID fields, do not update the context." or IP-ID fields, do not update the context."
However, also sequence number fields of extension headers MUST be CORRECTED TEXT:
updated, which means the updating properties should be rephrased as:
"The only values provided in extensions that update the context are "UO-1-ID packets only updates TS, SN, IP-ID, and sequence
the additional bits for the SN, TS, or IP-ID fields. Other values numbers of IP extension headers. Other values
provided in extensions do not update the context. Note that provided in extensions do not update the context.
sequence number fields of extension headers are also updated."
See also section 5.4 of this document. The decompressor MUST update its translation table whenever an
(Index, item) pair is received, as per Section 5.8.1, and this
rule applies also to UO-1-ID packets."
6.3. Context updating properties for IR packets
IR packets do not clear the whole context, but update 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.
A consequence of this is that fields that are not updated by the IR
packet, e.g. the translation tables for list compression, MUST NOT be
invalidated by the decompressor when it assumes context damage.
6.4. RTP padding field (R-P) in extension 3
Section 5.7.5 defines the properties of RTP header flags and fields
in extension 3. These get updated when the rtp flag of the extension
3 is set, i.e. when rtp = 1, otherwise they are not updated. However,
it is unclear how extension 3 updates the R-P bit in the context.
INCOMPLETE RFC 3095 TEXT (section 5.7.5):
"R-P: RTP Padding bit, absolute value (presumed zero if absent)."
CORRECTED TEXT:
"R-P: RTP Padding bit. If R-PT = 1, R-P is the absolute value of
the RTP padding bit and this value updates context(R-P). If
R-PT = 0, context(R-P) is updated to zero."
6.5. RTP eXtension bit (X) in dynamic part
Section 5.7.7.6 defines the properties of the RTP header flags and
fields in the RTP part of the dynamic chain of IR and IR-DYN packets.
However, it is unclear how the X bit is updated in the context.
INCOMPLETE RFC 3095 TEXT (section 5.7.7.6):
"X: Copy of X bit from RTP header (presumed 0 if RX = 0)"
CORRECTED TEXT:
"X: X bit from RTP header. If RX = 1, X is the X bit from the RTP
header and this value updates context(X). If RX = 0,
context(X) is updated to zero."
7. Context management and CID/context re-use 7. Context management and CID/context re-use
7.1. The decompressor MUST keep MAX_CID contexts 7.1. Persistence of decompressor contexts
As part of the negotiated channel parameters, compressor and As part of the negotiated channel parameters, compressor and
decompressor have through the MAX_CID parameter agreed on the highest decompressor have through the MAX_CID parameter agreed on the highest
context identification (CID) number to be used. By agreeing on context identification (CID) number to be used. By agreeing on
MAX_CID, the decompressor also agrees to provide memory resources to MAX_CID, the decompressor also agrees to provide memory resources to
host at least MAX_CID+1 contexts, and an established context with a host at least MAX_CID+1 contexts, and an established context with a
CID within this negotiated space MUST be kept by the decompressor CID within this negotiated space MUST be kept by the decompressor
until either the CID gets re-used, or the channel is taken down or until either the CID gets re-used, or the channel is taken down or
re-negotiated. re-negotiated.
7.2. CID/context re-use 7.2. CID/context re-use
As part of the channel negotiation, the maximal number of active As part of the channel negotiation, the maximal number of active
contexts supported is negotiated between the compressor and the contexts supported is negotiated between the compressor and the
decompressor through the MAX_CID parameter. The value of MAX_CID can decompressor through the MAX_CID parameter. The value of MAX_CID can
of course vary enormously between different link scenarios, as well differ significantly from one link application to another, as well as
as the load in terms of actual packet streams to compress. Depending the load in terms of the number of packet streams to compress. The
on link technology, the ROHC channel lifetime will also vary from lifetime of a ROHC channel can also vary, from almost permanent to
almost permanent to rather short-lived. However, in general it is not rather short-lived. However, in general it is not expected that
expected that resources will be allocated for more contexts than what resources will be allocated for more contexts than what can
can reasonably be expected to be active concurrently over the link. reasonably be expected to be active concurrently over the link. As a
As a consequence hereof, context identifiers (CIDs) and context consequence hereof, context identifiers (CIDs) and context memory are
memory are resources that will have to be re-used by the compressor resources that will have to be re-used by the compressor as part of
as part of what can be considered normal operation. what can be considered normal operation.
How context resources are re-used is in RFC 3095 [1] and subsequent How context resources are re-used is in RFC 3095 [1] and subsequent
ROHC standards basically left unspecified and up to implementation. ROHC standards left unspecified and up to implementation. This
However, re-using a CID and its allocated memory is not always as document does not intends to change that, i.e. ROHC resource
simple as initiating a contexts with a previously unused CID. Because management is still considered an implementation detail. However, re-
some profiles can be operating in various modes where packet formats using a CID and its allocated memory is not always as simple as
vary depending on current mode, care has to be taken to ensure that initiating a context with a previously unused CID. Because some
the old context data will be completely and safely overwritten, 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 eliminating the risk of undesired side effects from interactions
between old and new context data. between old and new context data. This document therefore points out
some important core aspects to consider when implementing resource
management in ROHC compressors and decompressors.
On a high level, CID/context re-use can be of two kinds, either re- 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, 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 or for a new context based on a different profile. These cases, are
discussed separately in the following two subsections. discussed separately in the following two subsections.
7.2.1. Re-using a CID/context with the same profile 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 For multi-mode profiles, such as those defined in RFC 3095 [1], mode
a CID/context is re-used for a new context based on the same profile transitions are performed using a decompressor-initiated handshake
as the old context, the current mode of operation MUST be inherited procedure, as defined in section 5.6. When a CID/context is re-used
from the old to the new context. The reason for this is that there is for a new context based on the same profile as the old context, the
no reliable way for the compressor to inform the decompressor that a current mode of operation SHOULD be inherited from the old to the new
CID/context re-use is happening. The decompressor can thus not be context. Specifically, the compressor SHOULD continue to operate
expected to flush the context memory for the CID, and there is no way using the mode of operation of the old context also with the new
to trigger a safe mode switching, which requires a decompressor- context. The reason for this is that there is no reliable way for the
initiated handshake procedure, as defined in section 5.6. compressor to inform the decompressor that a CID/context re-use is
happening. The decompressor can thus not be expected to clear the
context memory for the CID (see section 6.3 of this document), and
there is no way to trigger a safe mode switching (which requires the
decompressor-initiated handshake procedure).
It should be noted that the rule of mode inheritance applies also The rule of mode inheritance applies also when the
when the CONTEXT_REINITIALIZATION signal is used to reinitiate an CONTEXT_REINITIALIZATION signal (section 6.3.1) is used to reinitiate
entire context. an entire context.
7.2.2. Re-using a CID/context with a different profile 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 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 than the old context, both the compressor and the decompressor MUST
initial mode of the profile (if it is a multi-mode profile). This start operation with that context in the initial mode of the profile
applies both to IR-initiated new contexts and profile downgrades with (if it is a multi-mode profile). This applies both to IR-initiated
IR-DYN (e.g. the IP/UDP/RTP->IP/UDP downgrade in [1]section 5.11.1). new contexts and profile downgrades with IR-DYN (e.g. the profile
0x0001 -> profile 0x0002 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 Type 0 and type 1 packets have different formats in U/O- and R-mode,
updates all fields carried in the IR header. Similarly, an IR without and these R-mode packets have no CRC. When initiating a new context
a dynamic chain simply updates the static part of the context, while on a re-used R-mode CID, there is a risk that the decompressor will
the rest of the context is left unchanged. misinterpret compressed packets, if the initiating IR packets are
lost.
A consequence of this is that fields that cannot be updated by the IR A CID for a context currently operating in R-mode SHOULD therefore
packet, e.g. the Translation Tables for list compression, MUST NOT be not be re-used for a new context based on a different profile than
invalidated by the decompressor when it assumes context damage. the old context. A compressor doing otherwise should minimize the
risk for misinterpretation of R-0/R-1 by e.g. not using packets of
types beginning with 00 or 10 before it is highly confident that the
new context has successfully been initiated at the decompressor.
8. Other protocol clarifications 8. Other protocol clarifications
8.1. Meaning of NBO 8.1. Meaning of NBO
In general, an unset flag indicates the normal operation and a set In IPv4 dynamic part (Section 5.7.7.4), if the 'NBO' bit is set, it
flag indicates unusual behavior. However, in IPv4 dynamic part means that network byte order is used.
(Section 5.7.7.4), if the 'NBO' bit is set, it means that network
byte order is used.
8.2. IP-ID 8.2. IP-ID
According to Section 5.7 IP-ID means the compressed value of the IPv4 According to Section 5.7, IP-ID means the compressed value of the
header's 'Identification' field. Compressed packets contain this IPv4 header's 'Identification' field. Compressed packets contain this
compressed value (IP-ID), while IR packets with dynamic chain and IR- compressed value (IP-ID), while IR packets with dynamic chain and IR-
DYN packets transmit the original, uncompressed Identification field DYN packets transmit the original, uncompressed Identification field
value. The IP-ID field always represents the Identification value of value. The IP-ID field always represents the Identification value of
the innermost IPv4 header whose corresponding RND flag is not 1. 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 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 as 16-bit uncompressed Identification value(s) at the end of the
compressed base header, according to the IP-ID description (see 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. 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 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 indicated by RND/RND2 being set to 1), the decompressor ignores IP-ID
bits sent within compressed base headers. bits sent within compressed base headers.
It should be noted that when RND*=0, IP-ID is always compressed, i.e. When RND=RND2=0, IP-ID is compressed, i.e. expressed as an SN offset
expressed as an SN offset and byte-swapped if NBO=0. This is the case and byte-swapped if NBO=0. This is the case also when 16 bits of IP-
even when 16 bits of IP-ID is sent in extension 3. ID is sent in extension 3.
When RND=0 but no IP-ID bits are sent in the compressed header, the 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 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 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, 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 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. if no bits are sent for IP-ID, its SN offset slope defaults to 0.
8.3. Extension-3 in UO-1-ID packets 8.3. Extension-3 in UOR-2* packets
Extension-3 is applied to give values and indicate changes to fields Some flags of the IP header in the extension (e.g. NBO or RND) may
other than SN, TS and IP-ID in IP header(s) and RTP header. In case change the interpretation of fields in UOR-2* packets. In such cases,
of UO-1-ID packets, it should be noted that values provided in when a flag changes in Extension-3, a decompressor MUST re-parse the
extensions do not update the context, with an exception for SN, TS UOR-2* packet.
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
NOT 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). See also section 5.4 of this document.
Besides, usage of Extension-3 in UO-1-ID can be useful to compress a 8.4. Multiple occurrences of the M bit
transient change in a packet stream. For example, if a field's value
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 The RTP header part of Extension 3, as defined by section 5.7.5,
includes a one-bit field for the RTP Marker bit. This field is also
present in all compressed base header formats except for UO-1-ID,
meaning there may be multiple occurrences of the field within one
single compressed header. In such cases, the two M fields must have
the same value.
If Extension-3 is used in a UOR-2* packet then the information of the FORMAL ADDITION TO RFC 3095:
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 "When there are two occurrences of the M field in a compressed
of fields in UOR-2* packets. In these cases, when a flag changes in header (both in the compressed base header and in the RTP part of
Extension-3, a decompressor SHOULD re-parse the UOR-2* packet. Extension 3), the compressor MUST set both these occurrences of
the M field to the same value.
At the decompressor, if the two M field values of such a packet
are not identical, the packet MUST be discarded."
8.5. Multiple SN options in one feedback packet 8.5. Multiple SN options in one feedback packet
The length of the sequence number field in the original ESP header is 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 32 bits. The format of the SN feedback option (5.7.6.6) allows for 8
feedback packet unless it uses multiple SN options in one feedback additional SN bits to the 12 SN bits of the FEEDBACK-2 format
packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet can (5.7.6.1). One single SN feedback option is thus not enough for the
contain variable number of feedback options and the options can decompressor to send back all the 32 bits of the ESP sequence number
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. appear in any order.
A compressor MUST be able to process multiple SN options in one When processing multiple SN options in one feedback packet, the SN
feedback packet, and SN would be given by concatenating the fields. would be given by concatenating the fields.
8.6. Multiple CRC 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 Although it is not useful to have more than one single CRC option in
in a feedback packet, having multiple CRC options is still allowed. a feedback packet, having multiple CRC options is still allowed. If
If multiple CRC options are included, all such CRC options will be multiple CRC options are included, all such CRC options MUST be
identical, as they will be calculated over the same header. identical, as they will be calculated over the same header, the
compressor SHOULD otherwise discard the feedback packet.
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 original transition procedures in sections 5.6.5 and 5.6.6 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 be mistakenly
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
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? 8.7. Responding to lost feedback links
Althought this is neither desirable or expected, it may happen that a Although this is neither desirable or expected, it may happen that a
link used to carry feedback between two associated instances become link used to carry feedback between two associated instances becomes
unavailable. If the compressor can be notified of such event, the unavailable. If the compressor can be notified of such event, the
most suitable response in such case is for the compressor to restart compressor SHOULD restart compression for each flow that is operating
compression for each flow going over the ROHC channel, except for in R-mode. When restarting compression, the compressor SHOULD use a
flows that are operating in U/O-mode or flows using a CID associated different CID for each flow being restarted; this is useful to avoid
with the uncompressed profile (profile 0x0000). When restarting that packet types for which both U/O-mode and R-mode share the same
compression, the compressor SHOULD use a different CID for each flow type identifier gets misinterpreted when restarting the flow in U-
being restarted; this is useful to avoid that packet types for which mode (see also section 7.2 of this document).
both U/O-mode and R-mode share the same type identifier gets
misinterpreted when restarting the flow in U-mode.
Generally, feedback links are not expected to disappear when once Generally, feedback links are not expected to disappear when once
present, but it should be noted that this might be the case for present, but it should be noted that this might be the case for
certain link technologies. certain link technologies.
8.9. What does "presumed zero if absent" mean on page 88? 8.8. UOR-2 in profile 0x0002 (UDP) and profile 0x0003 (ESP)
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) and profile 3 (ESP)
One single new format is defined for UOR-2 in profile 2 and profile One single new format is defined for UOR-2 in profile 0x0002 and
3, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile 0x0003, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS)
profile 1. The same UOR-2 format is thus used independent of if there formats from profile 0x0001. The same UOR-2 format is thus used
are IP headers with a corresponding RND=1 or not. independent of whether there are IP headers with a corresponding
RND=1 or not. This also applies to the IP profile [4] and the IP/UDP-
Lite profile [5].
8.11. Sequence number LSB's in IP extension headers 8.9. Sequence number LSB's in IP extension headers
In section 5.8.5, formats are defined for compression of IP extension In section 5.8.5, formats are defined for compression of IP extension
header fields. These include compressed sequence number fields, and header fields. These include compressed sequence number fields, and
it is said that these fields contain "LSB of sequence number". This these fields contain "LSB of sequence number". These sequence numbers
means these sequence numbers are not "LSB-encoded" as e.g. the RTP are not "LSB-encoded" as e.g. the RTP sequence number, but are the
sequence number with an interpretation interval, but are actually LSB's of the uncompressed fields.
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.
For implementers who still want to make use of the optional O-mode 8.10. Expecting UOR-2 ACKs in 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 Usage of UOR-2 ACKs in O-mode, as discussed in section 5.4.1.1.2, is
optional. A decompressor can also send ACKs for purposes other than
to acknowledge the UOR-2, without having to continue sending ACKs for
all UOR-2. Similarly, a compressor implementation can ignore UOR-2
ACKs for the purpose of adapting the optimistic approach strategies.
The AH and GRE sequence numbers are compressed exactly as the ESP It is thus RECOMMENDED to not use of the optional ACK mechanism in
sequence number. Specifically, the principle for when to include or O-mode, neither in compressor nor in decompressor implementations.
exclude the AH and GRE sequence numbers is the same as for ESP, i.e.
the following rule from section 5.8.4.3 applies to all these sequence
numbers:
"Sequence Number: Not sent when the offset from the sequence number Using an incorrect expectation on UOR-2 ACKs as a basis for
of the compressed header is constant. When the compressor behavior will significantly degrade the compression
offset is not constant, the sequence number is performance. This is because UOR-2 ACKs can be sent from a
compressed by sending LSBs. See 5.8.4." decompressor for other purposes than to acknowledge the UOR-2 packet,
e.g. to send feedback such as clock resolution, or to initiate a mode
transition. If an implementation does use the optional acknowledgment
algorithm described in Section 5.4.1.1.2, it must make sure to set
the k_3 and n_3 parameters to much larger values than one to ensure
that the compressor performance is not degraded due to the problem
described above.
9. ROHC negotiation clarifications 9. ROHC negotiation
According to section 4.1, the link layer must provide means to Section 4.1 states that the link layer must provide means to
negotiate e.g. the channel parameters listed in section 5.1.1. One negotiate e.g. the channel parameters listed in section 5.1.1. One of
of these parameters is the PROFILES parameter, which is said to be a these parameters is the PROFILES parameter, which is a set of non-
set of non-negative integers where each integer indicates a profile negative integers where each integer indicates a profile supported by
supported by the decompressor. This can be interpreted as if it is the decompressor.
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 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 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 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 link, the profile used is identified only with the 8 LSB bits, which
means that the compressor and decompressor must have agreed on 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, variant to use for each profile.
but the negotiation protocol must provide means to do it.
In conclusion, the negotiation protocol must be able to communicate The negotiation protocol must thus be able to communicate to the
to the compressor the set of profiles supported by the decompressor, compressor the set of profiles supported by the decompressor, and
and when multiple variants of the same profile are available, also when multiple variants of the same profile are available, also
provide means for the decompressor to know which variant will be used provide means for the decompressor to know which variant will be used
by the compressor. This basically means that the PROFILES set after by the compressor. This basically means that the PROFILES set after
negotiation MUST NOT include more than one variant of a profile. negotiation MUST NOT include more than one variant of a profile.
10. PROFILES suboption in ROHC-over-PPP 10. PROFILES suboption in ROHC-over-PPP
The logical union of suboptions for IPCP and IPV6CP negotiations, as The logical union of suboptions for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [2], can not be used for the PROFILES 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 suboption, as the whole union would then have to be considered within
each of the two IPCP negotiations, to avoid getting an ambiguous each of the two IPCP negotiations, to avoid getting an ambiguous
profile set. An implementation of RFC 3241 MUST therefore ensure the profile set. An implementation of RFC 3241 MUST therefore ensure the
same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP). same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP).
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles 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 In the ROHC IP-only profile, section 3.3 of RFC 3843 [4], a mechanism
for encoding of a constant Identification value in IPv4 (constant IP- for encoding of a constant Identification value in IPv4 (constant IP-
ID) is defined. This mechanism is also used by the ROHC UDP-Lite ID) is defined. This mechanism is also used by the ROHC UDP-Lite
profiles, RFC 4019 [5]. profiles, RFC 4019 [5].
It should be noted that the "Constant IP-ID" mechanism applies to The "Constant IP-ID" mechanism applies to both the inner and the
both the inner and the outer IP header, when present , meaning that outer IP header, when present, meaning that there will be both a SID
there will be both a SID and a SID2 context value. and a SID2 context value.
12. Security considerations 12. Security considerations
This document provides a number of clarifications to [1], but it does This document provides a number of corrections and clarifications to
not make any changes or additions to the protocol. As a consequence, [1], but it does not make any changes with regards to the security
the security considerations of [1] apply without additions. aspects of the protocol. As a consequence, the security
considerations of [1] apply without additions.
13. IANA considerations 13. IANA considerations
This document does not require any IANA actions. This document does not require any IANA actions.
14. Acknowledgment 14. Acknowledgment
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, The authors would like to thank Vicknesan Ayadurai, Carsten Bormann,
Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy
Lundemo, Alan Kennington and Remi Pelland for their contributions and Lundemo, Alan Kennington and Remi Pelland for their contributions and
comments. Thanks also to the committed document reviewers, Carl comments. Thanks also to the committed document reviewers, Carl
Knutsson and Biplab Sarkar, who reviewed the document during working Knutsson and Biplab Sarkar, who reviewed the document during working
group last-call. group last-call.
15. References 15. References
15.1. Normative References 15.1. Normative References
[1] C. Bormann, et al., "RObust Header Compression (ROHC) Framework [1] C. Bormann, et al., "RObust Header Compression (ROHC): Framework
and four profiles: RTP, UDP, ESP, and uncompressed", and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
[2] C. Bormann, "Robust Header Compression (ROHC) over PPP", [2] C. Bormann, "Robust Header Compression (ROHC) over PPP",
RFC 3241, April 2002. RFC 3241, April 2002.
[3] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC): [3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.
[4] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC):
A Compression Profile for IP", RFC 3843, June 2004. A Compression Profile for IP", RFC 3843, June 2004.
[4] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994. [5] G. Pelletier, "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References 15.2. Informative References
[5] G. Pelletier, "RObust Header Compression (ROHC): Profiles for [7] L-E. Jonsson, G. Pelletier & K. Sandlund, "RObust Header
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005. Compression (ROHC): A Link-Layer Assisted Profile for
IP/UDP/RTP", RFC 4362, June 2004.
16. Authors' Addresses 16. Authors' Addresses
Lars-Erik Jonsson Lars-Erik Jonsson
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61 Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
skipping to change at page 22, line 13 skipping to change at page 27, line 13
EMail: peter.kremer@ericsson.com EMail: peter.kremer@ericsson.com
Appendix A - Sample CRC algorithm Appendix A - Sample CRC algorithm
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict; use strict;
#================================= #=================================
# #
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 # 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, # This little demo shows the four types of CRC in use in RFC 3095,
# the robust header compression standard. Type your data in # the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D. # hexadecimal form and then press Control+D.
# #
#--------------------------------- #---------------------------------
# #
# utility # utility
# #
sub dump_bytes($) { sub dump_bytes($) {
my $x = shift; my $x = shift;
my $i; my $i;
for ($i = 0; $i < length($x); ) { for ($i = 0; $i < length($x); ) {
skipping to change at page 24, line 45 skipping to change at page 29, line 45
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires August 1, 2006. This Internet-Draft expires November 22, 2006.
 End of changes. 125 change blocks. 
580 lines changed or deleted 797 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/