draft-ietf-rohc-rtp-impl-guide-13.txt   draft-ietf-rohc-rtp-impl-guide-14.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT P. Kremer INTERNET-DRAFT K. Sandlund
Expires: January 2006 Ericsson Expires: February 2006 P. Kremer
July 18, 2005 Ericsson
August 9, 2005
ROHC Implementer's Guide The RFC 3095 Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-13.txt> <draft-ietf-rohc-rtp-impl-guide-14.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 1, line 41 skipping to change at page 1, line 42
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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 a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org. directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
This document clarifies common misinterpretations and some ambiguous RFC 3095 defines the RObust Header Compression (ROHC) framework and
points of RFC 3095, which defines the framework and four profiles of profiles for IP, UDP, RTP, and ESP. This document clarifies
the robust and efficient header compression scheme (ROHC). It also ambiguities and common misinterpretations of RFC 3095, and it also
addresses minor interpretation details of RFC 3241 (ROHC over PPP), corrects some actual errors in the specification. The corrections and
RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles). clarifications provided herein must be followed to get interoperable
These issues have been identified by members of the ROHC working implementations, i.e. this document updates RFC 3095. Further, minor
group, during implementation and at interoperability test events. interpretation details of RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP
profile) and RFC 4109 (ROHC UPD-Lite profiles) are also addressed.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction.....................................................3
2. CRC calculation and coverage issues..............................4 2. CRC calculation and coverage issues..............................3
2.1. CRC calculation.............................................4 2.1. CRC calculation.............................................3
2.2. Padding octet in CRC........................................4 2.2. Padding octet in CRC........................................4
2.3. CRC coverage in CRC feedback options........................4 2.3. CRC coverage in CRC feedback options........................4
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..........5 3.1. Modified transition logic for enhanced transitions..........5
3.2. Transition from Reliable to Optimistic mode.................6 3.2. Transition from Reliable to Optimistic mode.................6
3.3. Transition to Unidirectional mode...........................6 3.3. Transition to Unidirectional mode...........................6
4. Timestamp encoding considerations................................7 4. Timestamp encoding considerations................................7
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.........................................11 5. List compression issues.........................................10
5.1. Generic extension header list..............................11 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.......................10
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..............................12 5.5. Bit masks in list compression..............................11
5.6. Headers compressed with list compression...................12 5.6. Headers compressed with list compression...................11
5.7. ESP NULL header list compression...........................12 5.7. ESP NULL header list compression...........................12
6. Updating properties.............................................13 6. Updating properties.............................................12
6.1. Implicit updates...........................................13 6.1. Implicit updates...........................................12
6.2. Updating properties of UO-1*...............................13 6.2. Updating properties of UO-1*...............................12
7. Context management and CID/context re-use.......................14 7. Context management and CID/context re-use.......................13
7.1. Compressor and decompressor MUST keep MAX_CID contexts.....14 7.1. Compressor and decompressor MUST keep MAX_CID contexts.....13
7.2. CID/context re-use.........................................14 7.2. CID/context re-use.........................................13
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..........13
7.2.2. Re-using a CID/context with a different profile.......15 7.2.2. Re-using a CID/context with a different profile.......14
7.3. Context updating properties for IR packets.................15 7.3. Context updating properties for IR packets.................14
8. Other protocol clarifications...................................16 8. Other protocol clarifications...................................14
8.1. Meaning of NBO.............................................16 8.1. Meaning of NBO.............................................14
8.2. IP-ID......................................................16 8.2. IP-ID......................................................14
8.3. Extension-3 in UO-1-ID packets.............................16 8.3. Extension-3 in UO-1-ID packets.............................15
8.4. Extension-3 in UOR-2* packets..............................17 8.4. Extension-3 in UOR-2* packets..............................15
8.5. Multiple SN options in one feedback packet.................17 8.5. Multiple SN options in one feedback packet.................15
8.6. Multiple CRC options in one feedback packet................17 8.6. Multiple CRC options in one feedback packet................16
8.7. Packet decoding during mode transition.....................17 8.7. Packet decoding during mode transition.....................16
8.8. How to respond to lost feedback links?.....................18 8.8. How to respond to lost feedback links?.....................16
8.9. What does "presumed zero if absent" mean on page 88?.......18 8.9. What does "presumed zero if absent" mean on page 88?.......17
8.10. UOR-2 in profile 2 (UDP)..................................18 8.10. UOR-2 in profile 2 (UDP)..................................17
8.11. Sequence number LSB's in IP extension headers.............18 8.11. Sequence number LSB's in IP extension headers.............17
8.12. Expecting UOR-2 ACKs in O-mode............................18 8.12. Expecting UOR-2 ACKs in O-mode............................17
8.13. Compression of SN in AH and GRE extension headers.........19 8.13. Compression of SN in AH and GRE extension headers.........18
9. ROHC negotiation clarifications.................................20 9. ROHC negotiation clarifications.................................18
10. PROFILES suboption in ROHC-over-PPP............................20 10. PROFILES suboption in ROHC-over-PPP............................18
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......20 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......19
12. Test configuration.............................................21 12. Security considerations........................................19
13. Security considerations........................................21 13. IANA considerations............................................19
14. IANA considerations............................................21 14. Acknowledgment.................................................19
15. Acknowledgment.................................................22 15. References.....................................................19
16. References.....................................................22 15.1. Normative References......................................19
16.1. Normative References......................................22 15.2. Informative References....................................19
16.2. Informative References....................................22 16. Authors' Addresses.............................................20
17. Authors' Addresses.............................................22 Appendix A - Sample CRC algorithm..................................21
Appendix A - Sample CRC algorithm..................................23
Appendix B - Potential improvements in updated profiles............25
1. Introduction 1. Introduction
ROHC [1] defines a robust and efficient header compression algorithm, RFC 3095 [1] defines the RObust Header Compression (ROHC) framework
and its description is rather long and complex. During the and profiles for IP, UDP, RTP, and ESP. During implementation and
implementation and the interoperability tests of the algorithm some interoperability testing of RFC 3095 some ambiguities and common
unclear areas have been identified. This document tries to collect misinterpretations have been identified, as well as a few actual
and clarify these points. A few minor interpretation details of RFC errors.
3241 [2] (ROHC over PPP), RFC 3843 [3] (ROHC IP-only profile), and
RFC 4019 [5] (ROHC UDP-Lite profiles) are also addressed in this This document has been created to summarize all identified issues,
document (chapter 10-11). Note that all section and chapter and provide the clarifications and corrections needed to make
references in this document refer to [1], where not stated otherwise. creation of interoperable implementations possible. It should thus be
noted that it is essential that implementers of RFC 3095 follow the
corrections and clarifications provided herein, i.e. this document
constitute an update to RFC 3095. When referring to RFC 3095, this
document should therefore also be referenced.
A few minor interpretation details of RFC 3241 [2] (ROHC over PPP),
RFC 3843 [3] (ROHC IP-only profile), and RFC 4019 [5] (ROHC UDP-Lite
profiles) are also addressed in this document (chapter 10-11).
Note that all section and chapter references in this document refer
to [1], where not stated otherwise.
2. CRC calculation and coverage issues 2. CRC calculation and coverage issues
2.1. CRC calculation 2.1. 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
skipping to change at page 21, line 5 skipping to change at page 19, line 18
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
there will be both a SID and a SID2 context value. there will be both a SID and a SID2 context value.
12. Test configuration 12. Security considerations
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
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
IP/UDP flow), which can transmit ROHC packets. Having these two
interfaces several configurations can be set up. The figure below
shows sample configurations that can be used for testing a ROHC
implementation:
IP/UDP/RTP +------------+ ROHC +--------------+ IP/UDP/RTP
packets | ROHC | packets | ROHC | packets
---------->| Compressor |-----> ----->| Decompressor |---------->
+------------+ +--------------+
Unfortunately, comparing the IP/UDP/RTP packets at the endpoints can
only show whether the reconstructed stream differs from the original
or not. In order to identify the place of the error more detailed
tests are needed. The next figure shows another possible scenario:
IP/UDP/RTP +------------+ ROHC ROHC +--------------+ IP/UDP/RTP
packets | ROHC | packets packets | ROHC | packets
+----->| Compressor |----->+ +----->| Decompressor |----->+
| +------------+ | | +--------------+ |
| | | |
| +------------+ | | +------------+ |
| | Test | | | | Test | |
+<-----| Equipment |<-----+ +<------| Equipment |<------+
+------------+ +------------+
In the first case, the test equipment generates the RTP stream and
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.
In the second case, it is the test equipment that sends the
compressed ROHC packets and the Decompressor reconstructs the RTP
stream. Since the tester knows the ROHC packets and the
reconstructed RTP stream it can detect if the Decompressor makes a
mistake.
13. Security considerations
This document provides a number of clarifications to [1], but it does This document provides a number of clarifications to [1], but it does
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.
14. IANA considerations 13. IANA considerations
This document does not require any IANA actions. This document does not require any IANA actions.
15. 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, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees,
Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and Mark West, Tommy Lundemo, Alan Kennington and Remi Pelland for their
Remi Pelland for their contributions and comments. contributions and comments.
16. References 15. References
16.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",
RFC 3241, April 2002. RFC 3241, April 2002.
[3] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC): [3] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC):
A Compression Profile for IP", RFC 3843, June 2004. A Compression Profile for IP", RFC 3843, June 2004.
[4] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994. [4] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.
16.2. Informative References 15.2. Informative References
[5] G. Pelletier, "RObust Header Compression (ROHC): Profiles for [5] G. Pelletier, "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005. User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[6] G. Pelletier, L-E. Jonsson, and K. Sandlund, "ROHC over Channels 16. Authors' Addresses
that can Reorder Packets", internet-draft (work in progress),
February 2005. <draft-ietf-rohc-over-reordering-02.txt>
17. Authors' Addresses
Lars-Erik Jonsson Lars-Erik Jonsson
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
Kristofer Sandlund
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58
EMail: kristofer.sandlund@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 25, line 5 skipping to change at page 23, line 5
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);
Appendix B - Potential improvements in updated profiles
B.1. General improvements
B.1.1. Editorial restructuring
Experience has shown that the structure of RFC3095 could had been
much better, and normative specifications could have been less
fragmented. One goal should thus be to do proper restructuring to
make the documentation easier to take in. One fundamental editorial
restructuring is to explicitly define and specify the ROHC framework
in a separate document. The profiles will then be specified in their
own document(s), and will most probably incorporate the updated
profiles from both RFC3095 and the "add-on" specifications ROHC IP-
only and ROHC UDP-Lite into one profile set documentation.
B.1.2. List compression should not be used for IP extension headers
RFC 3095 defines list compression as a generic mechanism ([1],
section 5.8) that is used for both RTP CSRC lists ([1], section
5.8.6) and IP extension headers ([1], section 5.8.4-5.8.5). In the
former case, list compression is indeed very suitable, as the scheme
maps very well to the expected behavior of CSRC items. However, using
list compression for IP extension headers is really hard to justify,
and makes ROHC unnecessary complex. Instead, extension headers should
be treated like all other headers, with static and dynamic chains.
This is the approach taken for ROHC-TCP, and should be applied also
to an updated RFC 3095.
B.1.3. List compression should only use the generic scheme
List compression ([1], section 5.8) defines four different encoding
schemes to be used for compressed lists. There is one generic
encoding scheme, and then three additional optimization schemes based
on reference-based list compression. Implementers have noticed that
using reference-based schemes implies unreasonable decompressor
memory demands and implementation complexity, while the potential
gain is realistically none. The use of the type field in compressed
lists should thus be deprecated and only type 0 encoding should be
allowed.
B.1.4. Multiple operating modes should be avoided, as in ROHC-TCP
RFC 3095 uses several operating modes with complicated transition
procedures to safeguard against incorrect packet interpretation, as
packet formats differ between modes. The multi-mode approach of RFC
3095 has made the specification unnecessary complex, and experience
has shown that this was not a preferable approach. By streamlining
the protocol to one single mode, the number of different packet
formats will be reduced, the compression and decompression control
logic needed will be significantly simplified, mode transition
procedures can be eliminated, non-updating packets can be avoided,
etc. When developing the ROHC TCP profile, the ROHC WG has already
concluded that the RFC 3095 mode concept is not to be used again.
Consequently, there are no explicit modes in ROHC-TCP, but only one
consistent logic is used exclusively, both for unidirectional and
bidirectional operation. An updated version of the RFC 3095 profiles
should follow that approach.
B.1.5. UO-1-ID should not be allowed to carry extension 3
UO-1-ID is the only UO-1 format that can carry an extension (see
section 5.7.3 and 5.7.5 of [1]). The updating properties of UO-1 is
also so that when carrying an extension 3, all fields except SN, TS,
and IP-ID are non-updating, which is a fundamental exception to
normal UO operation. The usefulness of partially updating UO packets
is really questionable. This "feature" is also only available for
contexts with a non-random IP-ID, and is thus mainly a useless
inconsistency. In an updated RTP profile, which is the only profile
using this packet type, UO-1-ID should thus not be allowed to carry
extension 3.
B.1.6. No sequential compression for outer IP-ID
The ROHC 3095 profiles define a mechanism for compression of the IP-
ID, not just for the innermost IP header, but also for a potential
outer (second innermost) IP header (see section 5.7 of [1]). It is
however really unrealistic to expect the outer header IP-ID to be
compressible from the sequence number of the RTP header or a
compressor-generated sequence number, while a ROHC-RTP decompressor
must still be implemented to handle such a case if it indeed happens.
This is extremely far-fetched, and the compressor should instead
simply have to identify an outer IP-ID as either random or constant
(for constant IP-ID handling, see section 3.3 of [3]).
B.1.7. ESP NULL-encryption compression should not compress trailer
The ESP NULL-encryption compression mechanism defined for ROHC
compresses not just the header, but also the trailer of the packet.
Apart from being a conceptual exception in the sense that it does not
only compress the header but also tampers with the payload, the
scheme makes assumptions that reduces its applicability, which is
already very limited, to a single corner case. Considering the
relative complexity of implementing it along with the small gain and
limited applicability, this mechanism should be significantly
simplified. The ESP NULL-encryption compression mechanism is defined
in section 5.8.4.3 of [1].
B.2. Minor improvements
B.2.1. Meaning of CC=0 for CSRC list presence
Regarding the CC field and CSRC list, the following interpretation
has been proposed as an improvement:
"It should be noted that when the value of this CC field is equal to
zero, there is no Generic CSRC list present in the dynamic chain,
i.e. the field comment should have said "variable length, present if
CC > 0". "
B.2.2. Size of list compression table for RTP CSRC
List compression formats are defined with 3 or 7 bit list item index
identifiers (see section 5.8.6.1 of [1]). As there is no additional
explicit restriction on the maximal number of list items, up to 128
items must be supported, which implies a significant memory demand
for an extreme corner-case. One RTP packet can have up to 15 CSRC
items, and that is probably a well over-provisioned number. Since
items can always be re-assigned, it is therefore suggested to have an
upper limit on the number of CSRC list item index identifiers, with a
max value of either 16 or 32.
B.2.3. The p-value for 5-bit SN
For the RFC 3095 RTP profile, p-values for SN fields are defined in
the beginning of section 5.7 of [3], as follows:
p = 1 if bits(SN) <= 4
p = 2^(bits(SN)-5) - 1 if bits(SN) > 4
This would mean p=1 for bits(SN)=4, p=1 for bits(SN)=6, p>1 for bits
(SN)>6, but for bits(SN)=5, p would then be 0. This is illogical, and
obviously a mistake. One reason it was not noticed might be that the
RTP profile does not have any packet format with 5 bits of SN.
However, the ESP profile refer to the RTP profile for p values
(section 5.12 of [1]), and in the ESP profile there are packet
formats with 5 bits of SN. The p-values should thus be redefined as
follows:
p = 1 if bits(SN) <= 5
p = 2^(bits(SN)-5) - 1 if bits(SN) > 5
It should be noted that the UDP profile has a fixed p-value of -1,
motivated by the use of a compressor-generated SN (section 5.11 of
[1]), and is thus not affected by the incorrectly specified p-value,
although the USP profile has packet formats with 5 bits of SN. Note
however the recommendation in section B.2.4.
B.2.4. The UDP profile should have same p-value as other profiles
Since the UDP profile makes use of a compressor-generated SN instead
of an SN taken from an uncompressed header field, it has in section
5.11 of [1] been given a fixed p-value of -1. This made sense, as one
design assumption was in-order delivery from compressor to
decompressor. However, as the interest in using ROHC also over
channels that can not guarantee in-order delivery has gained
momentum, this design choice becomes less appropriate, as described
in [6]. In an updated version of the UDP profile, it should thus be
given the same p-vales as for RTP and ESP, i.e. as outlined in B.2.3,
potentially with an increased' reordering-tolerance, see further
section B.4.
B.2.5. Local repair should be completely optional
In section 5.3.2.2.3-5.3.2.2.5 of [1], possibilities to do local
decompressor repair attempts upon decompression failures are
discussed, and example procedures are described. Section 5.3.2.2.3
says:
A. "First, attempt to determine whether SN LSB wraparound (case 3)
is likely, and if so, attempt a correction. For this, the
algorithm of section 5.3.2.2.4 MAY be used."
and it continues:
B. "Second, if the previous step did not attempt a correction, a
repair should be attempted under the assumption that the
reference SN has been incorrectly updated. For this, the
algorithm of section 5.3.2.2.5 MAY be used."
These are good examples of potential implementation improvements, and
the procedures are described as optional, i.e. with the use of "MAY".
However, both these paragraphs then take one step further and
actually mandates local repair procedures by saying:
C. "If another algorithm is used, it MUST have at least as high a
rate of correct repairs as the one in 5.3.2.2.4 (or 5.3.2.2.5,
respectively).
This should be a local decompressor implementation option, and it is
therefore suggested to exclude the mandating text C.
B.3. Improvements already applied to the IP-only and UPL-Lite profiles
B.3.1. Handling Multiple Levels of IP Headers
The profiles in RFC 3095 can only handle compression of packet
streams with at most two IP headers. The IP-only profile defines a
generic way of handling multiple IP headers (see section 3.2 of [3]).
B.3.2. The CONTEXT_MEMORY Feedback Option
To provide means for a decompressor implementation to have an upper
limit on its available context memory size, the IP-only profile
defines an additional feedback option to use (see section 3.7 of
[3]). The CONTEXT_MEMORY option informs the compressor that the
decompressor does not have sufficient memory resources to handle the
context of the packet stream, as the stream is currently compressed.
B.3.3. Compression of constant IP-ID (IPv4 only)
Most IPv4 stacks assign an IP-ID according to the value of a counter,
increasing by one for each outgoing packet. ROHC-RTP therefore
compresses the IP-ID field using offset IP-ID encoding based on the
RTP SN. For stacks generating IP-ID values using a pseudo-random
number generator, the field is not compressed and is sent as-is in
its entirety as additional octets after the compressed header.
Cases have also been found where an IPv4 stack uses a constant value
for the IP Identifier. When the IP-ID field is constant, it cannot
be compressed using offset IP-ID encoding and the field must be sent
in its entirety, although it is completely static and could had been
completely omitted in compressed headers. The IP-only profile
addresses this problem and defines an additional mechanism to cope
efficiently with constant IP-ID (see section 3.3 of [3]).
B.4. Adding tolerance to reordering between compressor and decompressor
RFC 3095 was written based on the assumption of in-order packet
delivery between compressor and decompressor. Since the publication
of RFC 3095, is has been clear that using ROHC would be desirable
also in environments where in-order delivery can not be guaranteed.
The challenges associated with such usage have been analyzed in an
informational ROHC WG document "ROHC over channels that can reorder
packets" [6], and the finding of that document should be used as a
basis when developing an enhanced ROHC that can tolerate a certain
amount of reordering, possibly a configurable reordering tolerance.
B.5. Implementation stuff that should go out of the spec.
There is a significant amount of implementation ideas given in
chapter 6 of, both potential implementation enhancement,
implementation API parameters, as well as data structures. It is
sometimes useful to have such material being provided in an appendix,
as it can help implementers. However, in this case it has been clear
that in the way these things were included in RFC 3095, more concerns
than benefits were created. There are several reasons for this, one
is that these parts were not included as an appendix, but actually
part of the specification itself. Also, the size and overall
structure of the whole RFC can easily make an implementer confused
about what is actually part of the standard.
In general, it is thus suggested that an update of RFC 3095 should
have larger implementation example material, if any, in an appendix
to make it clearer that it is not part of the actual standard.
Further, reducing the amount of material would be desirable, to make
the whole documentation more concise.
What to do with the various subsections of chapter 6 is discussed
below, along with other informational parts or concepts that can be
questioned.
B.5.1. Reverse decompression
Reverse decompression is described in section 6.1. This is a very
questionable implementation enhancement, and should preferably be
removed, or at least be put in an appendix.
B.5.2. Implementation parameters and signals
In section 6.3, various potential API parameters are defined,
although only informatively, as they are not at all necessary from a
ROHC protocol point of view. Unfortunately, the way this section is
written might make implementer's believe this is actually part of the
standard, as it even makes use of RFC 2119 keywords.
This section should thus be revised, simplified, and it should be
made clear that it is an API parameter proposal, nothing more,
nothing less. The result could potentially be put in an appendix of
the profiles specification.
B.5.3. Decompressor resource limitations
Section 6.4 of discusses how to handle resource limitations at the
decompressor. This is typical implementation guidelines that fits
very well in an "implementation issues" section, and should thus be
kept. Note that the addition of the CONTEXT_MEMORY feedback option
(see B.3.2) affects this discussion, which would have to be updated
accordingly.
B.5.4. Implementation structures
Section 6.5 provides some explanatory material on data structures
that a ROHC implementation will have to maintain in one form or
another. The section explicitly states the explanatory nature of it,
and points out that it is not intended to constrain implementations.
However, it is far from clear whether this material is actually
useful. It should therefore be revised, potentially removed, or at
least put in an appendix.
B.5.5. The state concept
The concept of states (FO/SO), as used in a normative manner
throughout RFC 3095, should be removed from the spec or at least
rewritten so that it becomes clear that this is a descriptive concept
and not at all normative. Mentioning of implementation parameters,
such as k_2/n_2 and k_3/n_3 should be dropped, or it should at least
be made clear that these are just example parameters in example
algorithms. Probably the entire state concept can be dropped, since
it really describes implementation choices. It can be used
informatively, but that should then be made clear.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 32, 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 January 18, 2006. This Internet-Draft expires February 9, 2006.
 End of changes. 

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