Robust Header Compression C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track February 2007 Expires: August 5, 2007 A ROHC Profile for CRTP (ROHC-CRTP) draft-bormann-rohc-avt-crtp-profile-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 August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a ROHC (Robust Header Compression) profile for header compression of packets using the legacy header compression schemes defined by IP compression (RFC 2507), CRTP (RFC 2508), and ECRTP (RFC 3545). The profile, called ROHC-CRTP, enables the use of these legacy header compression schemes in the context of a ROHC channel, making use of the mechanisms offered by the ROHC framework. $Id: draft-bormann-rohc-avt-crtp-profile.xml,v 1.5 2007/03/20 Bormann Expires August 5, 2007 [Page 1] Internet-Draft ROHC-CRTP February 2007 23:20:59 cabo Exp $ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Profile Operation . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Creating Contexts . . . . . . . . . . . . . . . . . . . . . 3 2.2. Using Contexts . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Compressed Packet Formats . . . . . . . . . . . . . . . . . . . 5 4. Parameter Values . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Bormann Expires August 5, 2007 [Page 2] Internet-Draft ROHC-CRTP February 2007 1. Introduction Work on the original ROHC standard [RFC3095] was started to obtain a higher-performance replacement for previous header compression standards for voice over IP applications such as RFC 2508. ROHC was defined as the combination of (1) a framework, now separately defined in [I-D.ietf-rohc-rfc3095bis-framework], which specifies the management of a ROHC channel for the transmission of multiple header compressed flows of possible different characteristics, and (2) a number of profiles, which specify the specific header compression schemes in use. Now that ROHC has sprouted more than a dozen profiles and variants of profiles, it is the obvious framework to use when undertaking new work on integrating header compression into an environment. However, some of the header compression schemes used previous to ROHC are still popular, and it would be beneficial to be able to transport them on a ROHC channel together with its more modern siblings. This specification defines how to transport flows compressed by IP compression (RFC 2507), CRTP (RFC 2508), and/or ECRTP (RFC 3545) in a ROHC channel. To this end, it defines a new ROHC profile, called the legacy profile or ROHC-CRTP for short, as well as RFC 3241 negotiation suboptions to negotiate non-default parameters for the compression schemes. Note that, as the usage of TCP and TCP options has significantly moved on since 1990, there is very little reason to continue using RFC 1144 in a modern network when newer alternatives are available; this legacy header compression scheme is therefore not supported by this specification. 2. Profile Operation This section gives an overview of the operation of ROHC-CRTP. The ROHC-CRTP protocol operates by mapping legacy header compression packet types into the ROHC framework. The actual protocol operation of the legacy schemes is not affected, but the encoding of the first few bytes of the legacy headers sometimes has to be adapted. 2.1. Creating Contexts A ROHC-CRTP context is created using an IR (initialization/refresh) packet, which contains a ROHC framework header followed by the ROHC- CRTP packet type FULL_HEADER, modified as follows: Bormann Expires August 5, 2007 [Page 3] Internet-Draft ROHC-CRTP February 2007 If the x bit is set to 1, all bytes that would have carried CID bits or been entirely set to 0 by section 5.3.1 in RFC2507 are elided. If the x bit is set to 0, all these bytes are transmitted as zero. 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if CID 1-15 and small CID +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 | x | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1 or 2 octets if large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ : : / FULL-HEADER / Legacy FULL-HEADER Packet : : +---+---+---+---+---+---+---+---+ The profile ID is chosen based on the nature of the packet: If it is a TCP packet (and will thus entertain COMPRESSED_TCP and COMPRESSED_TCP_NODELTA headers), the profile ID is 0x0074; otherwise (Non-TCP), the profile ID is 0x0075. The 8-bit CRC foreseen by the ROHC framework for IR headers is defined in this profile to only cover the framework header (the minimum range as defined in section 5.3.1.1 of [I-D.ietf-rohc-rfc3095bis-framework]). (Note that this means the CRC does not protect the legacy full header; there is no change in the protection of this header from the legacy operation.) Legacy CIDs and ROHC CIDs are mapped to each other in an appropriate, locally defined way. Note that the CID number used in the ROHC framework is unique in the channel; the trick used by RFC2507 for separating a TCP and a non-TCP number space does not apply in ROHC. (Where an existing implementation cannot easily be changed, legacy TCP CIDs n can be translated into ROHC CIDs 2n, and legacy UDP CIDs n can be translated into ROHC CIDs 2n+1 for CIDs allocated by this implementation.) 2.2. Using Contexts ROHC-CRTP packets with headers whose names start with COMPRESSED are sent with profile-specific CO headers, as detailed in Section 3. Bormann Expires August 5, 2007 [Page 4] Internet-Draft ROHC-CRTP February 2007 2.3. Feedback CONTEXT_STATE ROHC-CRTP packets are carried in ROHC feedback messages. The CONTEXT_STATE packets are disassembled into the context state items; each of the two-byte state items is sent within a separate ROHC FEEDBACK-2 message, preceded by one byte composed of the Acktype (ROHC framework) and the 6 LSBs of the type code (1 or 2 for the basic types; note that the difference between 1 and 2 is insignificant here). 3. Compressed Packet Formats This section defines the transmission of the various COMPRESSED_X packet formats used in ROHC-CRTP. The general prodecure for encapsulating a COMPRESSED_X packet in ROHC is as follows: 1. Remove the packet type identifier and any leading legacy CID bytes. 2. Use the profile-specific format as defined below. 3. Encapsulate the result into the framework standard structure, filling the type-indication/body bytes by the bytes outlined below. 0 x-1 x 7 --- --- --- --- --- --- --- --- : Add-CID octet : if CID 1-15 and small CIDs +--- --- --- --- ---+--- --- ---+ | type indication | body | 1 octet (8-x bits of body) +--- --- --- --- ---+--- --- ---+ : : / 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs : : +---+---+---+---+---+---+---+---+ / body / variable length +---+---+---+---+---+---+---+---+ COMPRESSED_TCP headers are only supported in profile 0x0074. If the R-bit is zero, the header (as modified by removing CID bytes) is encapsulated as is (the zero bit serves as the type indication discriminator). If the R-bit is one, the discriminator byte 0b11000001 is prefixed to the CID-less legcay compressed packet. COMPRESSED_TCP_NODELTA headers are only supported in profile 0x0074. A discriminator byte 0b11000010 is prefixed to the CID-less legcay compressed packet. Bormann Expires August 5, 2007 [Page 5] Internet-Draft ROHC-CRTP February 2007 COMPRESSED_NON_TCP headers are only supported in profile 0x0075. A discriminator byte 0b1000100 is prefixed to the CID-less legcay compressed packet. COMPRESSED_RTP_8 and COMPRESSED_RTP_16 packets are only supported in profile 0x0075; they look the same after removing the CIDs. If the M-bit is zero, the header (as modified by removing CID bytes) is encapsulated as is (the zero bit serves as the type indication discriminator). If the M-bit is one, the discriminator byte 0b10000001 is prefixed to the CID-less legcay compressed packet. COMPRESSED_UDP_8 and COMPRESSED_UDP_16 packets are only supported in profile 0x0075; they look the same after removing the CIDs. A discriminator byte 0b10000010 is prefixed to the CID-less legcay compressed packet. 4. Parameter Values RFC 3544 defines a number of parameter values that can be negotiated for IP compression, CRTP, and ECRTP. These parameters can be explicitly set by the CRTP suboption (see below), or they can be derived from the respective ROHC parameters. In the absence of the CRTP suboption, the following CRTP parameters are considered negotiated by ROHC-CRTP: 1. TCP_SPACE(CRTP) = MAX_CID(ROHC) 2. NON_TCP_SPACE(CRTP) = MAX_CID(ROHC) 3. F_MAX_PERIOD(CRTP) = 256 4. F_MAX_TIME(CRTP) = 5 5. MAX_HEADER(CRTP) = MAX_HEADER(ROHC) The ROHC CRTP suboption, if present, looks exactly like the RFC 3544 configuration option, except that the "Type" value (2, taken out of the NCP configuration option space) is replaced by the value __IANA__TYPE__ (taken out of the ROHC configuration suboption space). 5. Security considerations The security considerations of [RFC3095] apply. 6. IANA Considerations The ROHC profile identifiers 0x0074 and 0x0075 [# Editor's Note: To be replaced before publication #] have been reserved by the IANA for the profile defined in this document. Bormann Expires August 5, 2007 [Page 6] Internet-Draft ROHC-CRTP February 2007 The ROHC-CRTP suboption identifier __IANA__TYPE__ has been reserved by the IANA for the configuration suboption defined in this document. [# Editor's Note: rest of this section to be removed before publication: #] Two ROHC profile identifiers must be reserved by the IANA for the new profile defined in this document. A suggested registration in the "RObust Header Compression (ROHC) Profile Identifiers" name space would then be: Profile Usage Reference 0x0074 ROHC CRTP (TCP) [RFC XXXX (this)] 0x0075 ROHC CRTP (non-TCP) [RFC XXXX (this)] Author's note: This suggestion must be updated before sending to IANA. The suggested value for the ROHC-CRTP suboption identifier __IANA__TYPE__ is 2, as this would minimize the effort of translating a legacy configuration option into a ROHC configuration suboption. 7. Contributors The author would like to thank Ghyslain Pelletier, who opposed defining this profile from day 1 and in the ensuing protracted discussions helped the author sharpen the requirements for this profile. 8. Acknowledgements This document was prompted by the work on HCoIPsec by Emre Ertekin, Chris Christou, and others. The suggested profile numbers 0x0074 and 0x0075 have been inspired by the nostalgic song "'74 - '75" by The Connells. 9. References 9.1. Normative References [I-D.ietf-rohc-rfc3095bis-framework] Jonsson, L., "The RObust Header Compression (ROHC) Framework", draft-ietf-rohc-rfc3095bis-framework-01 (work in progress), July 2006. Bormann Expires August 5, 2007 [Page 7] Internet-Draft ROHC-CRTP February 2007 9.2. Informative References [RFC3095] 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. Author's Address Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany Phone: +49 421 218 7024 Fax: +49 421 218 7000 Email: cabo@tzi.org Bormann Expires August 5, 2007 [Page 8] Internet-Draft ROHC-CRTP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bormann Expires August 5, 2007 [Page 9]