draft-ietf-rohc-rtp-impl-guide-01.txt   draft-ietf-rohc-rtp-impl-guide-02.txt 
Network Working Group Peter Kremer, Ericsson Network Working Group Peter Kremer, Ericsson
INTERNET-DRAFT Lars-Erik Jonsson, Ericsson INTERNET-DRAFT Lars-Erik Jonsson, Ericsson
Expires: December 2002 June, 2002 Expires: April 2003 October 31, 2002
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-01.txt> <draft-ietf-rohc-rtp-impl-guide-02.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
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 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/ietf/lid-abstracts.txt
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 an individual submission to the IETF. Comments This document is a submission of the IETF ROHC WG. Comments should be
should be directed to the authors. 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 [RFC 3095], which defines the framework and four points of ROHC [RFC 3095], which defines the framework and four
profiles of a robust and efficient header compression scheme. These profiles of a robust and efficient header compression scheme. These
points have been identified by the members of the ROHC working group points have been identified by the members of the ROHC working group
during different interoperability test events. during different interoperability test events.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
2. CRC Calculation.................................................2 2. CRC Calculation.................................................2
3. Enhanced mode transition procedures.............................3 3. Enhanced mode transition procedures.............................3
3.1. Modified transition logic for enhanced transitions............3 3.1. Modified transition logic for enhanced transitions............3
3.2. Transition from Reliable to Optimistic mode...................4 3.2. Transition from Reliable to Optimistic mode...................4
3.3. Transition to Unidirectional mode.............................5 3.3. Transition to Unidirectional mode.............................5
4. Other clarifications............................................5 4. Other protocol clarifications...................................5
4.1. Padding octet in CRC..........................................5 4.1. Padding octet in CRC..........................................5
4.2. Transition to timer-based compression.........................5 4.2. Interpretation intervals for TS encoding......................5
4.3. Generic extension header list.................................5 4.3. Generic extension header list.................................6
4.4. Generic CSRC list.............................................6 4.4. Generic CSRC list.............................................6
4.5. RTP dynamic chain.............................................6 4.5. RTP dynamic chain.............................................6
4.6. Meaning of NBO................................................6 4.6. Meaning of NBO................................................7
4.7. Implicit updates..............................................6 4.7. Implicit updates..............................................7
4.8. IP-ID.........................................................7 4.8. IP-ID.........................................................7
4.9. Extension-3 in UO-1-ID packets................................7 4.9. Extension-3 in UO-1-ID packets................................7
4.10. Extension-3 in UOR-2* packets................................7 4.10. Extension-3 in UOR-2* packets................................7
4.11. Multiple SN options in one feedback packet...................7 4.11. Multiple SN options in one feedback packet...................8
4.12. Packet decoding during mode transition.......................7 4.12. Packet decoding during mode transition.......................8
4.13. How to respond to lost feedback links?.......................8 4.13. How to respond to lost feedback links?.......................8
4.14. What does "presumed zero if absent" mean on page 88?.........8 4.14. What does "presumed zero if absent" mean on page 88?.........9
4.15. CSRC list in UO-1-ID packets.................................8 4.15. CSRC list in UO-1-ID packets.................................9
5. Test Configuration..............................................9 5. ROHC negotiation clarifications.................................9
6. Acknowledgment..................................................9 6. Test Configuration.............................................10
7. References.....................................................10 7. Security considerations........................................10
8. Authors' Addresses.............................................10 8. Acknowledgment.................................................11
Appendix A. Sample CRC algorithm..................................11 9. References.....................................................11
10. Authors' Addresses............................................11
Appendix A. Sample CRC algorithm..................................12
1. Introduction 1. Introduction
ROHC [RFC 3095] addresses a robust and efficient header compression ROHC [RFC 3095] addresses a robust and efficient header compression
algorithm and as a such its description is long and complex. During algorithm and as a such its description is long and complex. During
the implementation and the interoperability tests of the algorithm the implementation and the interoperability tests of the algorithm
some unclear areas have been identified. This document tries to some unclear areas have been identified. This document tries to
collect and clarify these points. collect and clarify these points. Note that all section and chapter
references in this document refer to [RFC-3095], if not stated
otherwise.
2. CRC Calculation 2. CRC Calculation
ROHC uses CRC checksum in order to provide some protection against ROHC uses CRC checksum in order to provide some protection against
bit errors. CRC is used in the segmentation protocol and in the bit errors. CRC is used in the segmentation protocol and in the
compressed packets, as well. compressed packets, as well.
Section 5.2.5.2 describes the segmentation protocol and refers to Section 5.2.5.2 describes the segmentation protocol and refers to
[RFC 1662], which describes a well-defined CRC algorithm for 32 bit [RFC 1662], which describes a well-defined CRC algorithm for 32 bit
checksums. Although, Section 5.9 only defines the polynomials for 3, checksums. Although, Section 5.9 only defines the polynomials for 3,
skipping to change at page 5, line 30 skipping to change at page 5, line 30
|->-.. | |->-.. |
| ACK(SN,U) +-<-<-<-| | ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ | C_TRANS = D |-<-<-<-+ |
| | | |
|->->->-+ UO-0, UO-1* | |->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ | | +->->->->->->->-+ |
| +->->->-| D_TRANS = D | +->->->-| D_TRANS = D
| | D_MODE= U | | D_MODE= U
4. Other clarifications 4. Other protocol clarifications
4.1. Padding octet in CRC 4.1. Padding octet in CRC
According to Section 5.9.1, in case of IR and IR-DYN packets the CRC According to Section 5.9.1, in case of IR and IR-DYN packets the CRC
"is calculated over the entire IR or IR-DYN packet, excluding Payload "is calculated over the entire IR or IR-DYN packet, excluding Payload
and including CID or Add-CID octet". Padding isn't meant to be and including CID or Add-CID octet". Padding isn't meant to be
meaningful part of a packet and not included in CRC calculation. As meaningful part of a packet and not included in CRC calculation. As
a result, CRC doesn't cover the Add-CID octet for CID 0, either. a result, CRC doesn't cover the Add-CID octet for CID 0, either.
4.2. Transition to timer-based compression 4.2. Interpretation intervals for TS encoding
During transition from window-based compression to timer-based Section 4.5.4 defines the interpretation interval, p, for timer-based
compression it is necessary to keep k large enough to cover both compression of the RTP timestamp. However, Section 5.7 defines a
interpretation intervals. different interpretation interval, which is defined as the
interpretation interval to use for all TS values. It is thus unclear
which p-value to use, at least for timer-based compression.
The way this should be interpreted is that the p-value differs
depending on whether timer-based compression is enabled or not. For
timer-based compression, the interpretation interval of section
4.5.4, p = 2^(k-1) - 1, is used for TS. Otherwise, the interval of
section 5.7, p = 2^(k-2) - 1, is used for TS with regular W-LSB
encoding.
Since two different p-values are used, the compressor must take this
into account during the process of enabling timer-based compression.
Before timer-based compression can be used, the decompressor will
have to inform the compressor (on a per-channel basis) about its
clock resolution, and the compressor has to send (on a per-context
basis) a non-zero TIME_STRIDE to the decompressor.
When the compressor is confident that the decompressor has received
the TIME_STRIDE value, it can switch to timer-based compression.
During this transition from window-based compression to timer-based
compression, it is necessary that the compressor keeps k large enough
to cover both interpretation intervals.
4.3. Generic extension header list 4.3. Generic extension header list
Section 5.7.7.4 defines the static and dynamic parts of the IPv4 Section 5.7.7.4 defines the static and dynamic parts of the IPv4
header. This section indicates a 'Generic extension header list' header. This section indicates a 'Generic extension header list'
field in the dynamic chain, which has a variable length. The field in the dynamic chain, which has a variable length. The
detailed description of this field can be found in Section 5.8.6.1. detailed description of this field can be found in Section 5.8.6.1.
The generic extension header list starts with an octet that is always The generic extension header list starts with an octet that is always
present, so its length is one octet, at least. If the 'GP' bit in present, so its length is one octet, at least. If the 'GP' bit in
skipping to change at page 9, line 9 skipping to change at page 9, line 33
compressor decides that it may use this list as a future reference. compressor decides that it may use this list as a future reference.
On one hand, the decompressor shouldn't save the list because UO-1-ID On one hand, the decompressor shouldn't save the list because UO-1-ID
packets doesn't update the context. On the other hand, the packets doesn't update the context. On the other hand, the
decompressor updates its translation table whenever an (Index, item) decompressor updates its translation table whenever an (Index, item)
pair is received (section 5.8.1). The decompressor must be able to pair is received (section 5.8.1). The decompressor must be able to
handle such a packet, thus it has to behave as described in the handle such a packet, thus it has to behave as described in the
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. Test Configuration 5. ROHC negotiation clarifications
Section 4.1 states that the link layer must provide means to
negotiate e.g. the channel parameters listed in section 5.1.1. One
of these parameters is the PROFILES parameter, which is said to be a
set of non-negative integers where each integer indicates a profile
supported by the decompressor. This can be interpreted as if it is
sufficient to have a mechanism to announce profile support from
decompressor to compressor. However, things are a little bit more
complicated than that.
Each profile is identified by a 16-bit value, where the 8 LSB bits
indicate the actual profile, and the 8 MSB bits indicate the version
of that profile (see chapter 8). In the ROHC headers sent over the
link, the profile used is identified only with the 8 LSB bits, which
means that the compressor and decompressor must have agreed on which
version to use for each profile. This can be done in various ways,
but the negotiation protocol must provide means to do it.
In conclusion, the negotiation protocol must be able to communicate
to the compressor the set of profiles supported by the decompressor,
and when multiple versions of the same profile are available, also
provide means for the decompressor to know which version will be used
by the compressor. This basically means that the PROFILES set after
negotiation must not include more than one version of the same
profile.
6. 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 9, line 49 skipping to change at page 10, line 48
In the first case, the test equipment generates the RTP stream and In the first case, the test equipment generates the RTP stream and
also acts as a ROHC decompressor. The tester must recognize if the also acts as a ROHC decompressor. The tester must recognize if the
original RTP stream was compressed in a bad way and gives an alarm. original RTP stream was compressed in a bad way and gives an alarm.
In the second case, it is the test equipment that sends the In the second case, it is the test equipment that sends the
compressed ROHC packets and the Decompressor reconstructs the RTP compressed ROHC packets and the Decompressor reconstructs the RTP
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.
6. Acknowledgment 7. Security considerations
This document provides a number of clarifications to [RFC-3095], but
it does not make any changes or additions to the protocol. As a
consequence, the security considerations of [RFC-3095] apply without
additions.
8. Acknowledgment
The authors would like thank Vicknesan Ayadurai, Carsten Bormann, The authors would like thank Vicknesan Ayadurai, Carsten Bormann,
Zhigang Liu, Abigail Surtees and Mark West for their contributions Zhigang Liu, Abigail Surtees and Mark West for their contributions
and comments. and comments.
7. References 9. References
[RFC-3095] C. Bormann, Editor, RObust Header Compression (ROHC), [RFC-3095] C. Bormann, Editor, RObust Header Compression (ROHC),
RFC 3095, July 2001. RFC 3095, July 2001.
[RFC-1662] W. Simpson, Editor, PPP in HDLC-like Framing, RFC 1662, [RFC-1662] W. Simpson, Editor, PPP in HDLC-like Framing, RFC 1662,
July 1994. July 1994.
8. Authors' Addresses 10. Authors' Addresses
Peter Kremer Peter Kremer
Conformance and Software Test Laboratory Conformance and Software Test Laboratory
Ericsson Hungary Ericsson Hungary
H-1300 Bp. 3., P.O. Box 107, HUNGARY H-1300 Bp. 3., P.O. Box 107, HUNGARY
Phone: +36-1-437-7033 Phone: +36-1-437-7033
Fax: +36-1-437-7767 Fax: +36-1-437-7767
Email: Peter.Kremer@ericsson.com Email: Peter.Kremer@ericsson.com
Lars-Erik Jonsson Lars-Erik Jonsson
Box 920
Ericsson AB Ericsson AB
Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 07 Phone: +46 920 20 21 07
Fax: +46 920 20 20 99 Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
Appendix A. Sample CRC algorithm Appendix A. Sample CRC algorithm
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict; use strict;
skipping to change at line 552 skipping to change at page 14, line 4
# #
do_crc(7, 0x79, $string); do_crc(7, 0x79, $string);
#--------------------------------- #---------------------------------
# #
# 3-bit FO/SO CRC # 3-bit FO/SO CRC
# #
# C(x) = x^0 + x^1 + x^3 # C(x) = x^0 + x^1 + x^3
# #
do_crc(3, 0x6, $string); do_crc(3, 0x6, $string);
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires April 31, 2003.
 End of changes. 

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