idnits 2.17.1 draft-ietf-rohc-sctp-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 260 has weird spacing: '...lost or damag...' -- 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 26, 2003) is 7516 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) == Unused Reference: '1' is defined on line 321, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 334, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (ref. '1') (Obsoleted by RFC 4960) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-08 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3096 (ref. '4') == Outdated reference: A later version (-08) exists of draft-ietf-rohc-tcp-requirements-06 ** Downref: Normative reference to an Informational draft: draft-ietf-rohc-tcp-requirements (ref. '5') Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ch. Schmidt 3 Internet-Draft Siemens AG 4 Expires: March 26, 2004 M. Tuexen 5 Univ. of Applied Sciences Muenster 6 September 26, 2003 8 Requirements for RoHC IP/SCTP Robust Header Compression 9 draft-ietf-rohc-sctp-requirements-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 26, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document contains requirements for the IP/SCTP header 40 compression scheme (profile) to be developed by the ROHC WG. The 41 structure of this document is inherited from the document defining 42 IP/TCP requirements for ROHC. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Header compression requirements . . . . . . . . . . . . . . . 4 48 2.1 Impact on Internet infrastructure . . . . . . . . . . . . . . 4 49 2.2 Supported headers . . . . . . . . . . . . . . . . . . . . . . 4 50 2.3 SCTP specific requirements . . . . . . . . . . . . . . . . . . 5 51 2.4 Performance issues . . . . . . . . . . . . . . . . . . . . . . 6 52 2.5 Capability requirements related to link layer 53 characteristics . . . . . . . . . . . . . . . . . . . . . . . 7 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 56 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 58 Intellectual Property and Copyright Statements . . . . . . . . 12 60 1. Introduction 62 The goal of the ROHC WG is to develop header compression schemes that 63 perform well over links with high error rates and long link round 64 trip times. The schemes must perform well for cellular links, using 65 technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes 66 should also be applicable to other future link technologies with high 67 loss and long round trip times. 69 The main objective for ROHC has been robust compression of IP/UDP/ 70 RTP. Next step was IP/TCP compression. 72 SCTP is the new reliable transport protocol from the IETF. It offers 73 a number of features not available in other reliable transport 74 protocols such as TCP, including multi-streaming, multi-homing and 75 resistance to flooding and masquerade attacks. SCTP is designed to 76 transport PSTN signaling messages over IP networks but its rich 77 feature set makes it capable of many broader applications. 78 Additionally, SCTP is required for reliable server pooling (transport 79 between name servers and between pool elements and name servers) and 80 recommended for SIP signaling. The selection of SCTP for this purpose 81 will improve the quality of these services. 83 One of the most important innovations of SCTP is the multi-streaming 84 function. This feature allows data to be partitioned into multiple 85 streams where each stream is delivered independently, so in-sequence 86 delivery can be guaranteed for data sent within a single stream. The 87 advantage of this technique is that when a packet is lost, only 88 certain streams are affected. 90 From the header compression point of view the multi-streaming 91 function raises a number of new issues to solve. Most importantly a 92 SCTP packet consists of a common header followed by a sequence of 93 chunks. User payload is transported in DATA chunks which contain 94 stream specific information. All other chunks do not contain stream 95 specific information. To obtain maximum compression efficiency it is 96 important to maintain a separate context for the stream-specific 97 fields from each stream, but to use a shared context for all general 98 fields. 100 The remaining requirements will be similar to IP / TCP compression 101 [5]. 103 2. Header compression requirements 105 The following requirements have, more or less arbitrarily, been 106 divided into five groups. 108 The first group deals with requirements concerning the impact of a 109 header compression scheme on the rest of the Internet infrastructure. 110 The second group defines what kind of headers that must be compressed 111 efficiently. The third group defines SCTP specific requirements, 112 while the forth and fifth groups concern performance requirements and 113 capability requirements from the properties of the anticipated link 114 technologies. 116 2.1 Impact on Internet infrastructure 118 Transparency: 120 When a header is compressed and then decompressed, the resulting 121 header must be semantically identical to the original header. If 122 this cannot be achieved, the packet containing the erroneous 123 header must be discarded. 125 Justification: The header compression process must not produce 126 headers that might cause problems for any current or future part 127 of the Internet infrastructure. 129 Note: The ROHC WG has not found a case where "semantically 130 identical" is not the same as "bitwise identical". 132 Ubiquity: 134 Must not require modifications to existing IP (v4 or v6) or SCTP 135 implementations. 137 Justification: Ease of deployment. 139 2.2 Supported headers 141 IPv4 and IPv6: 143 Must support both IPv4 and IPv6. This means that all possible 144 changes in the IP header fields must be handled by the compression 145 scheme and commonly changing fields should be compressed 146 efficiently. 148 Justification: IPv4 and IPv6 will both be around during the 149 foreseeable future. 151 Mobile IP: 153 The kinds of headers used by Mobile IP{v4,v6} must be supported 154 and should be compressed efficiently. For IPv4 these include 155 headers of tunneled packets. For IPv6 these include headers 156 containing the Routing Header, the Binding Update Destination 157 Option, and the Home Address option. 159 Justification: It is very likely that Mobile IP will be used by 160 cellular devices. 162 IPSEC: 164 The scheme should be able to compress headers containing IPSEC 165 sub-headers. 167 Justification: IPSEC is expected to be used to provide necessary 168 end-to-end security. 170 Note: It is of course not possible to compress the encrypted part 171 of an ESP header, nor the cryptographic data in an AH header. 173 2.3 SCTP specific requirements 175 Generality: 177 Must support efficient compression of the SCTP information in a 178 SCTP packet. This means that the scheme must be able to work with 179 the protocol structure of the SCTP protocol (SCTP common header, 180 chunk-1 header, chunk-1 body, chunk-2 header, chunk-2 body...) in 181 a proper way. 183 Justification: There must be a generic scheme which reflects the 184 structure of SCTP packets. 186 Streams: 188 Multi-streaming function of SCTP has to be kept in most of the 189 cases. 191 Justification: The independent transport of multiple streams is a 192 big advantage of SCTP. In case of a packet loss at the compressed 193 link, two cases have to be differentiated: 195 Case 1: The verification of the decompression via CRC compression 196 checksum went well. In this case, uncompressed SCTP packets 197 will be forwarded and the SCTP endpoints will take care about 198 multi-streaming functionality. 200 Case 2: The verification of the decompression via CRC compression 201 checksum fails. In this case, the release of the related SCTP 202 packet could influence unrelated streams as well. The only way 203 to avoid this would be the generation of a new SCTP packet by 204 the decompressor (without the data chunks from the involved 205 stream) - in violation to the transparency transport 206 requirement. 208 The compression stream must support the multiple streams feature 209 in a way that head of line blocking is introduced by RoHC only in 210 very rare cases. Context update should be restricted to a minimum. 212 Extensions: 214 SCTP extensions as described in ADDIP [2] and PRSCTP [3] should be 215 compressed efficiently. 217 Justification: SCTP extensions will be a normal part of the 218 protocol. To reach good efficiency for SCTP, these extension have 219 to be handled in an appropriate way. 221 Extendibility: 223 Generic extendibility describes the handling of yet not defined 224 chunks, the compression scheme must be able to handle this chunks. 226 Justification: The compression scheme must support full SCTP 227 functionality. 229 2.4 Performance issues 231 Performance/Spectral Efficiency: 233 Must provide low relative overhead under expected operating 234 conditions. 236 Justification: Spectrum efficiency is the primary goal here. 238 Error propagation: 240 For SCTP traffic, link layer retransmissions should be applied to 241 make use of the bandwidth in the most efficient way. Lost or 242 damaged headers should thus not occur and therefore it is not a 243 primary goal to have mechanisms for error propagation avoidance in 244 case of such events. 246 Justification: To provide robustness against loss or damage 247 introduced by the link, efficiency must be sacrificed. Since loss 248 or damage is not expected for SCTP traffic, efficiency should 249 instead be prioritized. This does not mean that some robustness 250 should not be provided, if efficiency can still be optimized. 252 Note: In general, error propagation due to header compression 253 should be kept at an absolute minimum. Error propagation is 254 defined as the loss or damage of headers subsequent to headers 255 lost or damaged by the link, even if those subsequent headers are 256 not lost or damaged. 258 Note: There are at least two kinds of error propagation; loss 259 propagation, where a lost header causes subsequent headers to be 260 lost or damaged, and damage propagation, where a damaged header 261 causes subsequent headers to be lost or damaged. 263 Moderate Packet Reordering: 265 The scheme should efficiently handle moderate reordering (2-3 266 packets) in the packet stream reaching the compressor. 268 Justification: This kind of reordering is common. 270 Packet Reordering: 272 The scheme should be able to compress when there are reordered 273 packets in the packet stream reaching the compressor. 275 Justification: Reordering happens regularly in the Internet. 276 However, since the Internet is engineered to run SCTP reasonably 277 well, excessive reordering will not be common and need not be 278 handled with optimum efficiency. 280 Processing delay: 282 The scheme must not contribute significantly to system delay 283 budget. 285 2.5 Capability requirements related to link layer characteristics 287 Unidirectional links: 289 Must be possible to implement (possibly with less efficiency) 290 without explicit feedback messages from decompressor to 291 compressor. 293 Justification: There are links that do not provide a feedback 294 channel or feedback is not desirable for other reasons. 296 Link delay: 298 Must operate under all expected link delay conditions. 300 Header compression coexistence: 302 The scheme must fit into the ROHC framework together with other 303 ROHC profiles. 305 3. IANA Considerations 307 A protocol which meets these requirements will require the IANA to 308 assign various numbers. This document by itself, however, does not 309 require any IANA involvement. 311 4. Security Considerations 313 A protocol specified to meet these requirements must be able to 314 compress packets containing IPSEC headers according to the IPSEC 315 requirement, 2.2.4. The efficiency of the compression may be 316 influenced by encrypted protocol header elements. This document by 317 itself, however, does not add any security risks. 319 References 321 [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 322 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 323 "Stream Control Transmission Protocol", RFC 2960, October 2000. 325 [2] Stewart, R., "Stream Control Transmission Protocol (SCTP) 326 Dynamic Address Reconfiguration", 327 draft-ietf-tsvwg-addip-sctp-08 (work in progress), September 328 2003. 330 [3] Ramalho, M. and R. Stewart, "SCTP Partial Reliability 331 Extension", draft-stewart-tsvwg-prsctp-04 (work in progress), 332 May 2003. 334 [4] Degermark, M., "Requirements for robust IP/UDP/RTP header 335 compression", RFC 3096, July 2001. 337 [5] Jonsson, L., "Requirements for ROHC IP/TCP Header Compression", 338 draft-ietf-rohc-tcp-requirements-06 (work in progress), June 339 2003. 341 Authors' Addresses 343 Christian Schmidt 344 Siemens AG 345 St.-Martin-Str. 76 346 81541 Munich 347 Germany 349 Phone: +49 89 63675192 350 EMail: Christian-Schmidt@siemens.com 352 Michael Tuexen 353 Univ. of Applied Sciences Muenster 354 Stegerwaldstr. 39 355 48565 Steinfurt 356 Germany 358 Phone: +49 2551 962550 359 EMail: tuexen@fh-muenster.de 361 Intellectual Property Statement 363 The IETF takes no position regarding the validity or scope of any 364 intellectual property or other rights that might be claimed to 365 pertain to the implementation or use of the technology described in 366 this document or the extent to which any license under such rights 367 might or might not be available; neither does it represent that it 368 has made any effort to identify any such rights. Information on the 369 IETF's procedures with respect to rights in standards-track and 370 standards-related documentation can be found in BCP-11. Copies of 371 claims of rights made available for publication and any assurances of 372 licenses to be made available, or the result of an attempt made to 373 obtain a general license or permission for the use of such 374 proprietary rights by implementors or users of this specification can 375 be obtained from the IETF Secretariat. 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights which may cover technology that may be required to practice 380 this standard. Please address the information to the IETF Executive 381 Director. 383 Full Copyright Statement 385 Copyright (C) The Internet Society (2003). All Rights Reserved. 387 This document and translations of it may be copied and furnished to 388 others, and derivative works that comment on or otherwise explain it 389 or assist in its implementation may be prepared, copied, published 390 and distributed, in whole or in part, without restriction of any 391 kind, provided that the above copyright notice and this paragraph are 392 included on all such copies and derivative works. However, this 393 document itself may not be modified in any way, such as by removing 394 the copyright notice or references to the Internet Society or other 395 Internet organizations, except as needed for the purpose of 396 developing Internet standards in which case the procedures for 397 copyrights defined in the Internet Standards process must be 398 followed, or as required to translate it into languages other than 399 English. 401 The limited permissions granted above are perpetual and will not be 402 revoked by the Internet Society or its successors or assignees. 404 This document and the information contained herein is provided on an 405 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 406 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 407 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 408 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 409 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 411 Acknowledgment 413 Funding for the RFC Editor function is currently provided by the 414 Internet Society.