< draft-ietf-rohc-rtp-impl-guide-21.txt   draft-ietf-rohc-rtp-impl-guide-22.txt >
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT K. Sandlund INTERNET-DRAFT K. Sandlund
TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362 G. Pelletier TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362 G. Pelletier
Expires: April 2007 P. Kremer Expires: May 2007 P. Kremer
Ericsson Ericsson
October 13, 2006 November 6, 2006
RObust Header Compression (ROHC): RObust Header Compression (ROHC):
Corrections and Clarifications to RFC 3095 Corrections and Clarifications to RFC 3095
<draft-ietf-rohc-rtp-impl-guide-21.txt> <draft-ietf-rohc-rtp-impl-guide-22.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
of Section 3 of BCP 78.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 1, line 45 skipping to change at page 1, line 42
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. Some parts of the specification profiles for IP (Internet Protocol), UDP (User Datagram Protocol),
are unclear or contain errors that may lead to misinterpretations RTP (Real-Time Transport Protocol), and ESP (Encapsulated Security
that may impair interoperability between different implementations. Payload). Some parts of the specification are unclear or contain
This document provides corrections, additions and clarifications to errors that may lead to misinterpretations that may impair
RFC 3095; this document thus updates RFC 3095. In addition, other interoperability between different implementations. This document
clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP provides corrections, additions and clarifications to RFC 3095; this
profile) and RFC 4109 (ROHC UPD-Lite profiles) are also provided. 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.
Table of Contents Table of Contents
1. Introduction and terminology.....................................3 1. Introduction and terminology.....................................3
2. CRC calculation and coverage.....................................4 2. CRC calculation and coverage.....................................4
2.1. CRC calculation.............................................4 2.1. CRC calculation.............................................4
2.2. Padding octet and CRC calculations..........................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.........................5 2.4. CRC coverage of the ESP NULL header.........................5
3. Mode transition..................................................5 3. Mode transition..................................................5
skipping to change at page 3, line 26 skipping to change at page 3, line 26
14. Acknowledgment.................................................25 14. Acknowledgment.................................................25
15. References.....................................................26 15. References.....................................................26
15.1. Normative References......................................26 15.1. Normative References......................................26
15.2. Informative References....................................26 15.2. Informative References....................................26
16. Authors' Addresses.............................................27 16. Authors' Addresses.............................................27
Appendix A - Sample CRC algorithm..................................28 Appendix A - Sample CRC algorithm..................................28
1. Introduction and terminology 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 [8][9], UDP [10], RTP [11], and ESP [12]. During and profiles for IP (Internet Protocol) [8][9], UDP (User Datagram
implementation and interoperability testing of RFC 3095 some Protocol) [10], RTP (Real-Time Transport Protocol) [11], and ESP
ambiguities and common misinterpretations have been identified, as (Encapsulated Security Payload) [12]. During implementation and
well as a few errors. interoperability testing of RFC 3095 some ambiguities and common
misinterpretations have been identified, as well as a few errors.
This document summarizes identified issues and provides corrections This document summarizes identified issues and provides corrections
needed for implementations of RFC 3095 to interoperate, i.e. it needed for implementations of RFC 3095 to interoperate, i.e. it
constitutes an update to RFC 3095. This document also provides other constitutes an update to RFC 3095. This document also provides other
clarifications related to common misinterpretations of the clarifications related to common misinterpretations of the
specification. When referring to RFC 3095, this document should specification. References to RFC 3095 should therefore also include
therefore also be referenced. this document.
In addition, some clarifications and corrections are also provided In addition, some clarifications and corrections are also provided
for RFC 3241 [2] (ROHC over PPP), RFC 3843 [4] (ROHC IP-only for RFC 3241 (ROHC over PPP) [2], RFC 3843 (ROHC IP-only profile)
profile), and RFC 4019 [5] (ROHC UDP-Lite profiles), which are thus [4], and RFC 4019 (ROHC UDP-Lite profiles) [5], which are thus also
also updated by this document. Furthermore, RFC 4362 [7] (ROHC Link- updated by this document. Furthermore, RFC 4362 (ROHC Link-Layer
Layer Assisted Profile) is implicitly updated by this document, since Assisted Profile) [7] is implicitly updated by this document, since
also RFC 4362 is based on RFC 3095. 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 [6]. document are to be interpreted as described in RFC 2119 [6].
When a section of this document makes formal corrections, additions When a section of this document makes formal corrections, additions
or invalidations to text in RFC 3095, this is clearly summarized. The or invalidations to text in RFC 3095, this is clearly summarized. The
text from RFC 3095 that is being addressed is given and labeled text from RFC 3095 that is being addressed is given and labeled
"INCOMPLETE", "INCORRECT" or "INCORRECT AND INVALIDATED", followed by "INCOMPLETE", "INCORRECT" or "INCORRECT AND INVALIDATED", followed by
the correct text labeled "CORRECTED", where applicable. When a formal the correct text labeled "CORRECTED", where applicable. When text is
addition is provided, it is given with the label "FORMAL ADDITION". 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 RFC 3095 [1] is written In this document, a reference to a section in RFC 3095 [1] is written
as a prefixed section reference, RFC3095-<section number>. as a prefixed section reference, RFC3095-<section number>.
2. CRC calculation and coverage 2. CRC calculation and coverage
2.1. CRC calculation 2.1. CRC calculation
Section RFC3095-5.9 defines polynomials for 3, 7 and 8-bit CRCs, but Section RFC3095-5.9 defines polynomials for 3, 7 and 8-bit CRCs, but
it does not specify what algorithm is used. The 3, 7 and 8-bit CRCs it does not specify what algorithm is used. The 3, 7 and 8-bit CRCs
skipping to change at page 4, line 43 skipping to change at page 4, line 45
CORRECTED TEXT: CORRECTED TEXT:
"The CRC in the IR and IR-DYN packet is calculated over the entire "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 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." 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 RFC3095-5.7.6.3 is incomplete, as it does not mention how the Section RFC3095-5.7.6.3 is incomplete, as it does not mention how the
"size" field is handled when calculating the 8-bit CRC used in the "size" field is handled when calculating the 8-bit CRC used in the
CRC feedback option. Since the "size" field can be considered an CRC feedback option. Since the "size" field is an extension of the
extension of the "code" field, it must be treated in the same way. "code" field, it must be treated in the same way.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.6.3): INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.6.3):
"The CRC option contains an 8-bit CRC computed over the entire "The CRC option contains an 8-bit CRC computed over the entire
feedback payload, without the packet type and code octet, but feedback payload, without the packet type and code octet, but
including any CID fields, using the polynomial of section 5.9.1." including any CID fields, using the polynomial of section 5.9.1."
CORRECTED TEXT: CORRECTED TEXT:
"The CRC option contains an 8-bit CRC computed over the entire "The CRC option contains an 8-bit CRC computed over the entire
skipping to change at page 5, line 37 skipping to change at page 5, line 41
(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], as described in this section. compared to those defined in [1], as described in this section.
These enhanced procedures should be considered only as a possible These enhanced procedures should be considered only as a possible
improvement to a decompressor implementation, since interoperability improvement to a decompressor implementation, since interoperability
is not affected in any way. A decompressor implemented according to is not affected in any way. A decompressor implemented according to
the optimized procedures will 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 does. procedures described in RFC3095.
3.1.1. Mode transition procedures allowing sparse feedback 3.1.1. Mode transition procedures allowing sparse feedback
The purpose of these enhanced transition procedures is to allow the The purpose of these enhanced transition procedures is to allow the
decompressor to sparsely send feedback for packets decompressed decompressor to sparsely send feedback for packets decompressed
during the second half of the transition procedure, i.e. after an during the second half of the transition procedure, i.e. after an
appropriate IR/IR-DYN/UOR-2 packet has been received from the appropriate IR/IR-DYN/UOR-2 packet has been received from the
compressor. This is achieved by allowing the decompressor transition compressor. This is achieved 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, as shown
in the transition diagrams of sections 3.1.2 and 3.1.3 below. in the transition diagrams of sections 3.1.2 and 3.1.3 below.
This enhanced transition, where feedback need not be sent for every This enhanced transition, where feedback need not be sent for every
decompressed packet, does however introduce some considerations in decompressed packet, does however introduce some considerations in
case feedback messages would be lost. Specifically, there is a risk case feedback messages would be lost. Specifically, there is a risk
for a deadlock situation when a transition from R-mode is performed for a deadlock situation when a transition from R-mode is performed,
in case no feedback message successfully reaches the compressor and if no feedback message successfully reaches the compressor the
the transition is not complete. For transition between U-mode and O- transition is never completed. For transition between U-mode and O-
mode, there is also a small risk for reduced compression efficiency. mode, there is also a small risk for reduced compression efficiency.
To avoid this, the decompressor MUST continue to send feedback at To avoid this, the decompressor MUST continue to send feedback at
least periodically, also when in Pending transition state. This is least periodically, also when in Pending transition state. This is
equivalent to enhancing the definition of the D_TRANS parameter in equivalent to enhancing the definition of the D_TRANS parameter in
section RFC3095-5.6.1, to include the definition of a Pending state: section RFC3095-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 with some received, but it MUST continue to send feedback with some
periodicity, and all feedback packets sent MUST include the CRC periodicity, and all feedback packets sent MUST include the CRC
option. This ensures that all mode transitions will be completed option. This ensures that all mode transitions will be completed
also in case of feedback losses. also in case of feedback losses.
These modifications affect transitions to Optimistic and The modifications affect transitions to Optimistic and Unidirectional
Unidirectional modes of operation, i.e. the transitions described in modes of operation, i.e. the transitions described in sections
sections RFC3095-5.6.5 and RFC3095-5.6.6, and make those transition RFC3095-5.6.5 and RFC3095-5.6.6, and make those transition diagrams
diagrams more consistent with the diagram describing the transition more consistent with the diagram describing the transition to R-mode.
to R-mode.
3.1.2. Transition from Reliable to Optimistic 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
skipping to change at page 8, line 51 skipping to change at page 8, line 51
both when sent scaled and when sent unscaled. When no TS bits are both when sent scaled and when sent unscaled. When no TS bits are
transmitted in a compressed packet, TS is always scaled. If a transmitted in a compressed packet, TS is always scaled. If a
compressed packet carries an extension 3 and field(Tsc)=0, the compressed packet carries an extension 3 and field(Tsc)=0, the
compressed packet must thus always carry unscaled TS bits. For TS compressed packet must thus always carry unscaled TS bits. For TS
values sent in Extension 3, W-LSB encoded values are sent using the values sent in Extension 3, W-LSB encoded values are sent using the
self-describing variable-length format (section RFC3095-4.5.6), and self-describing variable-length format (section RFC3095-4.5.6), and
this applies to both scaled and unscaled values. this applies to both scaled and unscaled values.
4.2. (De)compression of TS without transmitted TS bits 4.2. (De)compression of TS without transmitted TS bits
When ROHC RTP operate using its most efficient packet types, apart When ROHC RTP operates using its most efficient packet types, apart
from packet type identification and the error detection CRC, only RTP from packet type identification and the error detection CRC, only RTP
sequence number (SN) bits have to be transmitted in RTP compressed sequence number (SN) bits are transmitted in RTP compressed headers.
headers. All other fields are then omitted either because they are All other fields are then omitted either because they are unchanged
unchanged or because they can be reconstructed through a function or because they can be reconstructed through a function from the SN
from the SN (i.e. by combining the transmitted SN bits with state (i.e. by combining the transmitted SN bits with state information
information from the context). Fields that can be inferred from the from the context). Fields that can be inferred from the SN are the IP
SN are the IP Identification (IP-ID) and the RTP Timestamp (TS). Identification (IP-ID) and the RTP Timestamp (TS).
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 RFC3095-4.5.5 (see section 8.2). However, for TS it is only section RFC3095-4.5.5 (see section 8.2). For the TS field, however,
defined how to decompress based on actual TS bits in the compressed RFC 3095 only defines how to decompress based on actual TS bits in
header, either scaled or unscaled, but not how to infer the TS from the compressed header, either scaled or unscaled, but not how to
the SN. This section specifies how the scaled TS is decompressed when infer the TS from the SN when there are no TS bits present in the
no TS bits are received in the compressed header. compressed header.
When no TS bits are received in the compressed header, the scaled TS When no TS bits are received in the compressed header, the scaled TS
value is reconstructed assuming a linear extrapolation from the SN, value is reconstructed assuming a linear extrapolation from the SN,
i.e. delta_TS = delta_SN * default-slope, where delta_SN and delta_TS i.e. delta_TS = delta_SN * default-slope, where delta_SN and delta_TS
are both signed integers. Section RFC3095-5.7 defines the potential are both signed integers. Section RFC3095-5.7 defines the potential
values for default-slope. values for default-slope.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7): INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7):
"If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before "If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
skipping to change at page 10, line 46 skipping to change at page 10, line 46
consecutive sequence numbers. TS_STRIDE is set by the compressor and consecutive sequence numbers. TS_STRIDE is set by the compressor and
explicitly communicated to the decompressor, and it is used as the explicitly communicated to the decompressor, and it is used as the
scaling factor for scaled TS encoding. scaling factor for scaled TS encoding.
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 RFC3095-4.5.3, defines the mathematical meaning equality in section RFC3095-4.5.3, defines the mathematical meaning
of TS_STRIDE: of TS_STRIDE:
TS = TS_SCALED * TS_STRIDE + TS_OFFSET TS = TS_SCALED * TS_STRIDE + TS_OFFSET
TS_SCALED is incorrectly written as TS / TS_STRIDE in the compression TS_SCALED is incompletely written as TS / TS_STRIDE in the
step following the above core equality. This formula is incorrect compression step following the above core equality. This formula is
both because it excludes TS_OFFSET and because it would prevent a incorrect both because it excludes TS_OFFSET and because it would
TS_STRIDE value of 0, which is an alternative not excluded by the prevent a TS_STRIDE value of 0, which is an alternative not excluded
definition or by the core equality above. If "/" were a generally by the definition or by the core equality above. If "/" were a
unambiguously defined operation meaning "the integral part of the generally unambiguously defined operation meaning "the integral part
result from dividing X by Y", the absence of TS_OFFSET could be of the result from dividing X by Y", the absence of TS_OFFSET could
explained, but the formula would still lack a proper output for be explained, but the formula would still lack a proper output for
TS_STRIDE equal to 0. The formula of "2. Compression" is thus TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid
invalid. 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)
4.4.2. TS wraparound with scaled timestamp encoding 4.4.2. TS wraparound with scaled timestamp encoding
Section RFC3095-4.5.3 states in point 4 and 5 that the compressor is Section RFC3095-4.5.3 states in point 4 and 5 that the compressor is
not required to initialize TS_OFFSET at wraparound, but that it 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 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 when there is a TS wraparound. The decompressor is also required to
detect and cope with TS wraparound, including updating TS_OFFSET. detect and cope with TS wraparound, including updating TS_OFFSET.
This method is not interoperable and not robust. The gain is also This method is not interoperable and not robust. The gain is also
insignificant, as TS wraparound happens very seldom. Therefore, the insignificant, as TS wraparound happens very seldom. Therefore, the
compressor reinitializes TS_OFFSET upon TS wraparound, by sending compressor should reinitialize TS_OFFSET upon TS wraparound, by
unscaled TS. sending unscaled TS.
4.4.3. Algorithm for scaled timestamp encoding 4.4.3. Algorithm for scaled timestamp encoding
INCORRECT RFC 3095 TEXT (section RFC3095-4.5.3): INCORRECT RFC 3095 TEXT (section RFC3095-4.5.3):
"1. Initialization: The compressor sends to the decompressor the "1. Initialization: The compressor sends to the decompressor the
value of TS_STRIDE and the absolute value of one or several TS value of TS_STRIDE and the absolute value of one or several TS
fields. The latter are used by the decompressor to initialize fields. The latter are used by the decompressor to initialize
TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that
TS_OFFSET is the same regardless of which absolute value is TS_OFFSET is the same regardless of which absolute value is
skipping to change at page 13, line 53 skipping to change at page 13, line 53
timestamp bits are present the timestamp is linearly inferred from timestamp bits are present the timestamp is linearly inferred from
the SN (see section 4.2 of this document). the SN (see 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. Before timer-based DYN, or by a compressed packet with extension 3. Before timer-based
compression can be used, the decompressor has to inform the compression can be used, the decompressor has to inform the
compressor (on a per-channel basis) about its clock resolution by compressor (on a per-channel basis) about its clock resolution by
sending a CLOCK feedback option for any CID on the channel. The sending a CLOCK feedback option for any CID on the channel. The
compressor can then initiate timer-based compression by sending (on a compressor can then initiate timer-based compression by sending (on a
per-context basis) a non-zero TIME_STRIDE to the decompressor. First per-context basis) a non-zero TIME_STRIDE to the decompressor. When
when the compressor is confident that the decompressor has received the compressor is confident that the decompressor has received the
the TIME_STRIDE value, it can switch to timer-based compression. TIME_STRIDE value, it can switch to timer-based compression.
5. List compression 5. List compression
5.1. CSRC list items in RTP dynamic chain 5.1. CSRC list items in RTP dynamic chain
Section RFC3095-5.7.7.6 defines the static and dynamic parts of the Section RFC3095-5.7.7.6 defines the static and dynamic parts of the
RTP header. This section indicates a 'Generic CSRC list' field in the RTP header. This section indicates a 'Generic CSRC list' field in the
dynamic chain, which has a variable length (see section RFC3095- dynamic chain, which has a variable length (see section RFC3095-
5.8.6). This field is always at least one octet in size, even if the 5.8.6). 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 list is empty (as opposed to the CSRC list in the uncompressed RTP
skipping to change at page 15, line 51 skipping to change at page 15, line 51
own index. own index.
In the case where there are multiple identical occurrences of the In the case where there are multiple identical occurrences of the
same extension type, the compressor can associate them to the same 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 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 the list is updated, the compressor MUST send the value for each
occurrence of that index in the list. occurrence of that index in the list.
When content of extension headers changes, an implementation can When content of extension headers changes, an implementation can
choose to either use a different index, or update the existing one. choose to either use a different index, or update the existing one.
Some extensions can be compressed away also when some fields change, Some extensions can be compressed away even when some fields change,
as those changes can be conveyed to the decompressor implicitly (e.g. as those changes can be conveyed to the decompressor implicitly (e.g.
sequence numbers in extension headers that can be inferred from the 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)' RTP SN) or explicitly (e.g. as part of the 'IP extension header(s)'
field in extension 3). 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.7. Reference list 5.7. Reference list
skipping to change at page 17, line 42 skipping to change at page 17, line 42
when the offset from the sequence number (SN) of the compressed when the offset from the sequence number (SN) of the compressed
header is constant, when the compressor has confidence that the header is constant, when the compressor has confidence that the
decompressor has established the correct offset." 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 cases, 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, except for the UO-1-ID
UO-1-ID packet (see section 6.2 of this document). In UO-mode, all packet (see section 6.2 of this document). 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*
Section RFC3095-5.7.3 states that the values provided in extensions Section RFC3095-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, carried by a UO-1-ID packet do not update the context, except for SN,
TS, or IP-ID fields. However, section RFC3095-5.8.1 correctly states TS, or IP-ID fields. However, section RFC3095-5.8.1 correctly states
skipping to change at page 20, line 8 skipping to change at page 20, line 8
differ significantly from one link application to another, as well as differ significantly from one link application to another, as well as
the load in terms of the number of packet streams to compress. The 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 lifetime of a ROHC channel can also vary, from almost permanent to
rather short-lived. However, in general it is not expected that rather short-lived. However, in general it is not expected that
resources will be allocated for more contexts than what can resources will be allocated for more contexts than what can
reasonably be expected to be active concurrently over the link. As a reasonably be expected to be active concurrently over the link. As a
consequence hereof, context identifiers (CIDs) and context memory are consequence hereof, context identifiers (CIDs) and context memory are
resources that will have to be re-used by the compressor as part of resources that will have to be re-used by the compressor 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 left unspecified in RFC 3095 [1]
ROHC standards left unspecified and up to implementation. This and subsequent 3095-based ROHC specifications. This document does not
document does not intends to change that, i.e. ROHC resource intends to change that, i.e. ROHC resource management is still
management is still considered an implementation detail. However, re- considered an implementation detail. However, re-using a CID and its
using a CID and its allocated memory is not always as simple as allocated memory is not always as simple as initiating a context with
initiating a context with a previously unused CID. Because some a previously unused CID. Because some profiles can be operating in
profiles can be operating in various modes where packet formats vary various modes where packet formats vary depending on current mode,
depending on current mode, care has to be taken to ensure that the care has to be taken to ensure that the old context data will be
old context data will be completely and safely overwritten, completely and safely overwritten, eliminating the risk of undesired
eliminating the risk of undesired side effects from interactions side effects from interactions between old and new context data. This
between old and new context data. This document therefore points out document therefore points out some important core aspects to consider
some important core aspects to consider when implementing resource when implementing resource management in ROHC compressors and
management in ROHC compressors and decompressors. 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], mode For multi-mode profiles, such as those defined in RFC 3095 [1], mode
transitions are performed using a decompressor-initiated handshake transitions are performed using a decompressor-initiated handshake
skipping to change at page 22, line 53 skipping to change at page 22, line 53
When processing multiple SN options in one feedback packet, the SN When processing multiple SN options in one feedback packet, the 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 not useful to have more than one single CRC option in 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 a feedback packet, having multiple CRC options is still allowed. If
multiple CRC options are included, all such CRC options MUST be multiple CRC options are included, all such CRC options MUST be
identical, as they will be calculated over the same header, the identical, as they will be calculated over the same header, the
compressor SHOULD otherwise discard the feedback packet. compressor MUST otherwise discard the feedback packet.
8.7. Responding to lost feedback links 8.7. Responding to lost feedback links
Although 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 becomes 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
compressor SHOULD restart compression for each flow that is operating compressor SHOULD restart compression for each flow that is operating
in R-mode. When restarting compression, the compressor SHOULD use a in R-mode. When restarting compression, the compressor SHOULD use a
different CID for each flow being restarted; this is useful to avoid different CID for each flow being restarted; this is useful to avoid
that packet types for which both U/O-mode and R-mode share the same that packet types for which both U/O-mode and R-mode share the same
skipping to change at page 23, line 47 skipping to change at page 23, line 47
8.10. Expecting UOR-2 ACKs in O-mode 8.10. Expecting UOR-2 ACKs in O-mode
Usage of UOR-2 ACKs in O-mode, as discussed in section RFC3095- Usage of UOR-2 ACKs in O-mode, as discussed in section RFC3095-
5.4.1.1.2, is optional. A decompressor can also send ACKs for 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 purposes other than to acknowledge the UOR-2, without having to
continue sending ACKs for all UOR-2. Similarly, a compressor continue sending ACKs for all UOR-2. Similarly, a compressor
implementation can ignore UOR-2 ACKs for the purpose of adapting the implementation can ignore UOR-2 ACKs for the purpose of adapting the
optimistic approach strategies. optimistic approach strategies.
It is thus RECOMMENDED to not use of the optional ACK mechanism in It is thus NOT RECOMMENDED to use of the optional ACK mechanism in
O-mode, neither in compressor nor in decompressor implementations. O-mode, neither in compressor nor in decompressor implementations.
Using an incorrect expectation on UOR-2 ACKs as a basis for Using an incorrect expectation on UOR-2 ACKs as a basis for
compressor behavior will significantly degrade the compression compressor behavior will significantly degrade the compression
performance. This is because UOR-2 ACKs can be sent from a performance. This is because UOR-2 ACKs can be sent from a
decompressor for other purposes than to acknowledge the UOR-2 packet, 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 e.g. to send feedback such as clock resolution, or to initiate a mode
transition. If an implementation does use the optional acknowledgment transition. If an implementation does use the optional acknowledgment
algorithm described in Section 5.4.1.1.2, it must make sure to set 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 the k_3 and n_3 parameters to much larger values than one to ensure
skipping to change at page 30, line 45 skipping to change at page 30, 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 April 13, 2007. This Internet-Draft expires May 6, 2007.
 End of changes. 26 change blocks. 
84 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/