idnits 2.17.00 (12 Aug 2021) /tmp/idnits9680/draft-bormann-rohc-avt-crtp-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 363. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2007) is 5567 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-rohc-rfc3095bis-framework has been published as RFC 4995 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Robust Header Compression C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track February 2007 5 Expires: August 5, 2007 7 A ROHC Profile for CRTP (ROHC-CRTP) 8 draft-bormann-rohc-avt-crtp-profile-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 5, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies a ROHC (Robust Header Compression) profile 42 for header compression of packets using the legacy header compression 43 schemes defined by IP compression (RFC 2507), CRTP (RFC 2508), and 44 ECRTP (RFC 3545). The profile, called ROHC-CRTP, enables the use of 45 these legacy header compression schemes in the context of a ROHC 46 channel, making use of the mechanisms offered by the ROHC framework. 48 $Id: draft-bormann-rohc-avt-crtp-profile.xml,v 1.5 2007/03/20 49 23:20:59 cabo Exp $ 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Profile Operation . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Creating Contexts . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Using Contexts . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Compressed Packet Formats . . . . . . . . . . . . . . . . . . . 5 59 4. Parameter Values . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security considerations . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Introduction 72 Work on the original ROHC standard [RFC3095] was started to obtain a 73 higher-performance replacement for previous header compression 74 standards for voice over IP applications such as RFC 2508. ROHC was 75 defined as the combination of (1) a framework, now separately defined 76 in [I-D.ietf-rohc-rfc3095bis-framework], which specifies the 77 management of a ROHC channel for the transmission of multiple header 78 compressed flows of possible different characteristics, and (2) a 79 number of profiles, which specify the specific header compression 80 schemes in use. 82 Now that ROHC has sprouted more than a dozen profiles and variants of 83 profiles, it is the obvious framework to use when undertaking new 84 work on integrating header compression into an environment. However, 85 some of the header compression schemes used previous to ROHC are 86 still popular, and it would be beneficial to be able to transport 87 them on a ROHC channel together with its more modern siblings. 89 This specification defines how to transport flows compressed by IP 90 compression (RFC 2507), CRTP (RFC 2508), and/or ECRTP (RFC 3545) in a 91 ROHC channel. To this end, it defines a new ROHC profile, called the 92 legacy profile or ROHC-CRTP for short, as well as RFC 3241 93 negotiation suboptions to negotiate non-default parameters for the 94 compression schemes. 96 Note that, as the usage of TCP and TCP options has significantly 97 moved on since 1990, there is very little reason to continue using 98 RFC 1144 in a modern network when newer alternatives are available; 99 this legacy header compression scheme is therefore not supported by 100 this specification. 102 2. Profile Operation 104 This section gives an overview of the operation of ROHC-CRTP. 106 The ROHC-CRTP protocol operates by mapping legacy header compression 107 packet types into the ROHC framework. The actual protocol operation 108 of the legacy schemes is not affected, but the encoding of the first 109 few bytes of the legacy headers sometimes has to be adapted. 111 2.1. Creating Contexts 113 A ROHC-CRTP context is created using an IR (initialization/refresh) 114 packet, which contains a ROHC framework header followed by the ROHC- 115 CRTP packet type FULL_HEADER, modified as follows: 117 If the x bit is set to 1, all bytes that would have carried CID bits 118 or been entirely set to 0 by section 5.3.1 in RFC2507 are elided. If 119 the x bit is set to 0, all these bytes are transmitted as zero. 121 0 1 2 3 4 5 6 7 122 --- --- --- --- --- --- --- --- 123 : Add-CID octet : if CID 1-15 and small CID 124 +---+---+---+---+---+---+---+---+ 125 | 1 1 1 1 1 1 0 | x | IR type octet 126 +---+---+---+---+---+---+---+---+ 127 : : 128 / 0-2 octets of CID / 1 or 2 octets if large CIDs 129 : : 130 +---+---+---+---+---+---+---+---+ 131 | Profile | 1 octet 132 +---+---+---+---+---+---+---+---+ 133 | CRC | 1 octet 134 +---+---+---+---+---+---+---+---+ 135 : : 136 / FULL-HEADER / Legacy FULL-HEADER Packet 137 : : 138 +---+---+---+---+---+---+---+---+ 140 The profile ID is chosen based on the nature of the packet: If it is 141 a TCP packet (and will thus entertain COMPRESSED_TCP and 142 COMPRESSED_TCP_NODELTA headers), the profile ID is 0x0074; otherwise 143 (Non-TCP), the profile ID is 0x0075. 145 The 8-bit CRC foreseen by the ROHC framework for IR headers is 146 defined in this profile to only cover the framework header (the 147 minimum range as defined in section 5.3.1.1 of 148 [I-D.ietf-rohc-rfc3095bis-framework]). (Note that this means the CRC 149 does not protect the legacy full header; there is no change in the 150 protection of this header from the legacy operation.) 152 Legacy CIDs and ROHC CIDs are mapped to each other in an appropriate, 153 locally defined way. Note that the CID number used in the ROHC 154 framework is unique in the channel; the trick used by RFC2507 for 155 separating a TCP and a non-TCP number space does not apply in ROHC. 156 (Where an existing implementation cannot easily be changed, legacy 157 TCP CIDs n can be translated into ROHC CIDs 2n, and legacy UDP CIDs n 158 can be translated into ROHC CIDs 2n+1 for CIDs allocated by this 159 implementation.) 161 2.2. Using Contexts 163 ROHC-CRTP packets with headers whose names start with COMPRESSED are 164 sent with profile-specific CO headers, as detailed in Section 3. 166 2.3. Feedback 168 CONTEXT_STATE ROHC-CRTP packets are carried in ROHC feedback 169 messages. The CONTEXT_STATE packets are disassembled into the 170 context state items; each of the two-byte state items is sent within 171 a separate ROHC FEEDBACK-2 message, preceded by one byte composed of 172 the Acktype (ROHC framework) and the 6 LSBs of the type code (1 or 2 173 for the basic types; note that the difference between 1 and 2 is 174 insignificant here). 176 3. Compressed Packet Formats 178 This section defines the transmission of the various COMPRESSED_X 179 packet formats used in ROHC-CRTP. 181 The general prodecure for encapsulating a COMPRESSED_X packet in ROHC 182 is as follows: 183 1. Remove the packet type identifier and any leading legacy CID 184 bytes. 185 2. Use the profile-specific format as defined below. 186 3. Encapsulate the result into the framework standard structure, 187 filling the type-indication/body bytes by the bytes outlined 188 below. 190 0 x-1 x 7 191 --- --- --- --- --- --- --- --- 192 : Add-CID octet : if CID 1-15 and small CIDs 193 +--- --- --- --- ---+--- --- ---+ 194 | type indication | body | 1 octet (8-x bits of body) 195 +--- --- --- --- ---+--- --- ---+ 196 : : 197 / 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs 198 : : 199 +---+---+---+---+---+---+---+---+ 200 / body / variable length 201 +---+---+---+---+---+---+---+---+ 203 COMPRESSED_TCP headers are only supported in profile 0x0074. If the 204 R-bit is zero, the header (as modified by removing CID bytes) is 205 encapsulated as is (the zero bit serves as the type indication 206 discriminator). If the R-bit is one, the discriminator byte 207 0b11000001 is prefixed to the CID-less legcay compressed packet. 209 COMPRESSED_TCP_NODELTA headers are only supported in profile 0x0074. 210 A discriminator byte 0b11000010 is prefixed to the CID-less legcay 211 compressed packet. 213 COMPRESSED_NON_TCP headers are only supported in profile 0x0075. A 214 discriminator byte 0b1000100 is prefixed to the CID-less legcay 215 compressed packet. 217 COMPRESSED_RTP_8 and COMPRESSED_RTP_16 packets are only supported in 218 profile 0x0075; they look the same after removing the CIDs. If the 219 M-bit is zero, the header (as modified by removing CID bytes) is 220 encapsulated as is (the zero bit serves as the type indication 221 discriminator). If the M-bit is one, the discriminator byte 222 0b10000001 is prefixed to the CID-less legcay compressed packet. 224 COMPRESSED_UDP_8 and COMPRESSED_UDP_16 packets are only supported in 225 profile 0x0075; they look the same after removing the CIDs. A 226 discriminator byte 0b10000010 is prefixed to the CID-less legcay 227 compressed packet. 229 4. Parameter Values 231 RFC 3544 defines a number of parameter values that can be negotiated 232 for IP compression, CRTP, and ECRTP. These parameters can be 233 explicitly set by the CRTP suboption (see below), or they can be 234 derived from the respective ROHC parameters. In the absence of the 235 CRTP suboption, the following CRTP parameters are considered 236 negotiated by ROHC-CRTP: 237 1. TCP_SPACE(CRTP) = MAX_CID(ROHC) 238 2. NON_TCP_SPACE(CRTP) = MAX_CID(ROHC) 239 3. F_MAX_PERIOD(CRTP) = 256 240 4. F_MAX_TIME(CRTP) = 5 241 5. MAX_HEADER(CRTP) = MAX_HEADER(ROHC) 243 The ROHC CRTP suboption, if present, looks exactly like the RFC 3544 244 configuration option, except that the "Type" value (2, taken out of 245 the NCP configuration option space) is replaced by the value 246 __IANA__TYPE__ (taken out of the ROHC configuration suboption space). 248 5. Security considerations 250 The security considerations of [RFC3095] apply. 252 6. IANA Considerations 254 The ROHC profile identifiers 0x0074 and 0x0075 [# Editor's Note: To 255 be replaced before publication #] have been reserved by the IANA for 256 the profile defined in this document. 258 The ROHC-CRTP suboption identifier __IANA__TYPE__ has been reserved 259 by the IANA for the configuration suboption defined in this document. 261 [# Editor's Note: rest of this section to be removed before 262 publication: #] 264 Two ROHC profile identifiers must be reserved by the IANA for the new 265 profile defined in this document. A suggested registration in the 266 "RObust Header Compression (ROHC) Profile Identifiers" name space 267 would then be: 269 Profile Usage Reference 270 0x0074 ROHC CRTP (TCP) [RFC XXXX (this)] 271 0x0075 ROHC CRTP (non-TCP) [RFC XXXX (this)] 273 Author's note: This suggestion must be updated before sending to 274 IANA. 276 The suggested value for the ROHC-CRTP suboption identifier 277 __IANA__TYPE__ is 2, as this would minimize the effort of translating 278 a legacy configuration option into a ROHC configuration suboption. 280 7. Contributors 282 The author would like to thank Ghyslain Pelletier, who opposed 283 defining this profile from day 1 and in the ensuing protracted 284 discussions helped the author sharpen the requirements for this 285 profile. 287 8. Acknowledgements 289 This document was prompted by the work on HCoIPsec by Emre Ertekin, 290 Chris Christou, and others. 292 The suggested profile numbers 0x0074 and 0x0075 have been inspired by 293 the nostalgic song "'74 - '75" by The Connells. 295 9. References 297 9.1. Normative References 299 [I-D.ietf-rohc-rfc3095bis-framework] 300 Jonsson, L., "The RObust Header Compression (ROHC) 301 Framework", draft-ietf-rohc-rfc3095bis-framework-01 (work 302 in progress), July 2006. 304 9.2. Informative References 306 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 307 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 308 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 309 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 310 Compression (ROHC): Framework and four profiles: RTP, UDP, 311 ESP, and uncompressed", RFC 3095, July 2001. 313 Author's Address 315 Carsten Bormann 316 Universitaet Bremen TZI 317 Postfach 330440 318 Bremen D-28334 319 Germany 321 Phone: +49 421 218 7024 322 Fax: +49 421 218 7000 323 Email: cabo@tzi.org 325 Full Copyright Statement 327 Copyright (C) The IETF Trust (2007). 329 This document is subject to the rights, licenses and restrictions 330 contained in BCP 78, and except as set forth therein, the authors 331 retain all their rights. 333 This document and the information contained herein are provided on an 334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 336 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 337 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 338 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Intellectual Property 343 The IETF takes no position regarding the validity or scope of any 344 Intellectual Property Rights or other rights that might be claimed to 345 pertain to the implementation or use of the technology described in 346 this document or the extent to which any license under such rights 347 might or might not be available; nor does it represent that it has 348 made any independent effort to identify any such rights. Information 349 on the procedures with respect to rights in RFC documents can be 350 found in BCP 78 and BCP 79. 352 Copies of IPR disclosures made to the IETF Secretariat and any 353 assurances of licenses to be made available, or the result of an 354 attempt made to obtain a general license or permission for the use of 355 such proprietary rights by implementers or users of this 356 specification can be obtained from the IETF on-line IPR repository at 357 http://www.ietf.org/ipr. 359 The IETF invites any interested party to bring to its attention any 360 copyrights, patents or patent applications, or other proprietary 361 rights that may cover technology that may be required to implement 362 this standard. Please address the information to the IETF at 363 ietf-ipr@ietf.org. 365 Acknowledgment 367 Funding for the RFC Editor function is provided by the IETF 368 Administrative Support Activity (IASA).