draft-ietf-rohc-rtp-impl-guide-09.txt   draft-ietf-rohc-rtp-impl-guide-10.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT P. Kremer INTERNET-DRAFT P. Kremer
Expires: Juni 2005 Ericsson Expires: September 2005 Ericsson
January 17, 2005 Mars 9, 2005
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-09.txt> <draft-ietf-rohc-rtp-impl-guide-10.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, each author represents that any
patent or other IPR claims of which I am (we are) aware have been applicable patent or other IPR claims of which he or she is aware
disclosed, and any of which I (we) become aware will be disclosed, in have been or will be disclosed, and any of which he or she becomes
accordance with RFC 3668 (BCP 79). aware will be disclosed, in accordance with Section 6 of RFC 3668.
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 3978 (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 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
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/1id-abstracts.html
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
This document describes common misinterpretations and some ambiguous This document describes common misinterpretations and some ambiguous
points of ROHC [1], which defines the framework and four profiles of points of RFC 3095, which defines the framework and four profiles of
a robust and efficient header compression scheme. The members of the a robust and efficient header compression scheme. The members of the
ROHC working group have identified these issues during implementation ROHC working group have identified these issues during implementation
and at the various interoperability test events. and at the various interoperability test events.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction.....................................................3
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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 used for compressed TS bits........................6 4.1. Encoding used for compressed TS bits........................6
4.2. (De)compression of TS without transmitted TS bits...........6 4.2. (De)compression of TS without transmitted TS bits...........6
4.3. Interpretation intervals for TS encoding....................7 4.3. Interpretation intervals for TS encoding....................7
4.4. TS_STRIDE for scaled timestamp encoding.....................8 4.4. TS_STRIDE for scaled timestamp encoding.....................8
4.5. Recalculating TS_OFFSET.....................................8 4.5. TS wraparound...............................................8
4.6. TS_STRIDE and the Tsc flag in Extension 3...................8 4.6. Recalculating TS_OFFSET.....................................9
4.7. TS_STRIDE and the Tsc flag in Extension 3...................9
5. List compression issues..........................................9 5. List compression issues..........................................9
5.1. Generic extension header list...............................9 5.1. Generic extension header list...............................9
5.2. CSRC list items in RTP dynamic chain........................9 5.2. CSRC list items in RTP dynamic chain.......................10
5.3. RTP dynamic chain...........................................9 5.3. RTP dynamic chain..........................................10
5.4. Compressed lists in UO-1-ID packets........................10 5.4. Compressed lists in UO-1-ID packets........................10
5.5. Bit masks in list compression..............................10 5.5. Bit masks in list compression..............................11
5.6. Headers compressed with list compression...................10 5.6. Headers compressed with list compression...................11
5.7. ESP NULL header list compression...........................10 5.7. ESP NULL header list compression...........................11
6. Updating properties.............................................10 6. Updating properties.............................................11
6.1. Implicit updates...........................................10 6.1. Implicit updates...........................................11
6.2. Updating properties of UO-1*...............................11 6.2. Updating properties of UO-1*...............................12
7. Context management and CID/context re-use.......................11 7. Context management and CID/context re-use.......................12
7.1. Compressor and decompressor MUST keep MAX_CID contexts.....11 7.1. Compressor and decompressor MUST keep MAX_CID contexts.....12
7.2. CID/context re-use.........................................11 7.2. CID/context re-use.........................................12
7.2.1. Re-using a CID/context with the same profile..........12 7.2.1. Re-using a CID/context with the same profile..........13
7.2.2. Re-using a CID/context with a different profile.......12 7.2.2. Re-using a CID/context with a different profile.......13
7.3. Context updating properties for IR packets.................13 7.3. Context updating properties for IR packets.................13
8. Other protocol clarifications...................................13 8. Other protocol clarifications...................................14
8.1. Meaning of NBO.............................................13 8.1. Meaning of NBO.............................................14
8.2. IP-ID......................................................13 8.2. IP-ID......................................................14
8.3. Extension-3 in UO-1-ID packets.............................13 8.3. Extension-3 in UO-1-ID packets.............................14
8.4. Extension-3 in UOR-2* packets..............................14 8.4. Extension-3 in UOR-2* packets..............................15
8.5. Multiple SN options in one feedback packet.................14 8.5. Multiple SN options in one feedback packet.................15
8.6. Multiple CRC options in one feedback packet................14 8.6. Multiple CRC options in one feedback packet................15
8.7. Packet decoding during mode transition.....................14 8.7. Packet decoding during mode transition.....................15
8.8. How to respond to lost feedback links?.....................15 8.8. How to respond to lost feedback links?.....................16
8.9. What does "presumed zero if absent" mean on page 88?.......15 8.9. What does "presumed zero if absent" mean on page 88?.......16
8.10. UOR-2 in profile 2 (UDP)..................................15 8.10. UOR-2 in profile 2 (UDP)..................................16
8.11. Sequence number LSB's in IP extension headers.............15 8.11. Sequence number LSB's in IP extension headers.............16
8.12. Expecting UOR-2 ACKs in O-mode............................15 8.12. Expecting UOR-2 ACKs in O-mode............................16
9. ROHC negotiation clarifications.................................16 9. ROHC negotiation clarifications.................................17
10. PROFILES suboption in ROHC-over-PPP............................17 10. PROFILES suboption in ROHC-over-PPP............................18
11. Test Configuration.............................................17 11. Test configuration.............................................18
12. Security considerations........................................18 12. Security considerations........................................19
13. Acknowledgment.................................................18 13. IANA considerations............................................19
14. References.....................................................18 14. Acknowledgment.................................................19
15. Authors' Addresses.............................................18 15. Normative references...........................................19
Appendix A - Sample CRC algorithm..................................19 16. Authors' Addresses.............................................19
Appendix B - Potential improvements in updated profiles............21 Appendix A - Sample CRC algorithm..................................20
Appendix B - Potential improvements in updated profiles............22
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 8, line 41 skipping to change at page 8, line 41
This formula is incorrect both because it excludes TS_OFFSET, and This formula is incorrect both because it excludes TS_OFFSET, and
because it would prevent a TS_STRIDE value of 0. If "/" were a because it would prevent a TS_STRIDE value of 0. If "/" were a
generally unambiguously defined operation meaning "the integral part generally unambiguously defined operation meaning "the integral part
of the result from dividing X by Y", the absence of TS_OFFSET could 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 be explained, but the formula still lacks a proper output for
TS_STRIDE equal to 0. As the core equality above does not prevent 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 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 compressor to do that, the formula of "2. Compression" should not be
read as having any formal meaning. read as having any formal meaning.
4.5. Recalculating TS_OFFSET 4.5. TS wraparound with scaled timestamp encoding
In the scaled timestamp encoding section, 4.5.3, it is said in point
4 and 5 that the compressor is not required to initialize TS_OFFSET
at wraparound, but that it is required to increase the number of bits
sent for the scaled TS value when there is a TS wraparound. The
decompressor is also required to detect and cope with TS wraparound,
including updating TS_OFFSET. This has been found to be non-trivial
to do, as well as hard to make interoperable and robust. The gain is
also insignificant, as TS wraparound happens very seldom.
It is therefore recommended not to follow point 4-5 of section 4.5.3,
and instead the compressor is recommended to reinitialize TS_OFFSET
upon TS wraparound, by sending unscaled TS. This is equivalent of
replacing point 4-5 with:
4. Offset at wraparound: If the value of TS_STRIDE is not equal
to a power of two, wraparound of the unscaled 32-bit TS will
change the value of TS_OFFSET. When this happens, the
compressor must reinitialize TS_OFFSET by sending unscaled TS,
as in 1 above.
It should be noted that by following this recommendation for the
compressor to reinitialize TS_OFFSET at wraparound, there will be no
problems interacting with a decompressor that still tries to follow
4.5.3 points 4-5. For a decompressor that assumes the compressor will
follow the above recommendation, there is a risk of the decompressor
context becoming invalid. Considering the size if the TS number
space, and thus the number of packets between each TS wraparound, the
potential cost of this is considered negligible.
4.6. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the 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.6. TS_STRIDE and the Tsc flag in Extension 3 4.7. TS_STRIDE and the Tsc flag in Extension 3
The Tsc flag in Extension 3 indicates whether TS is scaled or not. It The Tsc flag in Extension 3 indicates whether TS is scaled or not. 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 17, line 17 skipping to change at page 18, line 15
10. PROFILES suboption in ROHC-over-PPP 10. PROFILES suboption in ROHC-over-PPP
The logical union of suboptions for IPCP and IPV6CP negotiations, as The logical union of suboptions for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [2], can not be used for the PROFILES specified by ROHC over PPP [2], can not be used for the PROFILES
suboption, as the whole union would then have to be considered within suboption, as the whole union would then have to be considered within
each of the two IPCP negotiations, to avoid getting an ambiguous each of the two IPCP negotiations, to avoid getting an ambiguous
profile set. An implementation of RFC 3241 must therefore make sure profile set. An implementation of RFC 3241 must therefore make sure
the same profile set is negotiated for both IPv4 and IPv6 (IPCP and the same profile set is negotiated for both IPv4 and IPv6 (IPCP and
IPV6CP). IPV6CP).
11. Test Configuration 11. Test configuration
ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus
every ROHC implementation has an interface that can send and receive every ROHC implementation has an interface that can send and receive
IP packets (i.e. Ethernet). On the other hand, there must be an IP packets (i.e. Ethernet). On the other hand, there must be an
interface (a serial link for example) or other means of transport (an interface (a serial link for example) or other means of transport (an
IP/UDP flow), which can transmit ROHC packets. Having these two IP/UDP flow), which can transmit ROHC packets. Having these two
interfaces several configurations can be set up. The figure below interfaces several configurations can be set up. The figure below
shows sample configurations that can be used for testing a ROHC shows sample configurations that can be used for testing a ROHC
implementation: implementation:
skipping to change at page 18, line 13 skipping to change at page 19, line 11
stream. Since the tester knows the ROHC packets and the stream. Since the tester knows the ROHC packets and the
reconstructed RTP stream it can detect if the Decompressor makes a reconstructed RTP stream it can detect if the Decompressor makes a
mistake. mistake.
12. Security considerations 12. Security considerations
This document provides a number of clarifications to [1], but it does This document provides a number of clarifications to [1], but it does
not make any changes or additions to the protocol. As a consequence, not make any changes or additions to the protocol. As a consequence,
the security considerations of [1] apply without additions. the security considerations of [1] apply without additions.
13. Acknowledgment 13. IANA considerations
This document does not require any IANA actions.
14. Acknowledgment
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, The authors would like to thank Vicknesan Ayadurai, Carsten Bormann,
Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees, Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees,
Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and
Remi Pelland for their contributions and comments. Remi Pelland for their contributions and comments.
14. References 15. Normative references
[1] C. Bormann, et al., "RObust Header Compression (ROHC)", [1] C. Bormann, et al., "RObust Header Compression (ROHC)",
RFC 3095, July 2001. RFC 3095, July 2001.
[2] C. Bormann, "Robust Header Compression (ROHC) over PPP", [2] C. Bormann, "Robust Header Compression (ROHC) over PPP",
RFC 3241, April 2002. RFC 3241, April 2002.
[3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994. [3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.
15. Authors' Addresses 16. Authors' Addresses
Lars-Erik Jonsson Lars-Erik Jonsson
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61 Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
Peter Kremer Peter Kremer
Conformance and Software Test Laboratory Conformance and Software Test Laboratory
skipping to change at page 19, line 15 skipping to change at page 20, line 15
Appendix A - Sample CRC algorithm Appendix A - Sample CRC algorithm
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict; use strict;
#================================= #=================================
# #
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
# #
# This little demo shows the three types of CRC in use in RFC 3095, # This little demo shows the three types of CRC in use in RFC 3095,
# the robust header compression standard. Type your data in # the robust header compression standard. Type your data in
# hexadecimal form and the press Control+D. # hexadecimal form and then press Control+D.
# #
#--------------------------------- #---------------------------------
# #
# utility # utility
# #
sub dump_bytes($) { sub dump_bytes($) {
my $x = shift; my $x = shift;
my $i; my $i;
for ($i = 0; $i < length($x); ) { for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1))); printf("%02x ", ord(substr($x, $i, 1)));
skipping to change at page 22, line 5 skipping to change at page 23, 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>
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright Statement Copyright 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 July 17, 2005. This Internet-Draft expires September 9, 2005.
 End of changes. 

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