draft-ietf-rohc-rtp-impl-guide-15.txt   draft-ietf-rohc-rtp-impl-guide-16.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT K. Sandlund INTERNET-DRAFT K. Sandlund
Expires: February 2006 P. Kremer Expires: May 2006 G. Pelletier
P. Kremer
Ericsson Ericsson
August 26, 2005 November 23, 2005
The RFC 3095 Implementer's Guide The RFC 3095 Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-15.txt> <draft-ietf-rohc-rtp-impl-guide-16.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 BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, each author accepts the provisions By submitting this Internet-Draft, each author accepts the provisions
of Section 3 of BCP 78. of Section 3 of BCP 78.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.8. Using timer-based compression..............................10 4.8. Using timer-based compression..............................10
5. List compression issues.........................................10 5. List compression issues.........................................10
5.1. Generic extension header list..............................10 5.1. Generic extension header list..............................10
5.2. CSRC list items in RTP dynamic chain.......................11 5.2. CSRC list items in RTP dynamic chain.......................11
5.3. RTP dynamic chain..........................................11 5.3. RTP dynamic chain..........................................11
5.4. Compressed lists in UO-1-ID packets........................11 5.4. Compressed lists in UO-1-ID packets........................11
5.5. Bit masks in list compression..............................11 5.5. Bit masks in list compression..............................11
5.6. Headers compressed with list compression...................12 5.6. Headers compressed with list compression...................12
5.7. ESP NULL header list compression...........................12 5.7. ESP NULL header list compression...........................12
5.8. Translation tables and indexes for IP extension headers....12 5.8. Translation tables and indexes for IP extension headers....12
6. Updating properties.............................................12 5.9. Reference list.............................................12
6.1. Implicit updates...........................................12 6. Updating properties.............................................13
6.1. Implicit updates...........................................13
6.2. Updating properties of UO-1*...............................13 6.2. Updating properties of UO-1*...............................13
7. Context management and CID/context re-use.......................13 7. Context management and CID/context re-use.......................14
7.1. The decompressor MUST keep MAX_CID contexts................13 7.1. The decompressor MUST keep MAX_CID contexts................14
7.2. CID/context re-use.........................................13 7.2. CID/context re-use.........................................14
7.2.1. Re-using a CID/context with the same profile..........14 7.2.1. Re-using a CID/context with the same profile..........14
7.2.2. Re-using a CID/context with a different profile.......14 7.2.2. Re-using a CID/context with a different profile.......15
7.3. Context updating properties for IR packets.................15 7.3. Context updating properties for IR packets.................15
8. Other protocol clarifications...................................15 8. Other protocol clarifications...................................15
8.1. Meaning of NBO.............................................15 8.1. Meaning of NBO.............................................15
8.2. IP-ID......................................................15 8.2. IP-ID......................................................15
8.3. Extension-3 in UO-1-ID packets.............................15 8.3. Extension-3 in UO-1-ID packets.............................16
8.4. Extension-3 in UOR-2* packets..............................16 8.4. Extension-3 in UOR-2* packets..............................16
8.5. Multiple SN options in one feedback packet.................16 8.5. Multiple SN options in one feedback packet.................16
8.6. Multiple CRC options in one feedback packet................16 8.6. Multiple CRC options in one feedback packet................17
8.7. Packet decoding during mode transition.....................16 8.7. Packet decoding during mode transition.....................17
8.8. How to respond to lost feedback links?.....................17 8.8. How to respond to lost feedback links?.....................17
8.9. What does "presumed zero if absent" mean on page 88?.......17 8.9. What does "presumed zero if absent" mean on page 88?.......18
8.10. UOR-2 in profile 2 (UDP)..................................17 8.10. UOR-2 in profile 2 (UDP)..................................18
8.11. Sequence number LSB's in IP extension headers.............17 8.11. Sequence number LSB's in IP extension headers.............18
8.12. Expecting UOR-2 ACKs in O-mode............................17 8.12. Expecting UOR-2 ACKs in O-mode............................18
8.13. Compression of SN in AH and GRE extension headers.........18 8.13. Compression of SN in AH and GRE extension headers.........19
9. ROHC negotiation clarifications.................................18 9. ROHC negotiation clarifications.................................19
10. PROFILES suboption in ROHC-over-PPP............................19 10. PROFILES suboption in ROHC-over-PPP............................20
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......19 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......20
12. Security considerations........................................19 12. Security considerations........................................20
13. IANA considerations............................................19 13. IANA considerations............................................20
14. Acknowledgment.................................................19 14. Acknowledgment.................................................20
15. References.....................................................20 15. References.....................................................21
15.1. Normative References......................................20 15.1. Normative References......................................21
15.2. Informative References....................................20 15.2. Informative References....................................21
16. Authors' Addresses.............................................20 16. Authors' Addresses.............................................21
Appendix A - Sample CRC algorithm..................................21 Appendix A - Sample CRC algorithm..................................22
1. Introduction 1. Introduction
RFC 3095 [1] defines the RObust Header Compression (ROHC) framework RFC 3095 [1] defines the RObust Header Compression (ROHC) framework
and profiles for IP, UDP, RTP, and ESP. During implementation and and profiles for IP, UDP, RTP, and ESP. During implementation and
interoperability testing of RFC 3095 some ambiguities and common interoperability testing of RFC 3095 some ambiguities and common
misinterpretations have been identified, as well as a few actual misinterpretations have been identified, as well as a few actual
errors. errors.
This document has been created to summarize all identified issues, This document has been created to summarize all identified issues,
skipping to change at page 12, line 44 skipping to change at page 12, line 44
index (assuming they are not identical). When content of extension index (assuming they are not identical). When content of extension
headers changes, an implementation can choose to either initiate a headers changes, an implementation can choose to either initiate a
new index, or update the existing one. Note that some extensions can new index, or update the existing one. Note that some extensions can
be compressed away also when some fields change, as there are other be compressed away also when some fields change, as there are other
means to explicitly or implicitly convey the changes. means to explicitly or implicitly convey the changes.
When there is more than one IP header, there is more than one list of When there is more than one IP header, there is more than one list of
extension headers, and a translation table is maintained for each extension headers, and a translation table is maintained for each
list independently of one another. list independently of one another.
5.9. Reference list
A list compressed using encoding type 1 (insertion), type 2 (removal)
or type 3 (removal/insertion) uses a coding scheme that is based on
the use of a reference list in the context (identified as ref_id).
It is noted that while it could seem a fair choice to send a type 1
list when ref_id is an empty list, there is no gain in doing so with
respect to using a type 0 list. Sending a type 2 list when ref_id is
an empty list would lead to a failure, while sending a type 3 list
has very little meaning. All these alternatives are currently
possible with how list compression is specified in RFC 3095.
Because of this, a decompressor becomes required to maintain a
sliding window of ref_id lists in R-mode even for the case where no
items are sent as compressed list. To avoid this, the sending of type
1, 2, and 3 compressed list using an empty reference list should thus
be disallowed. Therefore empty lists are not needed to be stored in
the sliding window in the decompressor.
More specifically, when the compressor uses list encoding of type 1,
type 2, and type 3, the ref_id used must refer to a non-empty
reference list, regardless of the operating mode.
6. Updating properties 6. Updating properties
6.1. Implicit updates 6.1. Implicit updates
If an updating packet (e.g. R-0-CRC or UO-0) contains information A context updating packet that contains compressed sequence number
about a specific field X (compressed RTP sequence number, typically), information may also carry information about other fields; in such
then X is updated according to the content of that packet. But this case, these fields are updated according to the content of the
packet implicitly updates all other inferred fields (i.e. RTP packet. The updating packet also implicitly updates inferred fields
timestamp) according to the current mode and the appropriate mapping (e.g. RTP timestamp) according to the current mode and the
function of the updated and the inferred fields. appropriate mapping function of the updated and the inferred fields.
An updating packet thus updates the reference values of all header An updating packet thus updates the reference values of all header
fields, either explicitly or implicitly, with an exception for the fields, either explicitly or implicitly, with an exception for the
UO-1-ID packet, which only updates TS, SN, IP-ID, and sequence UO-1-ID packet, which only updates TS, SN, IP-ID, and sequence
numbers of IP extension headers (see 5.7.3). In UO-mode, all packets numbers of IP extension headers (see 5.7.3). In UO-mode, all packets
are updating packets, while in R-mode all packets with a CRC are are updating packets, while in R-mode all packets with a CRC are
updating packets. updating packets.
For example, a UO-0 packet contains the compressed RTP sequence For example, a UO-0 packet contains the compressed RTP sequence
number (SN). Such a packet also implicitly updates RTP timestamp, number (SN). Such a packet also implicitly updates RTP timestamp,
skipping to change at page 15, line 12 skipping to change at page 15, line 36
highly confident that the new context has successfully been initiated highly confident that the new context has successfully been initiated
at the decompressor. at the decompressor.
7.3. Context updating properties for IR packets 7.3. Context updating properties for IR packets
It should be noted that an IR does not flush the whole context, but It should be noted that an IR does not flush the whole context, but
updates all fields carried in the IR header. Similarly, an IR without updates all fields carried in the IR header. Similarly, an IR without
a dynamic chain simply updates the static part of the context, while a dynamic chain simply updates the static part of the context, while
the rest of the context is left unchanged. the rest of the context is left unchanged.
A consequence of this is that fields that cannot be updated by the IR
packet, e.g. the Translation Tables for list compression, MUST NOT be
invalidated by the decompressor when it assumes context damage.
8. Other protocol clarifications 8. Other protocol clarifications
8.1. Meaning of NBO 8.1. Meaning of NBO
In general, an unset flag indicates the normal operation and a set In general, an unset flag indicates the normal operation and a set
flag indicates unusual behavior. However, in IPv4 dynamic part flag indicates unusual behavior. However, in IPv4 dynamic part
(Section 5.7.7.4), if the 'NBO' bit is set, it means that network (Section 5.7.7.4), if the 'NBO' bit is set, it means that network
byte order is used. byte order is used.
8.2. IP-ID 8.2. IP-ID
skipping to change at page 17, line 16 skipping to change at page 17, line 45
transition procedure, and these packets must not mistakenly be transition procedure, and these packets must not mistakenly be
interpreted as the packets sent by the compressor to indicate interpreted as the packets sent by the compressor to indicate
completed transition. The decompressor side must therefore keep track completed transition. The decompressor side must therefore keep track
of the transition status, e.g. with an additional parameter. If the of the transition status, e.g. with an additional parameter. If the
enhanced transition procedures described in section 3 of this enhanced transition procedures described in section 3 of this
document are used, the D_TRANS parameter can serve this purpose since document are used, the D_TRANS parameter can serve this purpose since
its definition and usage is slightly modified. its definition and usage is slightly modified.
8.8. How to respond to lost feedback links? 8.8. How to respond to lost feedback links?
One potential issue that might have to be considered, depending on Althought this is neither desirable or expected, it may happen that a
link technology, is whether feedback links might get lost, and in link used to carry feedback between two associated instances become
such cases how this is handled. When the compressor is notified that unavailable. If the compressor can be notified of such event, the
the feedback channel is down, the compressor must be able to handle most suitable response in such case is for the compressor to restart
it by restarting compression with creating a new context. Creating a compression for each flow going over the ROHC channel, except for
new context also implies to use a new CID value. flows that are operating in U/O-mode or flows using a CID associated
with the uncompressed profile (profile 0x0000). When restarting
compression, the compressor should use a different CID for each flow
being restarted; this is useful to avoid that packet types for which
both U/O-mode and R-mode share the same type identifier gets
misinterpreted when restarting the flow in U-mode.
Generally, feedback links are not expected to disappear when once Generally, feedback links are not expected to disappear when once
present, but it should be noted that this might be the case for present, but it should be noted that this might be the case for
certain link technologies. certain link technologies.
8.9. What does "presumed zero if absent" mean on page 88? 8.9. What does "presumed zero if absent" mean on page 88?
On page 88, RFC 3095 says that R-P contains the absolute value of RTP On page 88, RFC 3095 says that R-P contains the absolute value of RTP
Padding bit and it's presumed zero if absent. It could be absent Padding bit and it's presumed zero if absent. It could be absent
from RTP header flags and fields, from the extension type 3 or from from RTP header flags and fields, from the extension type 3 or from
the ROHC packet. It's been agreed that the RTP padding bit is the ROHC packet. It's been agreed that the RTP padding bit is
presumed zero if absent from the RTP header flags. presumed zero if absent from the RTP header flags.
8.10. UOR-2 in profile 2 (UDP) 8.10. UOR-2 in profile 2 (UDP)
skipping to change at page 19, line 53 skipping to change at page 20, line 38
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. IANA considerations 13. IANA considerations
This document does not require any IANA actions. This document does not require any IANA actions.
14. Acknowledgment 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, Zhigang Liu, Abigail Surtees, Mark West, Tommy
Mark West, Tommy Lundemo, Alan Kennington and Remi Pelland for their Lundemo, Alan Kennington and Remi Pelland for their contributions and
contributions and comments. comments.
15. References 15. References
15.1. Normative References 15.1. Normative References
[1] C. Bormann, et al., "RObust Header Compression (ROHC) Framework [1] C. Bormann, et al., "RObust Header Compression (ROHC) Framework
and four profiles: RTP, UDP, ESP, and uncompressed", and four profiles: RTP, UDP, ESP, and uncompressed",
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",
skipping to change at page 20, line 42 skipping to change at page 21, line 42
Phone: +46 8 404 29 61 Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
Kristofer Sandlund Kristofer Sandlund
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58 Phone: +46 8 404 41 58
EMail: kristofer.sandlund@ericsson.com EMail: kristofer.sandlund@ericsson.com
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
EMail: ghyslain.pelletier@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
skipping to change at page 23, line 45 skipping to change at page 24, 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 February 26, 2006. This Internet-Draft expires May 23, 2006.
 End of changes. 17 change blocks. 
43 lines changed or deleted 86 lines changed or added

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