draft-ietf-rohc-rtp-impl-guide-14.txt   draft-ietf-rohc-rtp-impl-guide-15.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: February 2006 P. Kremer
Ericsson Ericsson
August 9, 2005 August 26, 2005
The RFC 3095 Implementer's Guide The RFC 3095 Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-14.txt> <draft-ietf-rohc-rtp-impl-guide-15.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 28 skipping to change at page 2, line 28
4.1. Encoding used for compressed TS bits........................7 4.1. Encoding used for compressed TS bits........................7
4.2. (De)compression of TS without transmitted TS bits...........7 4.2. (De)compression of TS without transmitted TS bits...........7
4.3. Interpretation intervals for TS encoding....................8 4.3. Interpretation intervals for TS encoding....................8
4.4. TS_STRIDE for scaled timestamp encoding.....................8 4.4. TS_STRIDE for scaled timestamp encoding.....................8
4.5. TS wraparound with scaled timestamp encoding................9 4.5. TS wraparound with scaled timestamp encoding................9
4.6. Recalculating TS_OFFSET.....................................9 4.6. Recalculating TS_OFFSET.....................................9
4.7. TS_STRIDE and the Tsc flag in Extension 3..................10 4.7. TS_STRIDE and the Tsc flag in Extension 3..................10
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.......................10 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...................11 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
6. Updating properties.............................................12 6. Updating properties.............................................12
6.1. Implicit updates...........................................12 6.1. Implicit updates...........................................12
6.2. Updating properties of UO-1*...............................12 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.......................13
7.1. Compressor and decompressor MUST keep MAX_CID contexts.....13 7.1. The decompressor MUST keep MAX_CID contexts................13
7.2. CID/context re-use.........................................13 7.2. CID/context re-use.........................................13
7.2.1. Re-using a CID/context with the same profile..........13 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.......14
7.3. Context updating properties for IR packets.................14 7.3. Context updating properties for IR packets.................15
8. Other protocol clarifications...................................14 8. Other protocol clarifications...................................15
8.1. Meaning of NBO.............................................14 8.1. Meaning of NBO.............................................15
8.2. IP-ID......................................................14 8.2. IP-ID......................................................15
8.3. Extension-3 in UO-1-ID packets.............................15 8.3. Extension-3 in UO-1-ID packets.............................15
8.4. Extension-3 in UOR-2* packets..............................15 8.4. Extension-3 in UOR-2* packets..............................16
8.5. Multiple SN options in one feedback packet.................15 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................16
8.7. Packet decoding during mode transition.....................16 8.7. Packet decoding during mode transition.....................16
8.8. How to respond to lost feedback links?.....................16 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?.......17
8.10. UOR-2 in profile 2 (UDP)..................................17 8.10. UOR-2 in profile 2 (UDP)..................................17
8.11. Sequence number LSB's in IP extension headers.............17 8.11. Sequence number LSB's in IP extension headers.............17
8.12. Expecting UOR-2 ACKs in O-mode............................17 8.12. Expecting UOR-2 ACKs in O-mode............................17
8.13. Compression of SN in AH and GRE extension headers.........18 8.13. Compression of SN in AH and GRE extension headers.........18
9. ROHC negotiation clarifications.................................18 9. ROHC negotiation clarifications.................................18
10. PROFILES suboption in ROHC-over-PPP............................18 10. PROFILES suboption in ROHC-over-PPP............................19
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.......19
12. Security considerations........................................19 12. Security considerations........................................19
13. IANA considerations............................................19 13. IANA considerations............................................19
14. Acknowledgment.................................................19 14. Acknowledgment.................................................19
15. References.....................................................19 15. References.....................................................20
15.1. Normative References......................................19 15.1. Normative References......................................20
15.2. Informative References....................................19 15.2. Informative References....................................20
16. Authors' Addresses.............................................20 16. Authors' Addresses.............................................20
Appendix A - Sample CRC algorithm..................................21 Appendix A - Sample CRC algorithm..................................21
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.
skipping to change at page 10, line 11 skipping to change at page 10, line 11
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.7. 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
value(TS_STRIDE) as is said in the legend for Extension 3 in section
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
TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some
packets until decompressor confidence is obtained. When the TS_STRIDE packets until decompressor confidence is obtained.
field is present in Extension 3, the Tsc flag must thus be set to 0.
When Tsc=1, TS must be scaled using context(TS_STRIDE) and not
value(TS_STRIDE), which is incorrectly stated in the legend for
Extension 3 in section 5.7.5. Instead, if the decompressor receives
an Extension 3 with TS_STRIDE included while Tsc=1, the decompressor
must simply ignore/discard value(TS_STRIDE). Since an unscaled TS is
needed together with TS_STRIDE to recalculate TS_OFFSET, it is thus
meaningless to include TS_STRIDE in Extension 3 if Tsc is set to 1.
4.8. Using timer-based compression 4.8. Using timer-based compression
Timer-based compression of the RTP timestamp, as described in section Timer-based compression of the RTP timestamp, as described in section
4.5.4, may be used to reduce the number of transmitted timestamp bits 4.5.4, may be used to reduce the number of transmitted timestamp bits
(bytes) needed when the timestamp can not be inferred from the SN. It (bytes) needed when the timestamp can not be inferred from the SN. It
should thus be noted that timer-based compression has no influence on should thus be noted that timer-based compression has no influence on
decompression of packets where no timestamp bits are sent, in that decompression of packets where no timestamp bits are sent, in that
case the timestamp is just linearly inferred from the SN (see section case the timestamp is just linearly inferred from the SN (see section
4.2 of this document). 4.2 of this document).
skipping to change at page 12, line 19 skipping to change at page 12, line 22
further be noted that for the Minimal Encapsulation (MINE) header, further be noted that for the Minimal Encapsulation (MINE) header,
there is no explicit discussion of how to compress it, as the header there is no explicit discussion of how to compress it, as the header
is either sent uncompressed or fully compressed away. is either sent uncompressed or fully compressed away.
5.7. ESP NULL header list compression 5.7. ESP NULL header list compression
Due to the offset of the fields in the trailer part of the ESP Due to the offset of the fields in the trailer part of the ESP
header, a compressor must only compress packets containing at most header, a compressor must only compress packets containing at most
one NULL ESP header. one NULL ESP header.
5.8. Translation tables and indexes for IP extension headers
Section 5.8.4 aims at describing how list indexes are associated to
list items and how table lists are built for IP extension headers.
However, the text is not very clear, and it is actually wrong to just
say that an index per type is used, since the same type can appear
several times with different content in one single chain.
In IP extension header list compression, an index is associated with
each individual extension header of an extension header chain. When
there are multiple occurrences of the same extension type (Protocol
Number) within a header chain, each will have to be given its own
index (assuming they are not identical). When content of extension
headers changes, an implementation can choose to either initiate a
new index, or update the existing one. Note that some extensions can
be compressed away also when some fields change, as there are other
means to explicitly or implicitly convey the changes.
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
list independently of one another.
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 If an updating packet (e.g. R-0-CRC or UO-0) contains information
about a specific field X (compressed RTP sequence number, typically), about a specific field X (compressed RTP sequence number, typically),
then X is updated according to the content of that packet. But this then X is updated according to the content of that packet. But this
packet implicitly updates all other inferred fields (i.e. RTP packet implicitly updates all other inferred fields (i.e. RTP
timestamp) according to the current mode and the appropriate mapping timestamp) according to the current mode and the appropriate mapping
function of the updated and the inferred fields. function of the updated and the inferred fields.
skipping to change at page 13, line 7 skipping to change at page 13, line 33
However, also sequence number fields of extension headers must be However, also sequence number fields of extension headers must be
updated, which means the updating properties should be rephrased as: updated, which means the updating properties should be rephrased as:
"The only values provided in extensions that update the context are "The only values provided in extensions that update the context are
the additional bits for the SN, TS, or IP-ID fields. Other values the additional bits for the SN, TS, or IP-ID fields. Other values
provided in extensions do not update the context. Note that provided in extensions do not update the context. Note that
sequence number fields of extension headers are also updated." sequence number fields of extension headers are also updated."
7. Context management and CID/context re-use 7. Context management and CID/context re-use
7.1. Compressor and decompressor MUST keep MAX_CID contexts 7.1. The decompressor MUST keep MAX_CID contexts
As part of the negotiated channel parameters, compressor and As part of the negotiated channel parameters, compressor and
decompressor have through the MAX_CID parameter agreed on the highest decompressor have through the MAX_CID parameter agreed on the highest
context identification (CID) number to be used. By agreeing on context identification (CID) number to be used. By agreeing on
MAX_CID, both compressor and decompressor also agrees to provide MAX_CID, the decompressor also agrees to provide memory resources to
memory resources to host at least MAX_CID+1 contexts, and an host at least MAX_CID+1 contexts, and an established context with a
established context with CID within this negotiated space MUST be CID within this negotiated space MUST be kept by the decompressor
kept by both compressor and decompressor until either the CID gets until either the CID gets re-used, or the channel is taken down or
re-used, or the channel is taken down or re-negotiated. re-negotiated.
7.2. CID/context re-use 7.2. CID/context re-use
As part of the channel negotiation, the maximal number of active As part of the channel negotiation, the maximal number of active
contexts supported is negotiated between the compressor and the contexts supported is negotiated between the compressor and the
decompressor through the MAX_CID parameter. The value of MAX_CID can decompressor through the MAX_CID parameter. The value of MAX_CID can
of course vary enormously between different link scenarios, as well of course vary enormously between different link scenarios, as well
as the load in terms of actual packet streams to compress. Depending as the load in terms of actual packet streams to compress. Depending
on link technology, the ROHC channel lifetime will also vary from on link technology, the ROHC channel lifetime will also vary from
almost permanent to rather short-lived. However, in general it is not almost permanent to rather short-lived. However, in general it is not
skipping to change at page 18, line 45 skipping to change at page 19, line 18
link, the profile used is identified only with the 8 LSB bits, which link, the profile used is identified only with the 8 LSB bits, which
means that the compressor and decompressor must have agreed on which means that the compressor and decompressor must have agreed on which
variant to use for each profile. This can be done in various ways, variant to use for each profile. This can be done in various ways,
but the negotiation protocol must provide means to do it. but the negotiation protocol must provide means to do it.
In conclusion, the negotiation protocol must be able to communicate In conclusion, the negotiation protocol must be able to communicate
to the compressor the set of profiles supported by the decompressor, to the compressor the set of profiles supported by the decompressor,
and when multiple variants of the same profile are available, also and when multiple variants of the same profile are available, also
provide means for the decompressor to know which variant will be used provide means for the decompressor to know which variant will be used
by the compressor. This basically means that the PROFILES set after by the compressor. This basically means that the PROFILES set after
negotiation must not include more than one variant of the same negotiation must not include more than one variant of a profile.
profile.
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 ensure the
the same profile set is negotiated for both IPv4 and IPv6 (IPCP and same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP).
IPV6CP).
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles
In the ROHC IP-only profile, section 3.3 of RFC 3843 [3], a mechanism In the ROHC IP-only profile, section 3.3 of RFC 3843 [3], a mechanism
for encoding of a constant Identification value in IPv4 (constant IP- for encoding of a constant Identification value in IPv4 (constant IP-
ID) is defined. This mechanism is also used by the ROHC UDP-Lite ID) is defined. This mechanism is also used by the ROHC UDP-Lite
profiles, RFC 4019 [5]. profiles, RFC 4019 [5].
It should be noted that the "Constant IP-ID" mechanism applies to It should be noted that the "Constant IP-ID" mechanism applies to
both the inner and the outer IP header, when present , meaning that both the inner and the outer IP header, when present , meaning 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 February 9, 2006. This Internet-Draft expires February 26, 2006.
 End of changes. 

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