Robust Header Compression R. Kapoor, Qualcomm Internet-Draft C. Trabelsi, Lucent Q. Zhang, Lucent Expires: April 22, 2007 October 20, 2006 RObust Header Compression: RTP, UDP, ESP Profiles with Efficient Support for Reordering draft-kapoor-rohc-profiles-reordering-01.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 April 22, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Kapoor, et. al. Expires April 22, 2007 [Page 1] Internet-Draft RoHC Profiles with Reordering October 2006 Abstract This document describes 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. Applicability Statement. . . . . . . . . . . . . . . . . . . . 3 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Tradeoff between Robustness to Losses and Reordering . . . . . 3 5. Changes from RFC 3095 profiles . . . . . . . . . . . . . . . . 4 5.1. Change to IR packet . . . . . . . . . . . . . . . . . . . 5 6. Recommendations for Use of Profiles . . . . . . . . . . . . . 6 6.1 RoHC Segmentation . . . . . . . . . . . . . . . . . . . . . 6 6.2 List Compression . . . . . . . . . . . . . . . . . . . . . 6 6.3 R-Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10.References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1 Normative References . . . . . . . . . . . . . . . . . . . 8 10.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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. 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 such Kapoor, et. al. Expires April 22, 2007 [Page 2] Internet-Draft RoHC Profiles with Reordering October 2006 systems that RoHC profiles be able to efficiently handle such out-of -order delivery. This document describes RoHC profiles that 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. Note: The intended status of this draft at the moment is not yet decided. The profile identifiers will depend on the status of this draft. 2. Applicability Statement ROHC as specified in RFC 3095 [1] does not provide support for reordering. While there is ongoing work to support reordering in RoHCv2 [4], this work is not yet complete and will involve other changes to RoHC. This specification attempts to set out the minimal set of changes to RFC 3095 needed to support reordering. This specification is intended to be used for near-term support of systems which require this functionality. It is not intended to replace RoHCv2's reordering support, and the full RoHCv2 profiles should be the basis of any long term protocol development. 3. 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]. 4. 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. The value of p defines the degree of reordering that can be Kapoor, et. al. Expires April 22, 2007 [Page 3] Internet-Draft RoHC Profiles with Reordering October 2006 tolerated by the decompressor, while the rest of the interpretation interval with size (2^k-1) - p defines the degree of tolerance to 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. <--- interpretation interval (size is 2^k) ----> |------------------+---------------------------| v_ref-p v_ref v_ref + (2^k-1) - p <--- reordering --> <--------- losses ---------> 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. 5. 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 Kapoor, et. al. Expires April 22, 2007 [Page 4] Internet-Draft RoHC Profiles with Reordering October 2006 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]. 5.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: 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 +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | RR | 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 Kapoor, et. al. Expires April 22, 2007 [Page 5] Internet-Draft RoHC Profiles with Reordering October 2006 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]). 6. 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]. 6.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. 6.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. 6.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 Kapoor, et. al. Expires April 22, 2007 [Page 6] Internet-Draft RoHC Profiles with Reordering October 2006 profiles is to operate them only in the U/O modes. Thus, these profiles SHOULD be used only in the U/O modes. 7. Security Considerations This document does not introduce additional security risks to [1]. 8. 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 XXX ROHC RTP-reordering RFCXXXX XXX ROHC UDP-reordering RFCXXXX XXX ROHC ESP-reordering RFCXXXX 9. Acknowledgements The authors would like to thank the people who have contributed to the RoHC specifications. 10. References 10.1 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. Kapoor, et. al. Expires April 22, 2007 [Page 7] Internet-Draft RoHC Profiles with Reordering October 2006 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2 Informative References [4] Pelletier, G., Sandlund, K., "RObust Header Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite", Internet Draft, June 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 April 22, 2007 [Page 8] Internet-Draft RoHC Profiles with Reordering October 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 April 22, 2007 [Page 9]