draft-ietf-rohc-rtp-impl-guide-08.txt   draft-ietf-rohc-rtp-impl-guide-09.txt 
Network Working Group L-E. Jonsson, Ericsson
INTERNET-DRAFT P. Kremer, Ericsson Network Working Group L-E. Jonsson
Expires: April 2005 October 25, 2004 INTERNET-DRAFT P. Kremer
Expires: Juni 2005 Ericsson
January 17, 2005
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-08.txt> <draft-ietf-rohc-rtp-impl-guide-09.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, I (we) certify that any applicable By submitting this Internet-Draft, I (we) certify that any applicable
patent or other IPR claims of which I am (we are) aware have been patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79). accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of By submitting this Internet-Draft, I (we) accept the provisions of
Section 3 of RFC 3667 (BCP 78). Section 3 of RFC 3667 (BCP 78).
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. CRC calculation and coverage issues..............................3 2. CRC calculation and coverage issues..............................3
2.1. CRC calculation.............................................3 2.1. CRC calculation.............................................3
2.2. Padding octet in CRC........................................3 2.2. Padding octet in CRC........................................3
2.3. CRC coverage in CRC feedback options........................3 2.3. CRC coverage in CRC feedback options........................3
2.4. CRC coverage of the ESP NULL header.........................4 2.4. CRC coverage of the ESP NULL header.........................4
3. Enhanced mode transition procedures..............................4 3. Enhanced mode transition procedures..............................4
3.1. Modified transition logic for enhanced transitions..........4 3.1. Modified transition logic for enhanced transitions..........4
3.2. Transition from Reliable to Optimistic mode.................5 3.2. Transition from Reliable to Optimistic mode.................5
3.3. Transition to Unidirectional mode...........................6 3.3. Transition to Unidirectional mode...........................6
4. Timestamp encoding considerations................................6 4. Timestamp encoding considerations................................6
4.1. Encoding of TS values.......................................6 4.1. Encoding used for compressed TS bits........................6
4.2. Interpretation intervals for TS encoding....................6 4.2. (De)compression of TS without transmitted TS bits...........6
4.3. Recalculating TS_OFFSET.....................................7 4.3. Interpretation intervals for TS encoding....................7
4.4. TS_STRIDE and the Tsc flag in Extension 3...................7 4.4. TS_STRIDE for scaled timestamp encoding.....................8
5. List compression issues..........................................7 4.5. Recalculating TS_OFFSET.....................................8
5.1. Generic extension header list...............................7 4.6. TS_STRIDE and the Tsc flag in Extension 3...................8
5.2. CSRC list items in RTP dynamic chain........................8 5. List compression issues..........................................9
5.3. RTP dynamic chain...........................................8 5.1. Generic extension header list...............................9
5.4. Compressed lists in UO-1-ID packets.........................8 5.2. CSRC list items in RTP dynamic chain........................9
5.5. Bit masks in list compression...............................8 5.3. RTP dynamic chain...........................................9
5.6. Headers compressed with list compression....................9 5.4. Compressed lists in UO-1-ID packets........................10
5.7. ESP NULL header list compression............................9 5.5. Bit masks in list compression..............................10
6. Updating properties..............................................9 5.6. Headers compressed with list compression...................10
6.1. Implicit updates............................................9 5.7. ESP NULL header list compression...........................10
6.2. Updating properties of UO-1*................................9 6. Updating properties.............................................10
7. Context management and CID/context re-use.......................10 6.1. Implicit updates...........................................10
7.1. Compressor and decompressor MUST keep MAX_CID contexts.....10 6.2. Updating properties of UO-1*...............................11
7.2. CID/context re-use.........................................10 7. Context management and CID/context re-use.......................11
7.2.1. Re-using a CID/context with the same profile..........10 7.1. Compressor and decompressor MUST keep MAX_CID contexts.....11
7.2.2. Re-using a CID/context with a different profile.......11 7.2. CID/context re-use.........................................11
7.3. Context updating properties for IR packets.................11 7.2.1. Re-using a CID/context with the same profile..........12
8. Other protocol clarifications...................................11 7.2.2. Re-using a CID/context with a different profile.......12
8.1. Meaning of NBO.............................................11 7.3. Context updating properties for IR packets.................13
8.2. IP-ID......................................................11 8. Other protocol clarifications...................................13
8.3. Extension-3 in UO-1-ID packets.............................12 8.1. Meaning of NBO.............................................13
8.4. Extension-3 in UOR-2* packets..............................12 8.2. IP-ID......................................................13
8.5. Multiple SN options in one feedback packet.................12 8.3. Extension-3 in UO-1-ID packets.............................13
8.6. Multiple CRC options in one feedback packet................13 8.4. Extension-3 in UOR-2* packets..............................14
8.7. Packet decoding during mode transition.....................13 8.5. Multiple SN options in one feedback packet.................14
8.8. How to respond to lost feedback links?.....................13 8.6. Multiple CRC options in one feedback packet................14
8.9. What does "presumed zero if absent" mean on page 88?.......13 8.7. Packet decoding during mode transition.....................14
8.10. UOR-2 in profile 2 (UDP)..................................14 8.8. How to respond to lost feedback links?.....................15
8.11. Sequence number LSB's in IP extension headers.............14 8.9. What does "presumed zero if absent" mean on page 88?.......15
8.12. Expecting UOR-2 ACKs in O-mode............................14 8.10. UOR-2 in profile 2 (UDP)..................................15
9. ROHC negotiation clarifications.................................15 8.11. Sequence number LSB's in IP extension headers.............15
10. PROFILES suboption in ROHC-over-PPP............................15 8.12. Expecting UOR-2 ACKs in O-mode............................15
11. Test Configuration.............................................16 9. ROHC negotiation clarifications.................................16
12. Security considerations........................................16 10. PROFILES suboption in ROHC-over-PPP............................17
13. Acknowledgment.................................................17 11. Test Configuration.............................................17
14. References.....................................................17 12. Security considerations........................................18
15. Authors' Addresses.............................................17 13. Acknowledgment.................................................18
Appendix A - Sample CRC algorithm..................................18 14. References.....................................................18
Appendix B - Potential improvements in updated profiles............20 15. Authors' Addresses.............................................18
Appendix C - Issues identified but not yet resolved................20 Appendix A - Sample CRC algorithm..................................19
Appendix B - Potential improvements in updated profiles............21
1. Introduction 1. Introduction
ROHC [1] defines a robust and efficient header compression algorithm, ROHC [1] defines a robust and efficient header compression algorithm,
and its description is rather long and complex. During the and its description is rather long and complex. During the
implementation and the interoperability tests of the algorithm some implementation and the interoperability tests of the algorithm some
unclear areas have been identified. This document tries to collect unclear areas have been identified. This document tries to collect
and clarify these points. Note that all section and chapter and clarify these points. Note that all section and chapter
references in this document refer to [1], if not stated otherwise. references in this document refer to [1], if not stated otherwise.
skipping to change at page 6, line 32 skipping to change at page 6, line 32
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ | C_TRANS = D |-<-<-<-+ |
| | | |
|->->->-+ UO-0, UO-1* | |->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ | | +->->->->->->->-+ |
| +->->->-| D_TRANS = D | +->->->-| D_TRANS = D
| | D_MODE= U | | D_MODE= U
4. Timestamp encoding considerations 4. Timestamp encoding considerations
4.1. Encoding of TS values 4.1. Encoding used for compressed TS bits
RTP Timestamp values (TS) are always encoded using W-LSB encoding, RTP Timestamp values (TS) are always encoded using W-LSB encoding,
both when sent scaled and when sent unscaled. For TS values sent in both when sent scaled and when sent unscaled. For TS values sent in
Extension 3, W-LSB encoded values are sent using the self-describing Extension 3, W-LSB encoded values are sent using the self-describing
variable-length format (section 4.5.6), and this applies to both variable-length format (section 4.5.6), and this applies to both
scaled and unscaled values. scaled and unscaled values.
4.2. Interpretation intervals for TS encoding 4.2. (De)compression of TS without transmitted TS bits
RFC 3095 explains that SO-state provides the most efficient
compression within ROHC RTP. In this state, apart from packet type
identification and the error detection CRC, only RTP sequence number
(SN) bits have to be transmitted in RTP compressed headers. All other
fields are then omitted either because they are unchanged or because
they can be reconstructed through a function from the SN (i.e. by
combining the transmitted SN bits with state information from the
context). Although it is never spelled out explicitly what fields are
inferred from the SN in this way, one should be able to figure out
that this principle applies to the IP Identification (IP-ID) field
and the RTP Timestamp (TS) field.
IP-ID compression and decompression, both with and without
transmitted IP-ID bits in the compressed header, are well defined in
section 4.5.5 (see section 8.2 of this document). However, for TS it
is only defined how to decompress based on actual TS bits in the
compressed header, either scaled or unscaled, but not how to infer
the TS from the SN, i.e. the SO-state operation. Although the general
idea is simple, the actual operation must be clearly defined to
ensure interoperability. There are also inconsistent text pieces that
might confuse an implementer and result in non-interoperable
implementations. This section therefore provides the necessary
clarifications to SN-to-TS decompression, i.e. decompression of TS
(scaled or unscaled) when no TS bits are transmitted in the
compressed header.
When no TS bits are transmitted in the compressed header, the encoded
TS value (scaled or unscaled) is to be decompressed assuming a linear
extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope.
Section 5.7 defines the potential values for default-slope as:
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see section 4.5.3), and default-slope(TS) = 1.
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE).
What must be noted here is that no slope value is used other than the
default-slope value, as defined in section 5.7. There is confusing
text in section 5.5.1.2 that might mistakenly be interpreted as if
the slope can have different values and be "learned", which is
incorrect. The default-slope from 5.7 is always the value used when
decompressing TS based on SN.
4.3. Interpretation intervals for TS encoding
Section 4.5.4 defines the interpretation interval, p, for timer-based Section 4.5.4 defines the interpretation interval, p, for timer-based
compression of the RTP timestamp. However, Section 5.7 defines a compression of the RTP timestamp. However, Section 5.7 defines a
different interpretation interval, which is defined as the different interpretation interval, which is defined as the
interpretation interval to use for all TS values. It is thus unclear interpretation interval to use for all TS values. It is thus unclear
which p-value to use, at least for timer-based compression. which p-value to use, at least for timer-based compression.
The way this should be interpreted is that the p-value differs The way this should be interpreted is that the p-value differs
depending on whether timer-based compression is enabled or not. For depending on whether timer-based compression is enabled or not. For
timer-based compression, the interpretation interval of section timer-based compression, the interpretation interval of section
skipping to change at page 7, line 18 skipping to change at page 8, line 13
have to inform the compressor (on a per-channel basis) about its have to inform the compressor (on a per-channel basis) about its
clock resolution. Further, the compressor has to send (on a per- clock resolution. Further, the compressor has to send (on a per-
context basis) a non-zero TIME_STRIDE to the decompressor. context basis) a non-zero TIME_STRIDE to the decompressor.
When the compressor is confident that the decompressor has received When the compressor is confident that the decompressor has received
the TIME_STRIDE value, it can switch to timer-based compression. the TIME_STRIDE value, it can switch to timer-based compression.
During this transition from window-based compression to timer-based During this transition from window-based compression to timer-based
compression, it is necessary that the compressor keep k large enough compression, it is necessary that the compressor keep k large enough
to cover both interpretation intervals. to cover both interpretation intervals.
4.3. Recalculating TS_OFFSET 4.4. TS_STRIDE for scaled timestamp encoding
The timestamp stride (TS_STRIDE) is defined as the expected increase
in the timestamp value between two RTP packets with consecutive
sequence numbers. TS_STRIDE is set by the compressor and explicitly
communicated to the decompressor, and it is used either as the
scaling factor for scaled TS encoding, or constitutes the default-
slope used when decompressing an unscaled TS through a linear
extrapolation from the SN (see also section 4.2 above).
The relation between TS and TS_SCALED, given by the following
equality in section 4.5.3, defines the mathematical meaning of
TS_STRIDE:
TS = TS_SCALED * TS_STRIDE + TS_OFFSET
In the compression step explained following this core equality of
section 4.5.3, TS_SCALED is incorrectly written as TS / TS_STRIDE.
This formula is incorrect both because it excludes TS_OFFSET, and
because it would prevent a TS_STRIDE value of 0. If "/" were a
generally unambiguously defined operation meaning "the integral part
of the result from dividing X by Y", the absence of TS_OFFSET could
be explained, but the formula still lacks a proper output for
TS_STRIDE equal to 0. As the core equality above does not prevent
setting TS_STRIDE to 0, and there is no reason not to allow a
compressor to do that, the formula of "2. Compression" should not be
read as having any formal meaning.
4.5. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the TS can be sent unscaled if the TS value change does not match the
established TS_STRIDE, but the TS_STRIDE might still stay unchanged. established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
To ensure correct decompression of subsequent packets, the To ensure correct decompression of subsequent packets, the
decompressor should therefore always recalculate the RTP TS modulo, decompressor should therefore always recalculate the RTP TS modulo,
TS_OFFSET, when a packet with an unscaled TS value is received. TS_OFFSET, when a packet with an unscaled TS value is received.
4.4. TS_STRIDE and the Tsc flag in Extension 3 4.6. TS_STRIDE and the Tsc flag in Extension 3
The Tsc flag in Extension 3 indicates whether TS is scaled or not. It The Tsc flag in Extension 3 indicates whether TS is scaled or not. It
must be noted that the Tsc value apply to all TS bits, also if there must be noted that the Tsc value apply to all TS bits, also if there
are no TS bits in the extension itself. are no TS bits in the extension itself.
Note also that if Tsc=1, TS is scaled using context(TS_STRIDE), not Note also that if Tsc=1, TS is scaled using context(TS_STRIDE), not
value(TS_STRIDE) as is said in the legend for Extension 3 in section value(TS_STRIDE) as is said in the legend for Extension 3 in section
5.7.5. 5.7.5.
When a compressor uses Extension 3 to re-establish a new value for When a compressor uses Extension 3 to re-establish a new value for
skipping to change at page 9, line 4 skipping to change at page 10, line 28
latter case. According to section 5.8.1.2, the compressor must latter case. According to section 5.8.1.2, the compressor must
increment Counter by 1. increment Counter by 1.
5.5. Bit masks in list compression 5.5. Bit masks in list compression
A 7-bit or 15-bit mask may be used in the insertion and/or removal A 7-bit or 15-bit mask may be used in the insertion and/or removal
schemes for compressed lists. It should be noted that even if a list schemes for compressed lists. It should be noted that even if a list
has more than 7 items, a 7-bit mask could be used as long as changes has more than 7 items, a 7-bit mask could be used as long as changes
are only applied in the first part of the reference list, and items are only applied in the first part of the reference list, and items
with an index not covered by the 7-bit mask are thus kept unchanged. with an index not covered by the 7-bit mask are thus kept unchanged.
5.6. Headers compressed with list compression 5.6. Headers compressed with list compression
In section 5.8, it is stated that headers which can be part of In section 5.8, it is stated that headers which can be part of
extension header chains INCLUDE AH, null ESP, minimal encapsulation, extension header chains INCLUDE AH, null ESP, minimal encapsulation
GRE, and IPv6 extensions. This list of headers which can be (MINE), GRE, and IPv6 extensions. This list of headers which can be
compressed is correct, but the work INCLUDE should not be there, compressed is correct, but the word INCLUDE should not be there,
since only the header types listed can actually be handled. since only the header types listed can actually be handled. It should
further be noted that for the Minimal Encapsulation (MINE) header,
there is no explicit discussion of how to compress it, as the header
is either sent uncompressed or fully compressed away.
5.7. ESP NULL header list compression 5.7. ESP NULL header list compression
Due to the offset of the fields in the trailer part of the ESP Due to the offset of the fields in the trailer part of the ESP
header, a compressor must only compress packets containing at most header, a compressor must only compress packets containing at most
one NULL ESP header. one NULL ESP header.
6. Updating properties 6. Updating properties
6.1. Implicit updates 6.1. Implicit updates
skipping to change at page 12, line 14 skipping to change at page 13, line 39
If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent
as 16-bit original Identification value(s) at the end of the as 16-bit original Identification value(s) at the end of the
compressed base header, according to the IP-ID description (see the compressed base header, according to the IP-ID description (see the
beginning of section 5.7). beginning of section 5.7).
It should be noted that when RND*=0, IP-ID is always compressed, i.e. It should be noted that when RND*=0, IP-ID is always compressed, i.e.
expressed as an SN offset and byte-swapped if NBO=0. This is the case expressed as an SN offset and byte-swapped if NBO=0. This is the case
even when 16 bits of IP-ID is sent in extension 3. even when 16 bits of IP-ID is sent in extension 3.
When RND=0 but no IP-ID bits are sent in the compressed header, the
SN offset for IP-ID stays unchanged, meaning that Offset_m equals
Offset_ref, as described in Section 4.5.5. This is further expressed
in a slightly different way (with the same meaning) in Section 5.7,
where it is said that "default-slope(IP-ID offset) = 0", meaning that
if no bits are sent for IP-ID, its SN offset slope defaults to 0.
8.3. Extension-3 in UO-1-ID packets 8.3. Extension-3 in UO-1-ID packets
Extension-3 is applied to give values and indicate changes to fields Extension-3 is applied to give values and indicate changes to fields
other than SN, TS and IP-ID in IP header(s) and RTP header. In case other than SN, TS and IP-ID in IP header(s) and RTP header. In case
of UO-1-ID packets, it should be noted that values provided in of UO-1-ID packets, it should be noted that values provided in
extensions do not update the context, with an exception for SN, TS extensions do not update the context, with an exception for SN, TS
and IP-ID fields, which always update the context (Section 5.7.3.). and IP-ID fields, which always update the context (Section 5.7.3.).
It should also be noted that a UO-1-ID packet with Extension 3 must It should also be noted that a UO-1-ID packet with Extension 3 must
never be sent with RND flags that changes the packet interpretation, never be sent with RND flags that changes the packet interpretation,
i.e. that would violate the base condition for UO-1-ID (at least one i.e. that would violate the base condition for UO-1-ID (at least one
skipping to change at page 20, line 15 skipping to change at page 22, line 5
Appendix B - Potential improvements in updated profiles Appendix B - Potential improvements in updated profiles
Regarding the CC field and CSRC list, the following interpretation Regarding the CC field and CSRC list, the following interpretation
has been proposed as an improvement: has been proposed as an improvement:
"It should be noted that when the value of this CC field is equal to "It should be noted that when the value of this CC field is equal to
zero, there is no Generic CSRC list present in the dynamic chain, zero, there is no Generic CSRC list present in the dynamic chain,
i.e. the field comment should have said "variable length, present if i.e. the field comment should have said "variable length, present if
CC > 0". "<introduction text> CC > 0". "<introduction text>
Appendix C - Issues identified but not yet resolved
These issues have been identified but are still under discussion on
the ROHC WG mail list. Resolutions to these issues will have to be
added in later revisions of this document.
* Slope used to compress/decompress RTP Timestamp
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
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 25, 2005. This Internet-Draft expires July 17, 2005.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/