Robust Header Compression R. Kapoor, Qualcomm Internet-Draft C. Trabelsi, Lucent Q. Zhang, Lucent Expires: January 14, 2007 July 14, 2006 RObust Header Compression: RTP, UDP, ESP Profiles with Efficient Support for Reordering draft-kapoor-rohc-profiles-reordering-00.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. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 14, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Kapoor, et. al. Expires January 14, 2007 [Page 1] Internet-Draft RoHC Profiles with Reordering July 2006 Abstract This document specifies ROHC (Robust Header Compression) profiles for compression of RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP and ESP/IP (Encapsulating Security Payload) headers. These profiles inherit most of their functionality from the RFC 3095 profiles, with the exception that efficient support for out-of-order delivery of packets is added to these new profiles. The profiles defined in this document do not provide mechanisms to alleviate the issues with reordering in the R mode, and these profiles SHOULD be used only in the U/O modes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Tradeoff between Robustness to Losses and Reordering . . . . . 3 4. Changes from RFC 3095 profiles . . . . . . . . . . . . . . . . 4 4.1. Change to IR packet . . . . . . . . . . . . . . . . . . . 4 5. Recommendations for Use of Profiles . . . . . . . . . . . . . 6 5.1 RoHC Segmentation . . . . . . . . . . . . . . . . . . . . . 6 5.2 List Compression . . . . . . . . . . . . . . . . . . . . . 6 5.3 R-Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . 9 1. Introduction RFC 3095 [1] defines profiles for compression of RTP/UDP/IP (Real- Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, ESP/IP (Encapsulating Security Payload) headers. The profiles defined in [1] have been adopted for use by standardization bodies such as 3GPP2. While the performance of profiles defined in [1] has been found to be robust and efficient, one key element missing from these profiles is the ability to efficiently handle out-of-order delivery of packets over the RoHC channel. In systems such as HRPD Rev A (standardized by 3GPP2), packets may arrive out-of-order on the air interface due to the use of Automatic Retransmission Request (ARQ) techniques such as Hybrid ARQ (H-ARQ) and/or handoffs. It is imperative for 3GPP2 Kapoor, et. al. Expires January 14, 2007 [Page 2] Internet-Draft RoHC Profiles with Reordering July 2006 systems that RoHC profiles be able to efficiently handle such out-of -order delivery. This document specifies updated versions of the following profiles from [1], updated for efficient out-of-order support: o RTP/UDP/IP : profile 0x0011 (updates profile 0x0001 [RFC3095]) o UDP/IP : profile 0x0012 (updates profile 0x0002 [RFC3095]) o ESP/IP : profile 0x0013 (updates profile 0x0003 [RFC3095]) These updated profiles inherit most of the functionality of the RFC 3095 profiles, with the exception that efficient support for out-of -order delivery packets is added to these new profiles. The profiles defined in this document do not provide mechanisms to alleviate the issues with reordering in the R mode (as described in [2]), and as such, these profiles SHOULD be used only in the U/O modes. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 3. Tradeoff between Robustness to Losses and Reordering As explained clearly in [2], there is an inherent trade-off between the ability of RoHC to handle losses and the degree of out-of-order packets. Figure 1 below shows the interpretation interval of RoHC, divided into two parts: the right hand side for handling losses and the left hand side for handling reordering. The size of the interpretation interval is defined by the number of bits k, carried for a particular field in the compressed packet. <--- interpretation interval (size is 2^k) ----> |------------------+---------------------------| v_ref-p v_ref v_ref + (2^k-1) - p <--- reordering --> <--------- losses ---------> The value of p defines the degree of reordering that can be tolerated by the decompressor, while the rest of the interpretation interval with size (2^k-1) - p defines the degree of tolerance to Kapoor, et. al. Expires January 14, 2007 [Page 3] Internet-Draft RoHC Profiles with Reordering July 2006 consecutive losses. Note that the value of p can be increased to increase robustness to reordering at the cost of decreasing robustness to consecutive losses, and vice versa. If behavior of a particular link in terms of degree of reordering and consecutive losses is known, it will be possible to configure the appropriate value of p, which achieves the best performance. This ability to configure the value of p will be of particular use to 3GPP2 systems, where behavior of airlink is well characterized. On the other hand, for the profiles defined in [1], the p value is defined as follows in RFC 3095: --- For the RTP profile, Section 5.7 defines the interpretation interval for the RTP Sequence Number as: p = 1 if bits(SN) <= 4 p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 --- The UDP profile always uses p = -1 when interpreting the Sequence Number (Section 5.11 of [1]). --- The value of p for the ESP-based Sequence Number is defined in a similar way as the RTP Sequence Number in the ROHC RTP profile (Section 5.12 of [1]). Thus, the profiles defined in [1] do not allow systems using RoHC to configure the appropriate value of p based on their particular requirements. This draft adds this functionality to the RoHC profiles defined in this document. 4. Changes from RFC 3095 Profiles In order to support a configurable p value, mechanisms to communicate this value from compressor to decompressor need to be defined. This section lists the changes to the new profiles for support of such functionality. It should be noted that the configured p value only defines the p values for Sequence Numbers (i.e., RTP SN for the RTP profile, UDP SN for the UDP profile and ESP SN for the ESP profile). All other fields such as RTP Timestamp (RTP TS) and IP Identification (IP-ID) have the same definition of p as in [1]. 4.1 Change to IR packet The IR packet for the new profiles defined in this document has the same properties as that defined in [1]. The structure of the IR packet for the new profiles is shown below: Kapoor, et. al. Expires January 14, 2007 [Page 4] Internet-Draft RoHC Profiles with Reordering July 2006 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- | Add-CID octet | if for small CIDs and CID != 0 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 | D | +---+---+---+---+---+---+---+---+ | | / 0-2 octets of CID info / 1-2 octets if for large CIDs | | +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | RR | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | | Static chain | variable length | | +---+---+---+---+---+---+---+---+ | | | Dynamic chain | present if D = 1, variable length | | - - - - - - - - - - - - - - - - | | | Payload | variable length | | RR: Reorder Ratio. This defines the part of the interpretation interval that handles out-of-order packets. RR can take the following values, with p taking the corresponding values: 0: REORDERING_NONE; p = -1 1: REORDERING_QUARTER; p = ((2^k) / 4) - 1 2: REORDERING_HALF; p = ((2^k) / 2) - 1 3: REORDERING_THREEQUARTERS; p = ((2^k) * 3) / 4) - 1 where 2^k is the size of the interpretation interval. Note that the calculation of the CRC now also includes the RR bits (the CRC is calculated in the same way as in [1]). Also, note that the only difference between this IR packet and that defined in [1] is the addition of the octet carrying the RR field. The profile field can take the value of any of the 3 new profiles defined in this document (the profile field is represented in an IR packet as defined in Section 5.2.3 of [1]). Kapoor, et. al. Expires January 14, 2007 [Page 5] Internet-Draft RoHC Profiles with Reordering July 2006 5. Recommendations for Use of Profiles This section provides recommendations for use of the profiles defined in this document. These recommendations follow from the discussion presented in [2]. 5.1 RoHC Segmentation The segmentation functionality, defined in Section 5.2.5 of [1], relies on in-order delivery of segments. Thus, RoHC segmentation should not be used with the profiles defined in this document. 5.2 List Compression Reference-based list compression, as defined in Section 5.8 of [1], may suffer from reordering vulnerabilities (as described in [2]). It is thus, recommended, that for the profiles defined in this document, only the "Generic Scheme" for list encoding be used. 5.3 R-Mode [2] points out a number of issues related to packets being reordered in the R-mode. For example, if updating packets were reordered, this can cause the compressor and decompressor to lose synchronization with each other, referred to as the "missing reference" problem. Also, if non-updating and updating packets were reordered, this can cause packets to be erroneously decompressed. Moreover, in this case, since decompression of R-0 and R-1* packets cannot be verified due to lack of a CRC, erroneous packets may be forwarded to the upper layers. The profiles defined in this document do not provide for any mechanism to alleviate such issues with reordering in the R-Mode. It should be noted here that the intention when defining these profiles is to operate them only in the U/O modes. Thus, these profiles SHOULD be used only in the U/O modes. 6. Security Considerations This document does not introduce additional security risks to [1]. Kapoor, et. al. Expires January 14, 2007 [Page 6] Internet-Draft RoHC Profiles with Reordering July 2006 7. IANA Considerations The ROHC profile identifiers 0x00XX <# Editor's Note: To be replaced before publication #> have been reserved by the IANA for the profiles defined in this document. <# Editor's Note: To be removed before publication #> The following is the suggested registration in the "RObust Header Compression (ROHC) Profile Identifiers" name space for the profiles defined in this document: Profile Usage Document 0x0011 ROHC RTP-reordering RFCXXXX 0x0012 ROHC UDP-reordering RFCXXXX 0x0013 ROHC ESP-reordering RFCXXXX 8. Acknowledgements The authors would like to thank the people who have contributed to the RoHC specifications. 9. Normative References [1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [2] Pelletier, G., Jonsson, L-E., and Sandlund, K., "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, June 2004. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Kapoor, et. al. Expires January 14, 2007 [Page 7] Internet-Draft RoHC Profiles with Reordering July 2006 Authors' Addresses Rohit Kapoor Qualcomm 5775, Morehouse Drive, San Diego, USA Phone: 1-858-845-1161 Email: rkapoor@qualcomm.com Chokri Trabelsi Lucent Technologies 67 Whippany Rd Whippany NJ, USA Phone: 1-973-386-2309 Email: ctrabelsi@lucent.com Qinqing Zhang Lucent Technologies 67 Whippany Rd Whippany NJ, USA Phone: 1-973-428-7835 Email: qinqing@lucent.com Kapoor, et. al. Expires January 14, 2007 [Page 8] Internet-Draft RoHC Profiles with Reordering July 2006 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-ipr@ietf.org. 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. 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. Kapoor, et. al. Expires January 14, 2007 [Page 9]