4815
PROPOSED STANDARD
RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095
Authors: L-E. Jonsson, K. Sandlund, G. Pelletier, P. Kremer
Date: February 2007
Area: tsv
Working Group: rohc
Stream: IETF
Updates:
RFC 3095
Abstract
RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided. [STANDARDS-TRACK]
RFC 4815
PROPOSED STANDARD
Network Working Group L-E. Jonsson
Request for Comments: 4815 K. Sandlund
Updates: <a href="./rfc3095">3095</a>, <a href="./rfc3241">3241</a>, <a href="./rfc3843">3843</a>, <a href="./rfc4019">4019</a>, <a href="./rfc4362">4362</a> G. Pelletier
Category: Standards Track P. Kremer
February 2007
<span class="h1">RObust Header Compression (ROHC):</span>
<span class="h1">Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a></span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
<a href="./rfc3095">RFC 3095</a> defines the RObust Header Compression (ROHC) framework and
profiles for IP (Internet Protocol), UDP (User Datagram Protocol),
RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security
Payload). Some parts of the specification are unclear or contain
errors that may lead to misinterpretations that may impair
interoperability between different implementations. This document
provides corrections, additions, and clarifications to <a href="./rfc3095">RFC 3095</a>; this
document thus updates <a href="./rfc3095">RFC 3095</a>. In addition, other clarifications
related to <a href="./rfc3241">RFC 3241</a> (ROHC over PPP), <a href="./rfc3843">RFC 3843</a> (ROHC IP profile) and
<a href="./rfc4109">RFC 4109</a> (ROHC UDP-Lite profiles) are also provided.
<span class="grey">Jonsson, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
Table of Contents
<a href="#section-1">1</a>. Introduction and Terminology ....................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. CRC Calculation and Coverage ....................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. CRC Calculation ............................................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Padding Octet and CRC Calculations .........................<a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. CRC Coverage in CRC Feedback Options .......................<a href="#page-5">5</a>
<a href="#section-2.4">2.4</a>. CRC Coverage of the ESP NULL Header ........................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Mode Transition .................................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Feedback During Mode Transition to U- and O-Mode ...........<a href="#page-5">5</a>
3.1.1. Mode Transition Procedures Allowing Sparse Feedback .6
<a href="#section-3.1.2">3.1.2</a>. Transition from Reliable to Optimistic Mode .........<a href="#page-7">7</a>
<a href="#section-3.1.3">3.1.3</a>. Transition to Unidirectional Mode ...................<a href="#page-8">8</a>
<a href="#section-3.2">3.2</a>. Feedback During Mode Transition ............................<a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. Packet Decoding During Mode Transition .....................<a href="#page-9">9</a>
<a href="#section-4">4</a>. Timestamp Encoding ..............................................<a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. Encoding Used for Compressed TS Bits .......................<a href="#page-9">9</a>
<a href="#section-4.2">4.2</a>. (De)compression of TS without Transmitted TS Bits .........<a href="#page-10">10</a>
<a href="#section-4.3">4.3</a>. Interpretation Intervals for TS Encoding ..................<a href="#page-11">11</a>
<a href="#section-4.4">4.4</a>. Scaled RTP Timestamp Encoding .............................<a href="#page-11">11</a>
<a href="#section-4.4.1">4.4.1</a>. TS_STRIDE for Scaled Timestamp Encoding ............<a href="#page-11">11</a>
<a href="#section-4.4.2">4.4.2</a>. TS Wraparound with Scaled Timestamp Encoding .......<a href="#page-12">12</a>
<a href="#section-4.4.3">4.4.3</a>. Algorithm for Scaled Timestamp Encoding ............<a href="#page-12">12</a>
<a href="#section-4.5">4.5</a>. Recalculating TS_OFFSET ...................................<a href="#page-14">14</a>
<a href="#section-4.6">4.6</a>. TS_STRIDE and the Tsc Flag in Extension 3 .................<a href="#page-14">14</a>
<a href="#section-4.7">4.7</a>. Using Timer-Based Compression .............................<a href="#page-15">15</a>
<a href="#section-5">5</a>. List Compression ...............................................<a href="#page-15">15</a>
<a href="#section-5.1">5.1</a>. CSRC List Items in RTP Dynamic Chain ......................<a href="#page-15">15</a>
<a href="#section-5.2">5.2</a>. Multiple Occurrences of the CC Field ......................<a href="#page-15">15</a>
<a href="#section-5.3">5.3</a>. Bit Masks in List Compression .............................<a href="#page-16">16</a>
<a href="#section-5.4">5.4</a>. Headers Compressed with List Compression ..................<a href="#page-16">16</a>
<a href="#section-5.5">5.5</a>. ESP NULL Header List Compression ..........................<a href="#page-17">17</a>
<a href="#section-5.6">5.6</a>. Translation Tables and Indexes for IP Extension Headers ...<a href="#page-17">17</a>
<a href="#section-5.7">5.7</a>. Reference List ............................................<a href="#page-17">17</a>
<a href="#section-5.8">5.8</a>. Compression of AH and GRE Sequence Numbers ................<a href="#page-18">18</a>
<a href="#section-6">6</a>. Updating Properties ............................................<a href="#page-19">19</a>
<a href="#section-6.1">6.1</a>. Implicit Updates ..........................................<a href="#page-19">19</a>
<a href="#section-6.2">6.2</a>. Updating Properties of UO-1* ..............................<a href="#page-20">20</a>
<a href="#section-6.3">6.3</a>. Context Updating Properties for IR Packets ................<a href="#page-20">20</a>
<a href="#section-6.4">6.4</a>. RTP Padding Field (R-P) in Extension 3 ....................<a href="#page-20">20</a>
<a href="#section-6.5">6.5</a>. RTP eXtension bit (X) in dynamic part .....................<a href="#page-21">21</a>
<a href="#section-7">7</a>. Context management and CID/context Reuse .......................<a href="#page-21">21</a>
<a href="#section-7.1">7.1</a>. Persistence of Decompressor Contexts ......................<a href="#page-21">21</a>
<a href="#section-7.2">7.2</a>. CID/Context Reuse .........................................<a href="#page-21">21</a>
<a href="#section-7.2.1">7.2.1</a>. Reusing a CID/Context with the Same Profile ........<a href="#page-22">22</a>
<a href="#section-7.2.2">7.2.2</a>. Reusing a CID/Context with a Different Profile .....<a href="#page-23">23</a>
<a href="#section-8">8</a>. Other Protocol Clarifications ..................................<a href="#page-23">23</a>
<a href="#section-8.1">8.1</a>. Meaning of NBO ............................................<a href="#page-23">23</a>
<span class="grey">Jonsson, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<a href="#section-8.2">8.2</a>. IP-ID .....................................................<a href="#page-23">23</a>
<a href="#section-8.3">8.3</a>. Extension-3 in UOR-2* Packets .............................<a href="#page-24">24</a>
<a href="#section-8.4">8.4</a>. Multiple Occurrences of the M Bit .........................<a href="#page-24">24</a>
<a href="#section-8.5">8.5</a>. Multiple SN options in one feedback packet ................<a href="#page-24">24</a>
<a href="#section-8.6">8.6</a>. Multiple CRC Options in One Feedback Packet ...............<a href="#page-25">25</a>
<a href="#section-8.7">8.7</a>. Responding to Lost Feedback Links .........................<a href="#page-25">25</a>
<a href="#section-8.8">8.8</a>. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP) ....<a href="#page-25">25</a>
<a href="#section-8.9">8.9</a>. Sequence Number LSB's in IP Extension Headers .............<a href="#page-25">25</a>
<a href="#section-8.10">8.10</a>. Expecting UOR-2 ACKs in O-Mode ...........................<a href="#page-26">26</a>
<a href="#section-8.11">8.11</a>. Context Repairs, TS_STRIDE and TIME_STRIDE ...............<a href="#page-26">26</a>
<a href="#section-9">9</a>. ROHC Negotiation ...............................................<a href="#page-27">27</a>
<a href="#section-10">10</a>. PROFILES Sub-option in ROHC-over-PPP ..........................<a href="#page-27">27</a>
<a href="#section-11">11</a>. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles ......<a href="#page-27">27</a>
<a href="#section-12">12</a>. Security Considerations .......................................<a href="#page-28">28</a>
<a href="#section-13">13</a>. Acknowledgments ...............................................<a href="#page-28">28</a>
<a href="#section-14">14</a>. References ....................................................<a href="#page-28">28</a>
<a href="#section-14.1">14.1</a>. Normative References .....................................<a href="#page-28">28</a>
<a href="#section-14.2">14.2</a>. Informative References ...................................<a href="#page-29">29</a>
<a href="#appendix-A">Appendix A</a>. Sample CRC Algorithm ..................................<a href="#page-30">30</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction and Terminology</span>
<a href="./rfc3095">RFC 3095</a> [<a href="#ref-1" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">1</a>] defines the RObust Header Compression (ROHC) framework
and profiles for IP (Internet Protocol) [<a href="#ref-8" title=""Internet Protocol"">8</a>][9], UDP (User Datagram
Protocol) [<a href="#ref-10" title=""User Datagram Protocol"">10</a>], RTP (Real-Time Transport Protocol) [<a href="#ref-11" title=""RTP: A Transport Protocol for Real-Time Applications"">11</a>], and ESP
(Encapsulating Security Payload) [<a href="#ref-12" title=""IP Encapsulating Security Payload (ESP)"">12</a>]. During implementation and
interoperability testing of <a href="./rfc3095">RFC 3095</a>, some ambiguities and common
misinterpretations have been identified, as well as a few errors.
This document summarizes identified issues and provides corrections
needed for implementations of <a href="./rfc3095">RFC 3095</a> to interoperate, i.e., it
constitutes an update to <a href="./rfc3095">RFC 3095</a>. This document also provides other
clarifications related to common misinterpretations of the
specification. References to <a href="./rfc3095">RFC 3095</a> should, therefore, also
include this document.
In addition, some clarifications and corrections are also provided
for <a href="./rfc3241">RFC 3241</a> (ROHC over PPP) [<a href="#ref-2" title=""Robust Header Compression (ROHC) over PPP"">2</a>], <a href="./rfc3843">RFC 3843</a> (ROHC IP-only profile)
[<a href="#ref-4" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">4</a>], and <a href="./rfc4019">RFC 4019</a> (ROHC UDP-Lite profiles) [<a href="#ref-5" title=""RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite"">5</a>], which are thus also
updated by this document. Furthermore, <a href="./rfc4362">RFC 4362</a> (ROHC Link-Layer
Assisted Profile) [<a href="#ref-7" title=""RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP"">7</a>] is implicitly updated by this document, since
<a href="./rfc4362">RFC 4362</a> is also based on <a href="./rfc3095">RFC 3095</a>.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-6" title=""Key words for use in RFCs to Indicate Requirement Levels"">6</a>].
<span class="grey">Jonsson, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
When a section of this document makes formal corrections, additions
or invalidations to text in <a href="./rfc3095">RFC 3095</a>, this is clearly summarized.
The text from <a href="./rfc3095">RFC 3095</a> that is being addressed is given and labeled
"INCOMPLETE", "INCORRECT", or "INCORRECT AND INVALIDATED", followed
by the correct text labeled "CORRECTED", where applicable. When text
is added that does not simply correct text in previous
specifications, it is given with the label "FORMAL ADDITION".
In this document, a reference to a section in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-1" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">1</a>] is written
as <a href="./rfc3095">RFC 3095</a>-Section <number>.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. CRC Calculation and Coverage</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. CRC Calculation</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.9">Section 5.9</a> defines polynomials for 3-, 7-, and 8-bit Cyclic
Redundancy Checks (CRCs), but it does not specify what algorithm is
used. The 3-, 7- and 8-bit CRCs are calculated using the CRC
algorithm defined in [<a href="#ref-3" title=""PPP in HDLC-like Framing"">3</a>].
A Perl implementation of the algorithm can be found in <a href="#appendix-A">Appendix A</a> of
this document.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Padding Octet and CRC Calculations</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.9.1">Section 5.9.1</a> 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.
INCOMPLETE <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.9.1">Section 5.9.1</a>):
"The CRC in the IR and IR-DYN packet is calculated over the entire
IR or IR-DYN packet, excluding Payload and including CID or any
Add-CID octet."
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."
<span class="grey">Jonsson, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. CRC Coverage in CRC Feedback Options</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.6.3">Section 5.7.6.3</a> is incomplete, as it does not mention how
the "size" field is handled when calculating the 8-bit CRC used in
the CRC feedback option. Since the "size" field is an extension of
the "code" field, it must be treated in the same way.
INCOMPLETE <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.6.3">Section 5.7.6.3</a>):
"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 <a href="#section-5.9.1">section 5.9.1</a>."
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 <a href="#section-5.9.1">Section 5.9.1</a>."
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. CRC Coverage of the ESP NULL Header</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.7">Section 5.8.7</a> gives the CRC coverage of the ESP NULL [<a href="#ref-13" title=""The NULL Encryption Algorithm and Its Use With IPsec"">13</a>]
header as "Entire ESP header". This must be interpreted as including
only the initial part of the header (i.e., Security Parameter Index
(SPI) and sequence number), and not the trailer part at the end of
the payload. Therefore, the ESP NULL header has the same CRC
coverage as the ESP header used in the ESP profile (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.7.7">Section</a>
<a href="#section-5.7.7.7">5.7.7.7</a>).
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Mode Transition</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Feedback During Mode Transition to U- and O-Mode</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.6.1">Section 5.6.1</a> states that during mode transitions, while the
D_TRANS parameter is I, the decompressor sends feedback for each
received packet. This restrictive behavior prevents the decompressor
from using a sparse feedback algorithm during mode transitions.
To reduce transmission overhead and computational complexity
(including CRC calculation) associated with feedback packets sent for
each decompressed packet during mode transition, a decompressor MAY
be implemented with slightly modified mode transition procedures
compared to those defined in [<a href="#ref-1" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">1</a>], as described in this section.
These enhanced procedures should be considered only as a possible
improvement to a decompressor implementation, since interoperability
is not affected in any way. A decompressor implemented according to
<span class="grey">Jonsson, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
the optimized procedures will interoperate with an <a href="./rfc3095">RFC 3095</a>
compressor, as well as a decompressor implemented according to the
procedures described in <a href="./rfc3095">RFC 3095</a>.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Mode Transition Procedures Allowing Sparse Feedback</span>
The purpose of these enhanced transition procedures is to allow the
decompressor to sparsely send feedback for packets decompressed
during the second half of the transition procedure, i.e., after an
appropriate IR/IR-DYN/UOR-2 packet has been received from the
compressor. This is achieved by allowing the decompressor transition
parameter (D_TRANS) to be set to P (Pending) at that stage, as shown
in the transition diagrams of Sections <a href="#section-3.1.2">3.1.2</a> and <a href="#section-3.1.3">3.1.3</a> below.
This enhanced transition, where feedback need not be sent for every
decompressed packet, does however introduce some considerations in
case feedback messages would be lost. Specifically, there is a risk
for a deadlock situation when a transition from R-mode is performed;
if no feedback message successfully reaches the compressor, the
transition is never completed. 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, as well as when in a Pending transition state.
This is equivalent to enhancing the definition of the D_TRANS
parameter in <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.6.1">Section 5.6.1</a>, to include the definition of a
Pending state:
- D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING, and (D)ONE. D_TRANS MUST be initialized to D, and a
mode transition can be initiated only when D_TRANS is D. While
D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC
option for each packet received. When D_TRANS is set to P, the
decompressor does not have to send a NACK or ACK for each packet
received, but it MUST continue to send feedback with some
periodicity, and all feedback packets sent MUST include the CRC
option. This ensures that all mode transitions will be completed
also in case of feedback losses.
The modifications affect transitions to Optimistic and Unidirectional
modes of operation (i.e., the transitions described in <a href="./rfc3095">RFC 3095</a>-
<a href="#section-5.6.5">Section 5.6.5</a> and <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.6.6">Section 5.6.6</a>) and make those transition
diagrams more consistent with the diagram describing the transition
to R-mode.
<span class="grey">Jonsson, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Transition from Reliable to Optimistic Mode</span>
The enhanced procedure for transition from Reliable to Optimistic
mode is shown below:
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
<span class="grey">Jonsson, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. Transition to Unidirectional Mode</span>
The enhanced procedure for transition to Unidirectional mode is shown
on the following figure:
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN/UOR-2(SN,U) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| | D_MODE= U
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Feedback During Mode Transition</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.6.1">Section 5.6.1</a> 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 CRCs 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 or not to carry out mode
transition actions. 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 <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.6.1">Section 5.6.1</a>):
"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
<span class="grey">Jonsson, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
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 <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.6.1">Section 5.6.1</a>:
"While D_TRANS is I, the decompressor sends a NACK or ACK carrying
a CRC option for each received packet."
However, <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.5.2.2">Section 5.5.2.2</a> 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*.
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.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Packet Decoding During Mode Transition</span>
The purpose of a mode transition is to ensure that the compressor and
the decompressor coherently move from one mode of operation to
another using a three-way handshake. At one point during the mode
transition, the decompressor acknowledges the reception of one (or
more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the
new mode. Packets of type 0 or type 1 that are received up to this
point are decompressed using the old mode, while afterwards they are
decompressed using the new mode. If the enhanced transition
procedures described in <a href="#section-3.1">Section 3.1</a> are used, the setting of the
D_TRANS parameter to P represents this breakpoint. The successful
decompression of a packet of type 0 or type 1 completes the mode
transition.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Timestamp Encoding</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Encoding Used for Compressed TS Bits</span>
RTP Timestamp (TS) values are always encoded using W-LSB encoding,
both when sent scaled and unscaled. When no TS bits are transmitted
in a compressed packet, TS is always scaled. If a compressed packet
carries an Extension 3 and field(Tsc)=0, the compressed packet must
thus always carry unscaled TS bits. For TS values sent in Extension
3, W-LSB encoded values are sent using the self-describing variable-
length format (<a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.6">Section 4.5.6</a>), and this applies to both
scaled and unscaled values.
<span class="grey">Jonsson, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. (De)compression of TS without Transmitted TS Bits</span>
When ROHC RTP operates using its most efficient packet types, apart
from packet type identification and the error detection CRC, only RTP
sequence number (SN) bits are transmitted in RTP compressed headers.
All other fields are then omitted either because they are unchanged
or because they can be reconstructed through a function from the SN
(i.e., by combining the transmitted SN bits with state information
from the context). Fields that can be inferred from the SN are the
IP Identification (IP-ID) and the RTP Timestamp (TS).
IP-ID compression and decompression, both with and without
transmitted IP-ID bits in the compressed header, are well defined in
<a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.5">Section 4.5.5</a> (see <a href="#section-8.2">Section 8.2</a>). For the TS field, however,
<a href="./rfc3095">RFC 3095</a> only defines how to decompress based on actual TS bits in
the compressed header, either scaled or unscaled, but not how to
infer the TS from the SN when there are no TS bits present in the
compressed header.
When no TS bits are received in the compressed header, the scaled TS
value is reconstructed assuming a linear extrapolation from the SN,
i.e., delta_TS = delta_SN * default-slope, where delta_SN and
delta_TS are both signed integers. <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7">Section 5.7</a> defines the
potential values for default-slope.
INCOMPLETE <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7">Section 5.7</a>):
"If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see <a href="#section-4.5.3">section 4.5.3</a>), 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 scaled
TS value is reconstructed assuming a linear extrapolation from
the SN, i.e., delta_TS = delta_SN * default-slope(TS).
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see <a href="#section-4.5.3">Section 4.5.3</a>), and default-slope(TS) = 1.
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE). If a packet with no TS
bits is received with Tsc = 0, the decompressor MUST discard the
packet."
<span class="grey">Jonsson, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
INCORRECT AND INVALIDATED <a href="./rfc3095">RFC 3095</a> TEXT (Section <a href="./rfc3095">RFC 3095</a>-5.5.1.2):
"For example, in a typical case where the string pattern has the
form of non-SN-field = SN * slope + offset, one ACK is enough if
the slope has been previously established by the decompressor
(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 <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7">Section 5.7</a>.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Interpretation Intervals for TS Encoding</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.4">Section 4.5.4</a> defines the interpretation interval, p, for
timer-based compression of the RTP timestamp. However, <a href="./rfc3095">RFC 3095</a>-
<a href="#section-5.7">Section 5.7</a> defines a different interpretation interval, which is
defined as the interpretation interval to use for all TS values. It
is thus unclear which p-value to use, at least for timer-based
compression.
The way this should be interpreted is that the p-value differs
depending on whether or not timer-based compression is enabled.
For timer-based compression (TIME_STRIDE set to a non-zero value),
the interpretation interval is:
p = 2^(k-1) - 1 (as per <a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.4">Section 4.5.4</a>)
Otherwise, the interpretation interval is:
p = 2^(k-2) - 1 (as per <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7">Section 5.7</a>)
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Scaled RTP Timestamp Encoding</span>
This section redefines the algorithm for scaled RTP timestamp
encoding, defined as a 5-step procedure in <a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.3">Section 4.5.3</a>.
Two formal errors have been corrected, as described in sub-sections
4.4.1 and 4.4.2 below, and the whole algorithm has been reworked to
be more concise and to use well-defined terminology. The resulting
text can be found in 4.4.3 below.
<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>. TS_STRIDE for Scaled Timestamp Encoding</span>
<a href="./rfc3095">RFC 3095</a> defines the timestamp stride (TS_STRIDE) as the expected
increase in the timestamp value between two RTP packets with
consecutive sequence numbers. TS_STRIDE is set by the compressor and
<span class="grey">Jonsson, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
explicitly communicated to the decompressor, and it is used as the
scaling factor for scaled TS encoding.
The relation between TS and TS_SCALED, given by the following
equality in <a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.3">Section 4.5.3</a>, defines the mathematical meaning
of TS_STRIDE:
TS = TS_SCALED * TS_STRIDE + TS_OFFSET
TS_SCALED is incompletely written as TS / TS_STRIDE in the
compression step following the above core equality. This formula is
incorrect both because it excludes TS_OFFSET and because it would
prevent a TS_STRIDE value of 0, which is an alternative not excluded
by the definition or by the core equality above. If "/" were a
generally unambiguously defined operation meaning "the integral part
of the result from dividing X by Y", the absence of TS_OFFSET could
be explained, but the formula would still lack a proper output for
TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid
only with the following requirements:
a) "/" means "the integral part of the result from dividing X by Y"
b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0)
<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>. TS Wraparound with Scaled Timestamp Encoding</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.3">Section 4.5.3</a> states in points 4 and 5 that the compressor
is not required to initialize TS_OFFSET at wraparound, but that it is
required to increase the number of bits sent for the scaled TS value
when there is a TS wraparound. The decompressor is also required to
detect and cope with TS wraparound, including updating TS_OFFSET.
This method is not interoperable and not robust. The gain is also
insignificant, as TS wraparound happens very seldomly. Therefore,
the compressor should reinitialize TS_OFFSET upon TS wraparound, by
sending an unscaled TS.
<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>. Algorithm for Scaled Timestamp Encoding</span>
INCORRECT <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.3">Section 4.5.3</a>):
"1. Initialization: The compressor sends to the decompressor the
value of TS_STRIDE and the absolute value of one or several TS
fields. The latter are used by the decompressor to initialize
TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that
TS_OFFSET is the same regardless of which absolute value is
used, as long as the unscaled TS value does not wrap around;
see 4) below.
<span class="grey">Jonsson, et al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
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.
3. Decompression: When receiving the compressed value of
TS_SCALED, the decompressor first derives the value of the
original TS_SCALED. The original RTP TS is then calculated as
TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
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:
"1. Initialization and updating of RTP TS scaling function: The
compressor sends to the decompressor the value of TS_STRIDE
along with an unscaled TS. These are both needed by the
decompressor to initialize TS_OFFSET as hdr(TS) modulo
field(TS_STRIDE). Note that TS_OFFSET is the same for any TS
as long as TS_STRIDE does not change and as long as the
unscaled TS value does not wrap around; see 4) below.
2. Compression: After initialization, the compressor no longer
compresses the unscaled TS values. Instead, it compresses the
scaled values. The compression method can be either W-LSB
encoding or timer-based encoding.
3. Decompression: When receiving a (compressed) TS_SCALED, the
field is first decompressed, and the unscaled RTP TS is then
calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
4. Offset at wraparound: If the value of TS_STRIDE is not equal to
a power of two, wraparound of the unscaled 32-bit TS will
change the value of TS_OFFSET. When this happens, the
compressor SHOULD reinitialize TS_OFFSET by sending unscaled
TS, as in 1 above."
<span class="grey">Jonsson, et al. Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
INCORRECT AND INVALIDATED <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-4.5.3">Section 4.5.3</a>):
The entire point 5, i.e. the entire text starting from "5.
Interpretation interval at wraparound ...", down to and including
the block of text that starts with "Let a be the number of LSBs"
and that ends with "...interpretation interval is b." is incorrect
and is thus invalid.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Recalculating TS_OFFSET</span>
TS can be sent unscaled if the TS value change does not match the
established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
To ensure correct decompression of subsequent packets, the
decompressor MUST therefore always recalculate TS_OFFSET (RTP TS
modulo TS_STRIDE) when a packet with an unscaled TS value is
received.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. TS_STRIDE and the Tsc Flag in Extension 3</span>
The Tsc flag in Extension 3 indicates whether or not TS is scaled.
The value of the Tsc flag thus applies to all TS bits, as well as if
there 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 <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.5">Section 5.7.5</a> incorrectly states that value(TS_STRIDE)
is used for scaled TS.
If TS_STRIDE is present in Extension 3, as indicated by the Tss flag
being set, the compressed header SHOULD carry 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).
INCORRECT <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.5">Section 5.7.5</a>):
"Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to <a href="#section-4.5.3">section</a>
<a href="#section-4.5.3">4.5.3</a>, using value(TS_STRIDE).
Context(Tsc) is always 1. If scaling is not desired, the
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 <a href="#section-4.5.3">Section</a>
<a href="#section-4.5.3">4.5.3</a>, using context(TS_STRIDE).
<span class="grey">Jonsson, et al. Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
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.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. Using Timer-Based Compression</span>
Timer-based compression of the RTP timestamp, as described in <a href="./rfc3095">RFC</a>
<a href="./rfc3095">3095</a>-<a href="#section-4.5.4">Section 4.5.4</a>, may be used to reduce the number of transmitted
timestamp bits (bytes) needed when the timestamp cannot be inferred
from the SN. Timer-based compression is only used for decompression
of compressed headers that contains a TS field; otherwise, when no
timestamp bits are present, the timestamp is linearly inferred from
the SN (see <a href="#section-4.2">Section 4.2</a> of this document).
Whether or not to use timer-based compression is controlled by the
TIME_STRIDE control field, which can be set by either an IR, an IR-
DYN, or a compressed packet with Extension 3. Before timer-based
compression can be used, the decompressor has to inform the
compressor (on a per-channel basis) about its clock resolution by
sending a CLOCK feedback option for any CID on the channel. The
compressor can then initiate timer-based compression by sending (on a
per-context basis) a non-zero TIME_STRIDE to the decompressor. When
the compressor is confident that the decompressor has received the
TIME_STRIDE value, it can switch to timer-based compression.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. List Compression</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. CSRC List Items in RTP Dynamic Chain</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.7.6">Section 5.7.7.6</a> defines the static and dynamic parts of the
RTP header. This section indicates a 'Generic CSRC list' field in
the dynamic chain, which has a variable length (see <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.6">Section</a>
<a href="#section-5.8.6">5.8.6</a>). This field is always at least one octet in size, even if the
list is empty (as opposed to the CSRC list in the uncompressed RTP
header, which is not present when the RTP CC field is set to 0).
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Multiple Occurrences of the CC Field</span>
The static and the dynamic parts of the RTP header are defined in <a href="./rfc3095">RFC</a>
<a href="./rfc3095">3095</a>-<a href="#section-5.7.7.6">Section 5.7.7.6</a>. In the dynamic part, a CC field indicates the
number of CSRC items present in the 'Generic CSRC list'. Another CC
field also appears within the 'Generic CSRC list' (<a href="./rfc3095">RFC 3095</a>-Section
<span class="grey">Jonsson, et al. Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
5.8.6.1), because Encoding Type 0 is always used in the dynamic
chain. Both CC fields have the same meaning: the value of the CC
field determines the number of XI items in the CSRC list for Encoding
Type 0, and it is not used otherwise. Therefore, the following
applies:
FORMAL ADDITION TO <a href="./rfc3095">RFC 3095</a>:
"The first octet in the dynamic part of the RTP header contains a
CC field, as defined in <a href="#section-5.7.7.6">Section 5.7.7.6</a>. 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 <a href="./rfc3095">RFC 3095</a>-5.8.6.1.
The compressor MUST set both occurrences of the CC field to the
same value.
The decompressor MUST use the value of the CC field from the
Encoding Type 0 within the Generic CRSC list, and it MUST thus
ignore the first occurrence of the CC field."
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Bit Masks in List Compression</span>
The insertion and/or removal schemes, described in <a href="./rfc3095">RFC 3095</a>-Sections
5.8.6.2 - 5.8.6.4, use bit masks to indicates insertion or removal
positions within the reference list. The size of the bit mask can be
7 bits or 15 bits.
The compressor MAY use a 7-bit mask, even if the reference list has
more than seven items, provided that changes to the list are only
applied to items within the first seven 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 seven items.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Headers Compressed with List Compression</span>
In <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8">Section 5.8</a>, it states that headers that can be part of
extension header chains "include" AH [<a href="#ref-14" title=""IP Authentication Header"">14</a>], ESP NULL [<a href="#ref-13" title=""The NULL Encryption Algorithm and Its Use With IPsec"">13</a>], minimal
encapsulation (MINE) [<a href="#ref-15" title=""Minimal Encapsulation within IP"">15</a>], GRE [<a href="#ref-16" title=""Generic Routing Encapsulation (GRE)"">16</a>][17], and IPv6 [<a href="#ref-9" title=""Internet Protocol, Version 6 (IPv6) Specification"">9</a>] extensions.
This list of headers that can be compressed is correct, but the word
"include" should not be there, since only the header types listed can
actually be handled. It should further be noted that for the Minimal
Encapsulation (MINE) header, there is no explicit discussion of how
to compress it, as the header is sent either uncompressed or fully
compressed away.
<span class="grey">Jonsson, et al. Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. ESP NULL Header List Compression</span>
Due to the offset of the fields in the trailer part of the ESP
header, a compressor MUST NOT compress packets containing more than
one NULL ESP [<a href="#ref-13" title=""The NULL Encryption Algorithm and Its Use With IPsec"">13</a>] header, unless the second-outermost header is
treated as a regular ESP [<a href="#ref-12" title=""IP Encapsulating Security Payload (ESP)"">12</a>] header and the packets are compressed
using profile 0x0003.
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. Translation Tables and Indexes for IP Extension Headers</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.4">Section 5.8.4</a> describes how list indexes are associated to
list items and how table lists are built for IP extension headers.
The text incorrectly states that one index per type is used, since
the same type can appear several times with different content in one
single chain.
In IP extension header list compression, an index is associated with
each individual extension header of an extension header chain. When
there are multiple non-identical occurrences of the same extension
type (Protocol Number) within a header chain, each MUST be given its
own index.
In the case where there are multiple identical occurrences of the
same extension type, the compressor can associate them to the same
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 even 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
extension headers, and a translation table is maintained for each
list independently of one another.
<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>. Reference List</span>
A list compressed using encoding type 1 (insertion), type 2
(removal), 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).
<span class="grey">Jonsson, et al. Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
While it could seem to be a fair choice to send a type 1 list when
ref_id is an empty list, there is nothing gained in doing so with
respect to using a type 0 list. Sending a type 2 list when ref_id is
an empty list would lead to a failure, while sending a type 3 list
has very little meaning. All these alternatives could be seen as
possible, based on how list compression is specified in <a href="./rfc3095">RFC 3095</a>.
If these alternatives were allowed, a decompressor would become
required to maintain a sliding window of ref_id lists in R-mode, even
for the case where no items are sent in the compressed list, and this
is not a desirable requirement. Using list encoding type 1, type 2,
and type 3 is therefore only allowed for non-empty reference lists.
FORMAL ADDITION TO <a href="./rfc3095">RFC 3095</a>:
"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."
<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>. Compression of AH and GRE Sequence Numbers</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.4.2">Section 5.8.4.2</a> and <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.4.4">Section 5.8.4.4</a> describe how to
compress the Authentication Header (AH) [<a href="#ref-14" title=""IP Authentication Header"">14</a>] and the Generic Routing
Encapsulation (GRE) [<a href="#ref-16" title=""Generic Routing Encapsulation (GRE)"">16</a>][17] 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 <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.4.2">Section 5.8.4.2</a>):
"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."
<span class="grey">Jonsson, et al. Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
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 <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.4.4">Section 5.8.4.4</a>):
"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."
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Updating Properties</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Implicit Updates</span>
A context updating packet that contains compressed sequence number
information may also carry information about other fields; in such
cases, these fields are updated according to the content of the
packet. The updating packet also implicitly updates inferred fields
(e.g., RTP Timestamp) according to the current mode and the
appropriate mapping function of the updated and inferred fields.
An updating packet thus updates the reference values of all header
fields, either explicitly or implicitly, except for the UO-1-ID
packet (see <a href="#section-6.2">Section 6.2</a> of this document). In UO-mode, all packets
are updating packets, while in R-mode, all packets with a CRC are
updating packets.
For example, a UO-0 packet contains the compressed RTP sequence
number (SN). Such a packet also implicitly updates RTP timestamp,
IPv4 ID, and sequence numbers of IP extension headers.
<span class="grey">Jonsson, et al. Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Updating Properties of UO-1*</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.3">Section 5.7.3</a> 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, <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.1">Section 5.8.1</a> 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 <a href="./rfc3095">RFC 3095</a>-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 <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.3">Section 5.7.3</a> are thus incomplete.
INCOMPLETE <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.3">Section 5.7.3</a>):
"Values provided in extensions, except those in other SN, TS, or
IP-ID fields, do not update the context."
CORRECTED TEXT:
"UO-1-ID packets only updates TS, SN, IP-ID, and sequence numbers
of IP extension headers. Other values provided in extensions do
not update the context.
The decompressor MUST update its translation table whenever an
(Index, item) pair is received, as per <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.1">Section 5.8.1</a>,
and this rule applies also to UO-1-ID packets."
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Context Updating Properties for IR Packets</span>
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.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. RTP Padding Field (R-P) in Extension 3</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.5">Section 5.7.5</a> 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.
<span class="grey">Jonsson, et al. Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
INCOMPLETE <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.5">Section 5.7.5</a>):
"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."
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. RTP eXtension bit (X) in dynamic part</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.7.6">Section 5.7.7.6</a> 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 <a href="./rfc3095">RFC 3095</a> TEXT (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.7.6">Section 5.7.7.6</a>):
"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."
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Context management and CID/context Reuse</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Persistence of Decompressor Contexts</span>
As part of the negotiated channel parameters, compressor and
decompressor have, through the MAX_CID parameter, agreed on the
highest context identification (CID) number to be used. By agreeing
on MAX_CID, the decompressor also agrees to provide memory resources
to host at least MAX_CID+1 contexts, and an established context with
a CID within this negotiated space MUST be kept by the decompressor
until either the CID gets reused, or the channel is taken down or
renegotiated.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. CID/Context Reuse</span>
As part of the channel negotiation, the maximal number of active
contexts supported is negotiated between the compressor and the
decompressor through the MAX_CID parameter. The value of MAX_CID can
differ significantly from one link application to another, as well as
the load in terms of the number of packet streams to compress. The
lifetime of a ROHC channel can also vary, from almost permanent to
<span class="grey">Jonsson, et al. Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
rather short-lived. However, in general, it is not expected that
resources will be allocated for more contexts than what can
reasonably be expected to be active concurrently over the link. As a
consequence hereof, context identifiers (CIDs) and context memory are
resources that will have to be reused by the compressor as part of
what can be considered normal operation.
How context resources are reused is left unspecified in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-1" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">1</a>]
and subsequent 3095-based ROHC specifications. This document does
not intend to change that, i.e., ROHC resource management is still
considered an implementation detail. However, reusing a CID and its
allocated memory is not always as simple as initiating a context with
a previously unused CID. Because some profiles can be operating in
various modes where packet formats vary depending on current mode,
care has to be taken to ensure that the old context data will be
completely and safely overwritten, eliminating the risk of undesired
side effects from interactions between old and new context data.
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 reuse can be of two kinds, either reuse
for a new context based on the same profile as the old context, or
for a new context based on a different profile. These cases are
discussed separately in the following two sub-sections.
<span class="h4"><a class="selflink" id="section-7.2.1" href="#section-7.2.1">7.2.1</a>. Reusing a CID/Context with the Same Profile</span>
For multi-mode profiles, such as those defined in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-1" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">1</a>], mode
transitions are performed using a decompressor-initiated handshake
procedure, as defined in <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.6">Section 5.6</a>. When a CID/context is
reused for a new context based on the same profile as the old
context, the current mode of operation SHOULD be inherited from the
old to the new context. Specifically, the compressor SHOULD continue
to operate using the mode of operation of the old context also with
the new context. The reason for this is that there is no reliable
way for the compressor to inform the decompressor that a CID/context
reuse is happening. The decompressor can thus not be expected to
clear the context memory for the CID (see <a href="#section-6.3">Section 6.3</a>), and there is
no way to trigger a safe mode switching (which requires the
decompressor-initiated handshake procedure).
The rule of mode inheritance applies also when the
CONTEXT_REINITIALIZATION signal (<a href="./rfc3095">RFC 3095</a>-<a href="#section-6.3.1">Section 6.3.1</a>) is used to
reinitiate an entire context.
<span class="grey">Jonsson, et al. Standards Track [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h4"><a class="selflink" id="section-7.2.2" href="#section-7.2.2">7.2.2</a>. Reusing a CID/Context with a Different Profile</span>
When a CID is reused for a new context based on a different profile
than the old context, both the compressor and the decompressor MUST
start operation with that context in the initial mode of the profile
(if it is a multi-mode profile). This applies both to IR-initiated
new contexts and profile downgrades with IR-DYN (e.g., the profile
0x0001 -> profile 0x0002 downgrade in <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.11.1">Section 5.11.1</a>).
Type 0 and type 1 packets have different formats in U/O- and R-mode,
and these R-mode packets have no CRC. When initiating a new context
on a reused R-mode CID, there is a risk that the decompressor will
misinterpret compressed packets if the initiating IR packets are
lost.
A CID for a context currently operating in R-mode SHOULD therefore
not be reused for a new context based on a different profile than 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.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Other Protocol Clarifications</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Meaning of NBO</span>
In IPv4 dynamic part (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.7.4">Section 5.7.7.4</a>), if the 'NBO' bit is
set, it means that network byte order is used.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. IP-ID</span>
According to <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7">Section 5.7</a>, IP-ID means the compressed value
of the IPv4 header's 'Identification' field. Compressed packets
contain this compressed value (IP-ID), while IR packets with dynamic
chain and IR-DYN packets transmit the original, uncompressed
Identification field value. The IP-ID field always represents the
Identification value of the innermost IPv4 header whose corresponding
RND flag is not 1.
If RND or RND2 is set to 1, the corresponding IP-ID(s) is (are) sent
as 16-bit uncompressed Identification value(s) at the end of the
compressed base header, according to the IP-ID description (see the
beginning of <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7">Section 5.7</a>). When there is no compressed IP-
ID, i.e., for IPv6 or when all IP Identification information is sent
as is (as indicated by RND/RND2 being set to 1), the decompressor
ignores IP-ID bits sent within compressed base headers.
<span class="grey">Jonsson, et al. Standards Track [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
When RND=RND2=0, IP-ID is compressed, i.e., expressed as an SN offset
and byte-swapped if NBO=0. This is the case also when 16 bits of
IP-ID is sent in Extension 3.
When RND=0 but no IP-ID bits are sent in the compressed header, the
SN offset for IP-ID stays unchanged, meaning that Offset_m equals
Offset_ref, as described in <a href="#section-4.5.5">Section 4.5.5</a>. This is further expressed
in a slightly different way (with the same meaning) in <a href="#section-5.7">Section 5.7</a>,
where it is said that "default-slope(IP-ID offset) = 0", meaning, if
no bits are sent for IP-ID, its SN offset slope defaults to 0.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Extension-3 in UOR-2* Packets</span>
Some flags of the IP header in the extension (e.g., NBO or RND) may
change the interpretation of fields in UOR-2* packets. In such
cases, when a flag changes in Extension 3, a decompressor MUST re-
parse the UOR-2* packet.
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. Multiple Occurrences of the M Bit</span>
The RTP header part of Extension 3, as defined by <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.5">Section</a>
<a href="#section-5.7.5">5.7.5</a>, 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 two occurrences of the field within one
single compressed header. In such cases, the two M fields must have
the same value.
FORMAL ADDITION TO <a href="./rfc3095">RFC 3095</a>:
"When there are two occurrences of the M field in a compressed
header (both in the compressed base header and in the RTP part of
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."
<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>. Multiple SN options in one feedback packet</span>
The length of the sequence number field in the original ESP [<a href="#ref-12" title=""IP Encapsulating Security Payload (ESP)"">12</a>]
header is 32 bits. The format of the SN feedback option (<a href="./rfc3095">RFC 3095</a>-
<a href="#section-5.7.6.6">Section 5.7.6.6</a>) allows for 8 additional SN bits to the 12 SN bits of
the FEEDBACK-2 format (<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.6.1">Section 5.7.6.1</a>). One single SN
feedback option is thus not enough for the 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.
<span class="grey">Jonsson, et al. Standards Track [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-5.7.6.1">Section 5.7.6.1</a> declares that a FEEDBACK-2 packet can
contain a variable number of feedback options, and the options can
appear in any order.
When processing multiple SN options in one feedback packet, the SN
would be given by concatenating the fields.
<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>. Multiple CRC Options in One Feedback Packet</span>
Although it is not useful to have more than one single CRC option in
a feedback packet, having multiple CRC options is still allowed. If
multiple CRC options are included, all such CRC options MUST be
identical, as they will be calculated over the same header; the
compressor MUST otherwise discard the feedback packet.
<span class="h3"><a class="selflink" id="section-8.7" href="#section-8.7">8.7</a>. Responding to Lost Feedback Links</span>
Although this is neither desirable or expected, it may happen that a
link used to carry feedback between two associated instances becomes
unavailable. If the compressor can be notified of such an event, the
compressor SHOULD restart compression for each flow that is operating
in R-mode. When restarting compression, the compressor SHOULD use a
different CID for each flow being restarted; this is useful to avoid
the possibility of misinterpreting the type of the compressed header
for the packet type identifiers that are common to both U/O-mode and
R-mode, when the flow is restarted in U-mode (see also <a href="#section-7.2">Section 7.2</a>).
Generally, feedback links are not expected to disappear once present,
but it should be noted that this might be the case for certain link
technologies.
<span class="h3"><a class="selflink" id="section-8.8" href="#section-8.8">8.8</a>. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP)</span>
One single new format is defined for UOR-2 in profile 0x0002 and
profile 0x0003, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS)
formats from profile 0x0001. The same UOR-2 format is thus used
independent of whether or not there are IP headers with a
corresponding RND=1. This also applies to the IP profile [<a href="#ref-4" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">4</a>] and the
IP/UDP-Lite profile [<a href="#ref-5" title=""RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite"">5</a>].
<span class="h3"><a class="selflink" id="section-8.9" href="#section-8.9">8.9</a>. Sequence Number LSB's in IP Extension Headers</span>
In <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.8.5">Section 5.8.5</a>, formats are defined for compression of IP
extension header fields. These include compressed sequence number
fields, and these fields contain the "LSB of sequence number". These
sequence numbers are not "LSB-encoded" as, e.g., the RTP sequence
number, but are the LSB's of the uncompressed fields.
<span class="grey">Jonsson, et al. Standards Track [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h3"><a class="selflink" id="section-8.10" href="#section-8.10">8.10</a>. Expecting UOR-2 ACKs in O-Mode</span>
Usage of UOR-2 ACKs in O-mode, as discussed in <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.4.1.1.2">Section</a>
<a href="#section-5.4.1.1.2">5.4.1.1.2</a>, 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-2s ACKs for the purpose of adapting the
optimistic approach strategies.
It is thus NOT RECOMMENDED to use the optional ACK mechanism in O-
mode, either in compressor or in decompressor implementations.
Using an incorrect expectation on UOR-2 ACKs as a basis for
compressor behavior will significantly degrade the compression
performance. This is because UOR-2 ACKs can be sent from a
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 <a href="#section-5.4.1.1.2">Section 5.4.1.1.2</a>, it must make
sure to set the k_3 and n_3 parameters to much larger values than 1
to ensure that the compressor performance is not degraded due to the
problem described above.
<span class="h3"><a class="selflink" id="section-8.11" href="#section-8.11">8.11</a>. Context Repairs, TS_STRIDE and TIME_STRIDE</span>
The 7-bit CRC used to verify the outcome of the decompression attempt
covers the original uncompressed header. The CRC verification thus
excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of
the original uncompressed header.
The UOR-2 packet type can be used to update the value of the
TS_STRIDE and/or the TIME_STRIDE, with the Extension 3. However,
these fields are not used for decompression of the RTP TS field for
this packet type and their respective value is thus not verified,
either implicitly or explicitly.
When the compressor receives a negative acknowledgement, it thus
cannot determine whether the failure may be caused by an unsuccessful
update to the TS_STRIDE and/or the TIME_STRIDE field(s), for which a
previous header that last attempted to update their value had
previously been acknowledged.
FORMAL ADDITION TO <a href="./rfc3095">RFC 3095</a>:
"When the compressor receives a NACK and uses the UOR-2 header
type to repair the decompressor context, it SHOULD include fields
that update the value of both the TS_STRIDE and the TIME_STRIDE
whose value it has updated at least once since the establishment
<span class="grey">Jonsson, et al. Standards Track [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
of that context, i.e., since the CID was first associated with
its current profile.
When the compressor receives a static-NACK, it MUST include in
the IR header fields for both the TS_STRIDE and the TIME_STRIDE
whose value it has updated at least once since the establishment
of that context, i.e., since the CID was first associated with
its current profile."
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. ROHC Negotiation</span>
<a href="./rfc3095">RFC 3095</a>-<a href="#section-4.1">Section 4.1</a> states that the link layer must provide means to
negotiate, e.g., the channel parameters listed in <a href="./rfc3095">RFC 3095</a>-<a href="#section-5.1.1">Section</a>
<a href="#section-5.1.1">5.1.1</a>. One of these parameters is the PROFILES parameter, which is a
set of non-negative integers where each integer indicates a profile
supported by the decompressor.
Each profile is identified by a 16-bit value, where the 8 LSB bits
indicate the actual profile, and the 8 MSB bits indicate the variant
of that profile (see <a href="./rfc3095">RFC 3095</a>-<a href="#section-8">Section 8</a>). In the ROHC headers sent
over the link, the profile used is identified only with the 8 LSB
bits, which means that the compressor and decompressor must have
agreed on which variant to use for each profile.
The negotiation protocol must thus be able to communicate to the
compressor the set of profiles supported by the decompressor. When
multiple variants of the same profile are available, the negotiation
protocol must provide the means for the decompressor to know which
variant will be used by the compressor. This basically means that
the PROFILES set after negotiation MUST NOT include more than one
variant of a profile.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. PROFILES Sub-option in ROHC-over-PPP</span>
The logical union of sub-options for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [<a href="#ref-2" title=""Robust Header Compression (ROHC) over PPP"">2</a>], cannot be used for the PROFILES
suboption, as the whole union would then have to be considered within
each of the two IPCP negotiations to avoid getting an ambiguous
profile set. An implementation of <a href="./rfc3241">RFC 3241</a> MUST therefore ensure
that the same profile set is negotiated for both IPv4 and IPv6
(IPCP/IPV6CP).
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles</span>
In the ROHC IP-only profile, <a href="./rfc3843#section-3.3">Section 3.3 of RFC 3843</a> [<a href="#ref-4" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">4</a>], a mechanism
for encoding of a constant Identification value in IPv4 (constant
IP-ID) is defined. This mechanism is also used by the ROHC UDP-Lite
profiles, <a href="./rfc4019">RFC 4019</a> [<a href="#ref-5" title=""RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite"">5</a>].
<span class="grey">Jonsson, et al. Standards Track [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
The "Constant IP-ID" mechanism applies to both the inner and outer IP
header, when present, meaning that there will be both a SID and a
SID2 context value.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Security Considerations</span>
This document provides a number of corrections and clarifications to
[<a href="#ref-1" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">1</a>], but it does not make any changes with regard to the security
aspects of the protocol. As a consequence, the security
considerations of [<a href="#ref-1" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">1</a>] apply without additions.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Acknowledgments</span>
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann,
Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy
Lundemo, Alan Kennington, Remi Pelland, Lajos Zaccomer, Endre Szalai,
Mark Kalmanczhelyi, and Arpad Szakacs for their contributions and
comments. Thanks also to the committed document reviewers, Carl
Knutsson and Biplab Sarkar, who reviewed the document during working
group last-call.
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. References</span>
<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
<a href="./rfc3095">RFC 3095</a>, July 2001.
[<a id="ref-2">2</a>] Bormann, C., "Robust Header Compression (ROHC) over PPP", <a href="./rfc3241">RFC</a>
<a href="./rfc3241">3241</a>, April 2002.
[<a id="ref-3">3</a>] Simpson, W., "PPP in HDLC-like Framing", STD 51, <a href="./rfc1662">RFC 1662</a>, July
1994.
[<a id="ref-4">4</a>] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", <a href="./rfc3843">RFC 3843</a>, June 2004.
[<a id="ref-5">5</a>] Pelletier, G., "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", <a href="./rfc4019">RFC 4019</a>, April 2005.
[<a id="ref-6">6</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Jonsson, et al. Standards Track [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>. Informative References</span>
[<a id="ref-7">7</a>] Jonsson, L-E., Pelletier, G., and K. Sandlund, "RObust Header
Compression (ROHC): A Link-Layer Assisted Profile for
IP/UDP/RTP", <a href="./rfc4362">RFC 4362</a>, January 2006.
[<a id="ref-8">8</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>, September 1981.
[<a id="ref-9">9</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-10">10</a>] Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>, August
1980.
[<a id="ref-11">11</a>] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
<a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-12">12</a>] Kent, S., "IP Encapsulating Security Payload (ESP)", <a href="./rfc4303">RFC 4303</a>,
December 2005.
[<a id="ref-13">13</a>] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", <a href="./rfc2410">RFC 2410</a>, November 1998.
[<a id="ref-14">14</a>] Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>, December 2005.
[<a id="ref-15">15</a>] Perkins, C., "Minimal Encapsulation within IP", <a href="./rfc2004">RFC 2004</a>,
October 1996.
[<a id="ref-16">16</a>] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", <a href="./rfc2784">RFC 2784</a>, March 2000.
[<a id="ref-17">17</a>] Dommety, G., "Key and Sequence Number Extensions to GRE", <a href="./rfc2890">RFC</a>
<a href="./rfc2890">2890</a>, September 2000.
<span class="grey">Jonsson, et al. Standards Track [Page 29]</span><span id="page-30" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Sample CRC Algorithm</span>
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann [email protected] 2001-08-02
#
# This little demo shows the four types of CRCs in use in <a href="./rfc3095">RFC 3095</a>,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
<span class="grey">Jonsson, et al. Standards Track [Page 30]</span><span id="page-31" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies that this is complemented like for PPP
# (this differs from 8-, 7-, and 3-bit CRCs)
#
# C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);
<span class="grey">Jonsson, et al. Standards Track [Page 31]</span><span id="page-32" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
Authors' Addresses
Lars-Erik Jonsson
Optand 737
SE-831 92 Ostersund, Sweden
Phone: +46 70 365 20 58
EMail: [email protected]
Kristofer Sandlund
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58
EMail: [email protected]
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
EMail: [email protected]
Peter Kremer
Conformance and Software Test Laboratory
Ericsson Hungary
H-1300 Bp. 3., P.O. Box 107, HUNGARY
Phone: +36 1 437 7033
EMail: [email protected]
<span class="grey">Jonsson, et al. Standards Track [Page 32]</span><span id="page-33" ></span>
<span class="grey"><a href="./rfc4815">RFC 4815</a> Corrections and Clarifications to <a href="./rfc3095">RFC 3095</a> February 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jonsson, et al. Standards Track [Page 33]
Annotations
Select text to annotate