draft-ietf-rohc-rtp-impl-guide-10.txt   draft-ietf-rohc-rtp-impl-guide-11.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT P. Kremer INTERNET-DRAFT P. Kremer
Expires: September 2005 Ericsson Expires: October 2005 Ericsson
Mars 9, 2005 April 4, 2005
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-10.txt> <draft-ietf-rohc-rtp-impl-guide-11.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 RFC 3668. 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 3978 (BCP 78). Section 3 of RFC 3978 (BCP 78).
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. TS wraparound...............................................8 4.5. TS wraparound with scaled timestamp encoding................8
4.6. Recalculating TS_OFFSET.....................................9 4.6. Recalculating TS_OFFSET.....................................9
4.7. TS_STRIDE and the Tsc flag in Extension 3...................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.......................10 5.2. CSRC list items in RTP dynamic chain.......................10
5.3. RTP dynamic chain..........................................10 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..............................11 5.5. Bit masks in list compression..............................11
5.6. Headers compressed with list compression...................11 5.6. Headers compressed with list compression...................11
5.7. ESP NULL header list compression...........................11 5.7. ESP NULL header list compression...........................11
skipping to change at page 2, line 55 skipping to change at page 2, line 55
8.3. Extension-3 in UO-1-ID packets.............................14 8.3. Extension-3 in UO-1-ID packets.............................14
8.4. Extension-3 in UOR-2* packets..............................15 8.4. Extension-3 in UOR-2* packets..............................15
8.5. Multiple SN options in one feedback packet.................15 8.5. Multiple SN options in one feedback packet.................15
8.6. Multiple CRC options in one feedback packet................15 8.6. Multiple CRC options in one feedback packet................15
8.7. Packet decoding during mode transition.....................15 8.7. Packet decoding during mode transition.....................15
8.8. How to respond to lost feedback links?.....................16 8.8. How to respond to lost feedback links?.....................16
8.9. What does "presumed zero if absent" mean on page 88?.......16 8.9. What does "presumed zero if absent" mean on page 88?.......16
8.10. UOR-2 in profile 2 (UDP)..................................16 8.10. UOR-2 in profile 2 (UDP)..................................16
8.11. Sequence number LSB's in IP extension headers.............16 8.11. Sequence number LSB's in IP extension headers.............16
8.12. Expecting UOR-2 ACKs in O-mode............................16 8.12. Expecting UOR-2 ACKs in O-mode............................16
8.13. Compression of SN in AH and GRE extension headers.........17
9. ROHC negotiation clarifications.................................17 9. ROHC negotiation clarifications.................................17
10. PROFILES suboption in ROHC-over-PPP............................18 10. PROFILES suboption in ROHC-over-PPP............................18
11. Test configuration.............................................18 11. Test configuration.............................................18
12. Security considerations........................................19 12. Security considerations........................................19
13. IANA considerations............................................19 13. IANA considerations............................................19
14. Acknowledgment.................................................19 14. Acknowledgment.................................................19
15. Normative references...........................................19 15. Normative references...........................................19
16. Authors' Addresses.............................................19 16. Authors' Addresses.............................................19
Appendix A - Sample CRC algorithm..................................20 Appendix A - Sample CRC algorithm..................................20
Appendix B - Potential improvements in updated profiles............22 Appendix B - Potential improvements in updated profiles............22
skipping to change at page 14, line 26 skipping to change at page 14, line 26
According to Section 5.7 IP-ID means the compressed value of the IPv4 According to Section 5.7 IP-ID means the compressed value of the IPv4
header's 'Identification' field. Compressed packets contain this header's 'Identification' field. Compressed packets contain this
compressed value (IP-ID), while IR packets with dynamic chain and IR- compressed value (IP-ID), while IR packets with dynamic chain and IR-
DYN packets transmit the original, uncompressed Identification field DYN packets transmit the original, uncompressed Identification field
value. The IP-ID field always represents the Identification value of value. The IP-ID field always represents the Identification value of
the innermost IPv4 header whose corresponding RND flag is not 1. the innermost IPv4 header whose corresponding RND flag is not 1.
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). When there is no compressed IP-ID, i.e.
for IPv6 or when all IP Identification information is sent as-is (as
indicated by RND/RND2 being set to 1), the decompressor ignores IP-ID
bits sent within compressed base headers.
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 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 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 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, 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 where it is said that "default-slope(IP-ID offset) = 0", meaning that
skipping to change at page 17, line 23 skipping to change at page 17, line 25
compressor implementation wants to adapt its optimistic approach compressor implementation wants to adapt its optimistic approach
behavior on potential UOR-2 ACK usage, the confidence algorithm for behavior on potential UOR-2 ACK usage, the confidence algorithm for
determining UOR-2 ACK usage must be carefully designed, with k_3 and determining UOR-2 ACK usage must be carefully designed, with k_3 and
n_3 having values much larger than 1, as UOR-2 ACKs can be sent from n_3 having values much larger than 1, as UOR-2 ACKs can be sent from
a decompressor for other purposes than to actually acknowledge the a decompressor for other purposes than to actually acknowledge the
UOR-2 packet, e.g. to send feedback data such as clock resolution, or 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 to initiate a mode transfer. Before adapting a compressor to the
potential use of UOR-2 ACKs, the implementer must ensure all aspects potential use of UOR-2 ACKs, the implementer must ensure all aspects
are considered by the confidence algorithm. are considered by the confidence algorithm.
8.13. Compression of SN in AH and GRE extension headers
The AH and GRE sequence numbers are compressed exactly as the ESP
sequence number. Specifically, the principle for when to include or
exclude the AH and GRE sequence numbers is the same as for ESP, i.e.
the following rule applies to all these sequence numbers:
Sequence Number: Not sent when the offset from the sequence number
of the compressed header is constant. When the
offset is not constant, the sequence number is
compressed by sending LSBs. See 5.8.4.
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 23, line 45 skipping to change at page 23, 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 September 9, 2005. This Internet-Draft expires October 4, 2005.
 End of changes. 

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