draft-ietf-rohc-rtp-impl-guide-06.txt   draft-ietf-rohc-rtp-impl-guide-07.txt 
Network Working Group L-E. Jonsson, Ericsson Network Working Group L-E. Jonsson, Ericsson
INTERNET-DRAFT P. Kremer, Ericsson INTERNET-DRAFT P. Kremer, Ericsson
Expires: April 2005 October 5, 2004 Expires: April 2005 October 12, 2004
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-06.txt> <draft-ietf-rohc-rtp-impl-guide-07.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 51 skipping to change at page 2, line 51
8.2. IP-ID......................................................11 8.2. IP-ID......................................................11
8.3. Extension-3 in UO-1-ID packets.............................12 8.3. Extension-3 in UO-1-ID packets.............................12
8.4. Extension-3 in UOR-2* packets..............................12 8.4. Extension-3 in UOR-2* packets..............................12
8.5. Multiple SN options in one feedback packet.................12 8.5. Multiple SN options in one feedback packet.................12
8.6. Multiple CRC options in one feedback packet................13 8.6. Multiple CRC options in one feedback packet................13
8.7. Packet decoding during mode transition.....................13 8.7. Packet decoding during mode transition.....................13
8.8. How to respond to lost feedback links?.....................13 8.8. How to respond to lost feedback links?.....................13
8.9. What does "presumed zero if absent" mean on page 88?.......13 8.9. What does "presumed zero if absent" mean on page 88?.......13
8.10. UOR-2 in profile 2 (UDP)..................................14 8.10. UOR-2 in profile 2 (UDP)..................................14
8.11. Sequence number LSB's in IP extension headers.............14 8.11. Sequence number LSB's in IP extension headers.............14
9. ROHC negotiation clarifications.................................14 8.12. When to expect UOR-2 ACKs in O-mode.......................14
9. ROHC negotiation clarifications.................................15
10. PROFILES suboption in ROHC-over-PPP............................15 10. PROFILES suboption in ROHC-over-PPP............................15
11. Test Configuration.............................................15 11. Test Configuration.............................................16
12. Security considerations........................................16 12. Security considerations........................................16
13. Acknowledgment.................................................16 13. Acknowledgment.................................................17
14. References.....................................................16 14. References.....................................................17
15. Authors' Addresses.............................................16 15. Authors' Addresses.............................................17
Appendix A - Sample CRC algorithm..................................17 Appendix A - Sample CRC algorithm..................................18
Appendix B - Potential improvements in updated profiles............19 Appendix B - Potential improvements in updated profiles............20
Appendix C - Issues identified but not yet resolved................19 Appendix C - Issues identified but not yet resolved................20
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 14, line 21 skipping to change at page 14, line 21
8.11. Sequence number LSB's in IP extension headers 8.11. Sequence number LSB's in IP extension headers
In section 5.8.5, formats are defined for compression of IP extension In section 5.8.5, formats are defined for compression of IP extension
header fields. These include compressed sequence number fields, and header fields. These include compressed sequence number fields, and
it is said that these fields contain "LSB of sequence number". This it is said that these fields contain "LSB of sequence number". This
means these sequence numbers are not "LSB-encoded" as e.g. the RTP means these sequence numbers are not "LSB-encoded" as e.g. the RTP
sequence number with an interpretation interval, but are actually sequence number with an interpretation interval, but are actually
just the LSB's of the uncompressed fields. just the LSB's of the uncompressed fields.
8.12. When to expect UOR-2 ACKs in O-mode
Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in O-mode,
and explains a conceptual algorithm for a compressor to determine
whether such ACKs can be expected from the decompressor, simply using
a condition based on unspecified parameters k_3 and n_3. However,
what is not clearly pointed out is the importance of being very
careful when implementing this confidence algorithm, as using an
incorrect expectation on UOR-2 ACKs as a basis for compressor
behavior will significantly degrade the compression performance. If a
compressor implementation wants to adapt its optimistic approach
behavior on potential UOR-2 ACK usage, the confidence algorithm for
determining UOR-2 ACK usage must be carefully designed, with
k_3=n_3>>1, as UOR-2 ACKs can be sent from a decompressor for other
purposes than to actually acknowledge the UOR-2 packet, e.g. to send
feedback data such as clock resolution, or to initiate a mode
transfer. Before adapting a compressor to the potential use of UOR-2
ACKs, the implementer must ensure all these aspects are considered by
the confidence algorithm.
It should again be noted that the use of UOR-2 ACKs in O-mode is
indeed optional, so a decompressor can send ACKs for other purposes
than actually acking the UOR-2, without then having to continue
sending them for all UOR-2. Similarly, compressor implementations can
totally ignore UOR-2 ACKs for the purpose of adapting the optimistic
approach strategies.
9. ROHC negotiation clarifications 9. ROHC negotiation clarifications
According to section 4.1, the link layer must provide means to According to section 4.1, the link layer must provide means to
negotiate e.g. the channel parameters listed in section 5.1.1. One 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 of these parameters is the PROFILES parameter, which is said to be a
set of non-negative integers where each integer indicates a profile set of non-negative integers where each integer indicates a profile
supported by the decompressor. This can be interpreted as if it is supported by the decompressor. This can be interpreted as if it is
sufficient to have a mechanism to announce profile support from sufficient to have a mechanism to announce profile support from
decompressor to compressor. However, things are a little bit more decompressor to compressor. However, things are a little bit more
complicated than that. complicated than that.
skipping to change at page 16, line 41 skipping to change at page 17, line 35
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
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
EMail: peter.kremer@ericsson.com EMail: peter.kremer@ericsson.com
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
# #
skipping to change at page 20, line 21 skipping to change at page 21, line 21
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 5, 2005. This Internet-Draft expires April 12, 2005.
 End of changes. 

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