Network Working Group L-E. Jonsson INTERNET-DRAFT Ericsson Expires:
September 2006March 24,2007 September 19, 2006 Improvements for the ROHC Profile Set Update <draft-ietf-rohc-rfc3095bis-improvements-02.txt><draft-ietf-rohc-rfc3095bis-improvements-03.txt> Status of this memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. By submitting this Internet-Draft, each author accepts the provisions of Section 3 of BCP 78. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF ROHC WG. Comments should be directed to the ROHC WG mailing list, email@example.com. Abstract RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles. Now with 5 years of ROHC experience, it has been decided to revise RFC 3095 through the development of an updated profile set. This document collects all improvements that have been agreed to be addressed by this updated and improved ROHC revision. Table of Contents 1. Introduction.....................................................2 2. General improvements.............................................3 2.1. Editorial restructuring.....................................3 2.2. List compression should not be used for IP extension headers3 2.3. List compression should only use the generic scheme.........3 2.4. Multiple operating modes should be avoided, as in ROHC-TCP..3 2.5. UO-1-ID should not be allowed to carry extension 3..........4 2.6. No sequential compression for outer IP-ID...................4 2.7. ESP NULL-encryption compression should not compress trailer.4 2.8. CRC calculation should not use STATIC/DYNAMIC separation....4 3. Minor improvements...............................................5 3.1. Meaning of CC=0 for CSRC list presence......................5 3.2. Size of list compression table for RTP CSRC.................5 3.3. The p-value for 5-bit SN....................................5 3.4. The UDP profile should have same p-value as other profiles..6 3.5. Local repair should be completely optional..................6 4. Improvements already applied to the IP-only and UDP-Lite profiles6 4.1. Handling Multiple Levels of IP Headers......................6 4.2. The CONTEXT_MEMORY Feedback Option..........................7 4.3. Compression of constant IP-ID (IPv4 only)...................7 5. Adding tolerance to reordering...................................7 6. Implementation stuff that should go out of the specification.....7 6.1. Reverse decompression.......................................8 6.2. Implementation parameters and signals.......................8 6.3. Decompressor resource limitations...........................8 6.4. Implementation structures...................................8 6.5. The state concept...........................................9 7. Security considerations..........................................9 8. IANA considerations..............................................9 9. Informative References...........................................9 10. Authors Addresses...............................................9 1. Introduction RFC 3095  defines the RObust Header Compression (ROHC) framework and profiles for IP, UDP, RTP and ESP. When specified, ROHC was created to meet many new challenging requirements, and lots of new compression methods were used. With 5 years of ROHC experience, many lessons have been learned when it comes to what parts of RFC 3095 were actually useful, as well as what parts should had been omitted or simplified. This document collects all improvements that have been agreed to be addressed when RFC 3095 is now to be revised through the development of an updated profile set. Note that all section and chapter references in this document refer to , where not stated otherwise. 2. General improvements 2.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. 2.2. List compression should not be used for IP extension headers RFC 3095 defines list compression as a generic mechanism (, section 5.8) that is used for both RTP CSRC lists (, section 5.8.6) and IP extension headers (, 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. 2.3. List compression should only use the generic scheme List compression (, section 5.8) defines four different encoding schemes to be used for compressed lists. There is one generic encoding scheme, and three additional optimization schemes based on reference-based list compression. Implementers have found 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. 2.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. 2.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 ). 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. 2.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 ). 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 ). 2.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 18.104.22.168 of . 2.8. CRC calculation should not use STATIC/DYNAMIC separation The CRC_STATIC and CRC_DYNAMIC separation was intended to reduce the computational complexity of CRC calculation. However, the separation has proven to make implementation painful, and it actually also adds complexity both in terms of data structures and computation. The STATIC/DYNAMIC CRC separation should therefore be deprecated. 3. Minor improvements 3.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". " 3.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 22.214.171.124 of ). 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. 3.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 , 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 ), 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 ), 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 3.4 of this document. 3.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  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 . 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 section 3.3 of this document, potentially with an increased reordering-tolerance, see further section 5 of this document. 3.5. Local repair should be completely optional In section 126.96.36.199.3-188.8.131.52.5 of , possibilities to do local decompressor repair attempts upon decompression failures are looked at, and example procedures are described. Section 184.108.40.206.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 220.127.116.11.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 18.104.22.168.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 22.214.171.124.4 (or 126.96.36.199.5, respectively). This should be a local decompressor implementation option, and it is therefore suggested to exclude the mandating text C. 4. Improvements already applied to the IP-only and UDP-Lite profiles 4.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 ). 4.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 ). 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. 4.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 ). 5. Adding tolerance to reordering 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" , 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. 6. Implementation stuff that should go out of the specification 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. 6.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. 6.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. 6.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 section 4.2 of this document) affects this discussion, which would have to be updated accordingly. 6.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. 6.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. 7. Security considerations This document provides guidelines for how to specify new protocols, and those protocols will of course have to consider security aspects. 8. IANA considerations This document does not require any IANA actions. 9. Informative References  C. Bormann, et al., "RObust Header Compression (ROHC) Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.  L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.  G. Pelletier, L-E. Jonsson, and K. Sandlund, "ROHC over Channels that can Reorder Packets", internet-draft (work in progress), May 2005. <draft-ietf-rohc-over-reordering-03.txt> 10. Authors Addresses Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 29 61 EMail: firstname.lastname@example.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft expires September 24, 2006.March 19, 2007.