idnits 2.17.1 draft-ietf-rohc-rfc3095bis-improvements-03.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 462. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 268: '...thm of section 5.3.2.2.4 MAY be used."...' RFC 2119 keyword, line 275: '...thm of section 5.3.2.2.5 MAY be used."...' RFC 2119 keyword, line 282: '...ithm is used, it MUST have at least as...' Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.1 boilerplate, a section with a similar start was also found: By submitting this Internet-Draft, each author accepts the provisions of Section 3 of BCP 78. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 255 has weird spacing: '...sion of the U...' -- 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 (September 19, 2006) is 6401 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L-E. Jonsson 3 INTERNET-DRAFT Ericsson 4 Expires: March 2007 September 19, 2006 6 Improvements for the ROHC Profile Set Update 7 9 Status of this memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 By submitting this Internet-Draft, each author accepts the provisions 17 of Section 3 of BCP 78. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a submission of the IETF ROHC WG. Comments should be 35 directed to the ROHC WG mailing list, rohc@ietf.org. 37 Abstract 39 RFC 3095 defines the RObust Header Compression (ROHC) framework and 40 profiles. Now with 5 years of ROHC experience, it has been decided to 41 revise RFC 3095 through the development of an updated profile set. 42 This document collects all improvements that have been agreed to be 43 addressed by this updated and improved ROHC revision. 45 Table of Contents 47 1. Introduction.....................................................2 48 2. General improvements.............................................3 49 2.1. Editorial restructuring.....................................3 50 2.2. List compression should not be used for IP extension headers3 51 2.3. List compression should only use the generic scheme.........3 52 2.4. Multiple operating modes should be avoided, as in ROHC-TCP..3 53 2.5. UO-1-ID should not be allowed to carry extension 3..........4 54 2.6. No sequential compression for outer IP-ID...................4 55 2.7. ESP NULL-encryption compression should not compress trailer.4 56 2.8. CRC calculation should not use STATIC/DYNAMIC separation....4 57 3. Minor improvements...............................................5 58 3.1. Meaning of CC=0 for CSRC list presence......................5 59 3.2. Size of list compression table for RTP CSRC.................5 60 3.3. The p-value for 5-bit SN....................................5 61 3.4. The UDP profile should have same p-value as other profiles..6 62 3.5. Local repair should be completely optional..................6 63 4. Improvements already applied to the IP-only and UDP-Lite profiles6 64 4.1. Handling Multiple Levels of IP Headers......................6 65 4.2. The CONTEXT_MEMORY Feedback Option..........................7 66 4.3. Compression of constant IP-ID (IPv4 only)...................7 67 5. Adding tolerance to reordering...................................7 68 6. Implementation stuff that should go out of the specification.....7 69 6.1. Reverse decompression.......................................8 70 6.2. Implementation parameters and signals.......................8 71 6.3. Decompressor resource limitations...........................8 72 6.4. Implementation structures...................................8 73 6.5. The state concept...........................................9 74 7. Security considerations..........................................9 75 8. IANA considerations..............................................9 76 9. Informative References...........................................9 77 10. Authors Addresses...............................................9 79 1. Introduction 81 RFC 3095 [1] defines the RObust Header Compression (ROHC) framework 82 and profiles for IP, UDP, RTP and ESP. When specified, ROHC was 83 created to meet many new challenging requirements, and lots of new 84 compression methods were used. With 5 years of ROHC experience, many 85 lessons have been learned when it comes to what parts of RFC 3095 86 were actually useful, as well as what parts should had been omitted 87 or simplified. This document collects all improvements that have been 88 agreed to be addressed when RFC 3095 is now to be revised through the 89 development of an updated profile set. 91 Note that all section and chapter references in this document refer 92 to [1], where not stated otherwise. 94 2. General improvements 96 2.1. Editorial restructuring 98 Experience has shown that the structure of RFC3095 could had been 99 much better, and normative specifications could have been less 100 fragmented. One goal should thus be to do proper restructuring to 101 make the documentation easier to take in. One fundamental editorial 102 restructuring is to explicitly define and specify the ROHC framework 103 in a separate document. The profiles will then be specified in their 104 own document(s), and will most probably incorporate the updated 105 profiles from both RFC3095 and the "add-on" specifications ROHC IP- 106 only and ROHC UDP-Lite into one profile set documentation. 108 2.2. List compression should not be used for IP extension headers 110 RFC 3095 defines list compression as a generic mechanism ([1], 111 section 5.8) that is used for both RTP CSRC lists ([1], section 112 5.8.6) and IP extension headers ([1], section 5.8.4-5.8.5). In the 113 former case, list compression is indeed very suitable, as the scheme 114 maps very well to the expected behavior of CSRC items. However, using 115 list compression for IP extension headers is really hard to justify, 116 and makes ROHC unnecessary complex. Instead, extension headers should 117 be treated like all other headers, with static and dynamic chains. 118 This is the approach taken for ROHC-TCP, and should be applied also 119 to an updated RFC 3095. 121 2.3. List compression should only use the generic scheme 123 List compression ([1], section 5.8) defines four different encoding 124 schemes to be used for compressed lists. There is one generic 125 encoding scheme, and three additional optimization schemes based on 126 reference-based list compression. Implementers have found that using 127 reference-based schemes implies unreasonable decompressor memory 128 demands and implementation complexity, while the potential gain is 129 realistically none. The use of the type field in compressed lists 130 should thus be deprecated and only type 0 encoding should be allowed. 132 2.4. Multiple operating modes should be avoided, as in ROHC-TCP 134 RFC 3095 uses several operating modes with complicated transition 135 procedures to safeguard against incorrect packet interpretation, as 136 packet formats differ between modes. The multi-mode approach of RFC 137 3095 has made the specification unnecessary complex, and experience 138 has shown that this was not a preferable approach. By streamlining 139 the protocol to one single mode, the number of different packet 140 formats will be reduced, the compression and decompression control 141 logic needed will be significantly simplified, mode transition 142 procedures can be eliminated, non-updating packets can be avoided, 143 etc. When developing the ROHC TCP profile, the ROHC WG has already 144 concluded that the RFC 3095 mode concept is not to be used again. 146 Consequently, there are no explicit modes in ROHC-TCP, but only one 147 consistent logic is used exclusively, both for unidirectional and 148 bidirectional operation. An updated version of the RFC 3095 profiles 149 should follow that approach. 151 2.5. UO-1-ID should not be allowed to carry extension 3 153 UO-1-ID is the only UO-1 format that can carry an extension (see 154 section 5.7.3 and 5.7.5 of [1]). The updating properties of UO-1 is 155 also so that when carrying an extension 3, all fields except SN, TS, 156 and IP-ID are non-updating, which is a fundamental exception to 157 normal UO operation. The usefulness of partially updating UO packets 158 is really questionable. This "feature" is also only available for 159 contexts with a non-random IP-ID, and is thus mainly a useless 160 inconsistency. In an updated RTP profile, which is the only profile 161 using this packet type, UO-1-ID should thus not be allowed to carry 162 extension 3. 164 2.6. No sequential compression for outer IP-ID 166 The ROHC 3095 profiles define a mechanism for compression of the IP- 167 ID, not just for the innermost IP header, but also for a potential 168 outer (second innermost) IP header (see section 5.7 of [1]). It is 169 however really unrealistic to expect the outer header IP-ID to be 170 compressible from the sequence number of the RTP header or a 171 compressor-generated sequence number, while a ROHC-RTP decompressor 172 must still be implemented to handle such a case if it indeed happens. 173 This is extremely far-fetched, and the compressor should instead 174 simply have to identify an outer IP-ID as either random or constant 175 (for constant IP-ID handling, see section 3.3 of [2]). 177 2.7. ESP NULL-encryption compression should not compress trailer 179 The ESP NULL-encryption compression mechanism defined for ROHC 180 compresses not just the header, but also the trailer of the packet. 181 Apart from being a conceptual exception in the sense that it does not 182 only compress the header but also tampers with the payload, the 183 scheme makes assumptions that reduces its applicability, which is 184 already very limited, to a single corner case. Considering the 185 relative complexity of implementing it along with the small gain and 186 limited applicability, this mechanism should be significantly 187 simplified. The ESP NULL-encryption compression mechanism is defined 188 in section 5.8.4.3 of [1]. 190 2.8. CRC calculation should not use STATIC/DYNAMIC separation 192 The CRC_STATIC and CRC_DYNAMIC separation was intended to reduce the 193 computational complexity of CRC calculation. However, the separation 194 has proven to make implementation painful, and it actually also adds 195 complexity both in terms of data structures and computation. The 196 STATIC/DYNAMIC CRC separation should therefore be deprecated. 198 3. Minor improvements 200 3.1. Meaning of CC=0 for CSRC list presence 202 Regarding the CC field and CSRC list, the following interpretation 203 has been proposed as an improvement: 205 "It should be noted that when the value of this CC field is equal to 206 zero, there is no Generic CSRC list present in the dynamic chain, 207 i.e. the field comment should have said "variable length, present if 208 CC > 0". " 210 3.2. Size of list compression table for RTP CSRC 212 List compression formats are defined with 3 or 7 bit list item index 213 identifiers (see section 5.8.6.1 of [1]). As there is no additional 214 explicit restriction on the maximal number of list items, up to 128 215 items must be supported, which implies a significant memory demand 216 for an extreme corner-case. One RTP packet can have up to 15 CSRC 217 items, and that is probably a well over-provisioned number. Since 218 items can always be re-assigned, it is therefore suggested to have an 219 upper limit on the number of CSRC list item index identifiers, with a 220 max value of either 16 or 32. 222 3.3. The p-value for 5-bit SN 224 For the RFC 3095 RTP profile, p-values for SN fields are defined in 225 the beginning of section 5.7 of [1], as follows: 226 p = 1 if bits(SN) <= 4 227 p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 229 This would mean p=1 for bits(SN)=4, p=1 for bits(SN)=6, p>1 for bits 230 (SN)>6, but for bits(SN)=5, p would then be 0. This is illogical, and 231 obviously a mistake. One reason it was not noticed might be that the 232 RTP profile does not have any packet format with 5 bits of SN. 233 However, the ESP profile refer to the RTP profile for p values 234 (section 5.12 of [1]), and in the ESP profile there are packet 235 formats with 5 bits of SN. The p-values should thus be redefined as 236 follows: 237 p = 1 if bits(SN) <= 5 238 p = 2^(bits(SN)-5) - 1 if bits(SN) > 5 240 It should be noted that the UDP profile has a fixed p-value of -1, 241 motivated by the use of a compressor-generated SN (section 5.11 of 242 [1]), and is thus not affected by the incorrectly specified p-value, 243 although the USP profile has packet formats with 5 bits of SN. Note 244 however the recommendation in section 3.4 of this document. 246 3.4. The UDP profile should have same p-value as other profiles 248 Since the UDP profile makes use of a compressor-generated SN instead 249 of an SN taken from an uncompressed header field, it has in section 250 5.11 of [1] been given a fixed p-value of -1. This made sense, as one 251 design assumption was in-order delivery from compressor to 252 decompressor. However, as the interest in using ROHC also over 253 channels that can not guarantee in-order delivery has gained 254 momentum, this design choice becomes less appropriate, as described 255 in [3]. In an updated version of the UDP profile, it should thus be 256 given the same p-vales as for RTP and ESP, i.e. as outlined in 257 section 3.3 of this document, potentially with an increased 258 reordering-tolerance, see further section 5 of this document. 260 3.5. Local repair should be completely optional 262 In section 5.3.2.2.3-5.3.2.2.5 of [1], possibilities to do local 263 decompressor repair attempts upon decompression failures are looked 264 at, and example procedures are described. Section 5.3.2.2.3 says: 266 A. "First, attempt to determine whether SN LSB wraparound (case 3) 267 is likely, and if so, attempt a correction. For this, the 268 algorithm of section 5.3.2.2.4 MAY be used." 270 and it continues: 272 B. "Second, if the previous step did not attempt a correction, a 273 repair should be attempted under the assumption that the 274 reference SN has been incorrectly updated. For this, the 275 algorithm of section 5.3.2.2.5 MAY be used." 277 These are good examples of potential implementation improvements, and 278 the procedures are described as optional, i.e. with the use of "MAY". 279 However, both these paragraphs then take one step further and 280 actually mandates local repair procedures by saying: 282 C. "If another algorithm is used, it MUST have at least as high a 283 rate of correct repairs as the one in 5.3.2.2.4 (or 5.3.2.2.5, 284 respectively). 286 This should be a local decompressor implementation option, and it is 287 therefore suggested to exclude the mandating text C. 289 4. Improvements already applied to the IP-only and UDP-Lite profiles 291 4.1. Handling Multiple Levels of IP Headers 293 The profiles in RFC 3095 can only handle compression of packet 294 streams with at most two IP headers. The IP-only profile defines a 295 generic way of handling multiple IP headers (see section 3.2 of [2]). 297 4.2. The CONTEXT_MEMORY Feedback Option 299 To provide means for a decompressor implementation to have an upper 300 limit on its available context memory size, the IP-only profile 301 defines an additional feedback option to use (see section 3.7 of 302 [2]). The CONTEXT_MEMORY option informs the compressor that the 303 decompressor does not have sufficient memory resources to handle the 304 context of the packet stream, as the stream is currently compressed. 306 4.3. Compression of constant IP-ID (IPv4 only) 308 Most IPv4 stacks assign an IP-ID according to the value of a counter, 309 increasing by one for each outgoing packet. ROHC-RTP therefore 310 compresses the IP-ID field using offset IP-ID encoding based on the 311 RTP SN. For stacks generating IP-ID values using a pseudo-random 312 number generator, the field is not compressed and is sent as-is in 313 its entirety as additional octets after the compressed header. 315 Cases have also been found where an IPv4 stack uses a constant value 316 for the IP Identifier. When the IP-ID field is constant, it cannot 317 be compressed using offset IP-ID encoding and the field must be sent 318 in its entirety, although it is completely static and could had been 319 completely omitted in compressed headers. The IP-only profile 320 addresses this problem and defines an additional mechanism to cope 321 efficiently with constant IP-ID (see section 3.3 of [2]). 323 5. Adding tolerance to reordering 325 RFC 3095 was written based on the assumption of in-order packet 326 delivery between compressor and decompressor. Since the publication 327 of RFC 3095, is has been clear that using ROHC would be desirable 328 also in environments where in-order delivery can not be guaranteed. 329 The challenges associated with such usage have been analyzed in an 330 informational ROHC WG document "ROHC over channels that can reorder 331 packets" [3], and the finding of that document should be used as a 332 basis when developing an enhanced ROHC that can tolerate a certain 333 amount of reordering, possibly a configurable reordering tolerance. 335 6. Implementation stuff that should go out of the specification 337 There is a significant amount of implementation ideas given in 338 chapter 6 of, both potential implementation enhancement, 339 implementation API parameters, as well as data structures. It is 340 sometimes useful to have such material being provided in an appendix, 341 as it can help implementers. However, in this case it has been clear 342 that in the way these things were included in RFC 3095, more concerns 343 than benefits were created. There are several reasons for this, one 344 is that these parts were not included as an appendix, but actually 345 part of the specification itself. Also, the size and overall 346 structure of the whole RFC can easily make an implementer confused 347 about what is actually part of the standard. 349 In general, it is thus suggested that an update of RFC 3095 should 350 have larger implementation example material, if any, in an appendix 351 to make it clearer that it is not part of the actual standard. 352 Further, reducing the amount of material would be desirable, to make 353 the whole documentation more concise. 355 What to do with the various subsections of chapter 6 is discussed 356 below, along with other informational parts or concepts that can be 357 questioned. 359 6.1. Reverse decompression 361 Reverse decompression is described in section 6.1. This is a very 362 questionable implementation enhancement, and should preferably be 363 removed, or at least be put in an appendix. 365 6.2. Implementation parameters and signals 367 In section 6.3, various potential API parameters are defined, 368 although only informatively, as they are not at all necessary from a 369 ROHC protocol point of view. Unfortunately, the way this section is 370 written might make implementer's believe this is actually part of the 371 standard, as it even makes use of RFC 2119 keywords. 373 This section should thus be revised, simplified, and it should be 374 made clear that it is an API parameter proposal, nothing more, 375 nothing less. The result could potentially be put in an appendix of 376 the profiles specification. 378 6.3. Decompressor resource limitations 380 Section 6.4 of discusses how to handle resource limitations at the 381 decompressor. This is typical implementation guidelines that fits 382 very well in an "implementation issues" section, and should thus be 383 kept. Note that the addition of the CONTEXT_MEMORY feedback option 384 (see section 4.2 of this document) affects this discussion, which 385 would have to be updated accordingly. 387 6.4. Implementation structures 389 Section 6.5 provides some explanatory material on data structures 390 that a ROHC implementation will have to maintain in one form or 391 another. The section explicitly states the explanatory nature of it, 392 and points out that it is not intended to constrain implementations. 393 However, it is far from clear whether this material is actually 394 useful. It should therefore be revised, potentially removed, or at 395 least put in an appendix. 397 6.5. The state concept 399 The concept of states (FO/SO), as used in a normative manner 400 throughout RFC 3095, should be removed from the spec or at least 401 rewritten so that it becomes clear that this is a descriptive concept 402 and not at all normative. Mentioning of implementation parameters, 403 such as k_2/n_2 and k_3/n_3 should be dropped, or it should at least 404 be made clear that these are just example parameters in example 405 algorithms. Probably the entire state concept can be dropped, since 406 it really describes implementation choices. It can be used 407 informatively, but that should then be made clear. 409 7. Security considerations 411 This document provides guidelines for how to specify new protocols, 412 and those protocols will of course have to consider security aspects. 414 8. IANA considerations 416 This document does not require any IANA actions. 418 9. Informative References 420 [1] C. Bormann, et al., "RObust Header Compression (ROHC) Framework 421 and four profiles: RTP, UDP, ESP, and uncompressed", 422 RFC 3095, July 2001. 424 [2] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC): 425 A Compression Profile for IP", RFC 3843, June 2004. 427 [3] G. Pelletier, L-E. Jonsson, and K. Sandlund, "ROHC over Channels 428 that can Reorder Packets", internet-draft (work in progress), 429 May 2005. 431 10. Authors Addresses 433 Lars-Erik Jonsson 434 Ericsson AB 435 Box 920 436 SE-971 28 Lulea, Sweden 437 Phone: +46 8 404 29 61 438 EMail: lars-erik.jonsson@ericsson.com 440 Intellectual Property Statement 442 The IETF takes no position regarding the validity or scope of any 443 Intellectual Property Rights or other rights that might be claimed to 444 pertain to the implementation or use of the technology described in 445 this document or the extent to which any license under such rights 446 might or might not be available; nor does it represent that it has 447 made any independent effort to identify any such rights. Information 448 on the procedures with respect to rights in RFC documents can be 449 found in BCP 78 and BCP 79. 451 Copies of IPR disclosures made to the IETF Secretariat and any 452 assurances of licenses to be made available, or the result of an 453 attempt made to obtain a general license or permission for the use of 454 such proprietary rights by implementers or users of this 455 specification can be obtained from the IETF on-line IPR repository at 456 http://www.ietf.org/ipr. 458 The IETF invites any interested party to bring to its attention any 459 copyrights, patents or patent applications, or other proprietary 460 rights that may cover technology that may be required to implement 461 this standard. Please address the information to the IETF at ietf- 462 ipr@ietf.org. 464 Copyright Statement 466 Copyright (C) The Internet Society (2006). This document is subject 467 to the rights, licenses and restrictions contained in BCP 78, and 468 except as set forth therein, the authors retain all their rights. 470 Disclaimer of Validity 472 This document and the information contained herein are provided on an 473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 475 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 476 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 477 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 This Internet-Draft expires March 19, 2007.