idnits 2.17.1 draft-schmidt-rohc-sctp-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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 14, 2001) is 8258 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) == Missing Reference: 'RFC2026' is mentioned on line 14, but not defined == Missing Reference: 'ROHC' is mentioned on line 265, but not defined == Unused Reference: 'RFC-2960' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC-1144' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'RFC-2507' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC-3096' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'TCPREQ' is defined on line 293, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-02 -- Possible downref: Normative reference to a draft: ref. 'USCTP' ** Downref: Normative reference to an Informational RFC: RFC 3096 == Outdated reference: A later version (-08) exists of draft-ietf-rohc-tcp-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rohc-tcp-requirements (ref. 'TCPREQ') Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RoHC Working Group Ch. Schmidt 3 INTERNET DRAFT M. Tuexen 4 Siemens 5 Expires March 14, 2002 September 14, 2001 7 Requirements for RoHC IP/SCTP Robust Header Compression 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be acessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document contains requirements for the IP/SCTP header compression 33 scheme (profile) to be developed by the ROHC WG. The structure of this 34 document is inherited from the document defining IP/TCP requirements for 35 ROHC. 37 1. Document history 39 September 14, 2001 - draft-schmidt-rohc-sctp-requirements-00.txt. 41 Initial version of this document to initiate discussion on 42 requirements for SCTP compression in ROHC. 44 2. Introduction 46 The goal of the ROHC WG is to develop header compression schemes that 47 perform well over links with high error rates and long link round trip 48 times. The schemes must perform well for cellular links, using 49 technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes 50 should also be applicable to other future link technologies with high 51 loss and long round trip times. 53 The main objective for ROHC has been robust compression of IP/UDP/RTP. 54 Next step was IP/TCP compression. 56 SCTP is the new reliable transport protocol from the IETF. It offers a 57 number of features not available in other reliable transport protocols 58 such as TCP, including multi-streaming, multi-homing and resistance to 59 flooding and masquerade attacks. SCTP is designed to transport PSTN 60 signaling messages over IP networks but its rich feature set makes it 61 capable of many broader applications. Main known application today is 62 the transport of SIP signaling messages. 64 One of the most important innovations of SCTP is the multi-streaming 65 function. This feature allows data to be partitioned into multiple 66 streams where each stream is delivered independently, so in-sequence 67 delivery can be guaranteed only for packets within a single stream. The 68 advantage of this technique is that when a packet is lost, only the data 69 from the corresponding stream is delayed whilst the packet is 70 retransmitted. Packets from other streams are unaffected by the loss. 72 From the header compression point of view the multi-streaming function 73 raises a number of new issues to solve. Most importantly a SCTP packet 74 consists of a common header followed by a sequence of chunks. User 75 payload is transported in DATA chunks which contain stream specific 76 information. All other chunks do not contain stream specific 77 information. To obtain maximum compression efficiency it is important to 78 maintain a separate context for the stream-specific fields from each 79 stream, but to use a shared context for all general fields. 81 The remaining requirements will be similar to IP / TCP compression. 83 3. Header compression requirements 85 The following requirements have, more or less arbitrarily, been divided 86 into five groups. The first group deals with requirements concerning the 87 impact of a header compression scheme on the rest of the Internet 88 infrastructure. The second group defines what kind of headers that must 89 be compressed efficiently while the third and forth groups concern 90 performance requirements and capability requirements which stem from the 91 properties of the anticipated link technologies. Finally, the fifth 92 section discusses Intellectual Property Rights related to ROHC SCTP 93 compression. 95 3.1. Impact on Internet infrastructure 97 1. Transparency: When a header is compressed and then decompressed, the 98 resulting header must be semantically identical to the original 99 header. If this cannot be achieved, the packet containing the 100 erroneous header must be discarded. 102 Justification: The header compression process must not produce 103 headers that might cause problems for any current or future part of 104 the Internet infrastructure. 106 Note: The ROHC WG has not found a case where "semantically 107 identical" is not the same as "bitwise identical". 109 2. Ubiquity: Must not require modifications to existing IP (v4 or v6) 110 or SCTP implementations. 112 Justification: Ease of deployment. 114 Note: The ROHC WG may recommend changes that would increase the 115 compression efficiency for the SCTP streams emitted by 116 implementations. However, ROHC cannot rely on such recommendations 117 being followed. 119 3.2. Supported headers 121 (1) IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all 122 possible changes in the IP header fields must be handled by the 123 compression scheme and commonly changing fields should be 124 compressed efficiently. 126 Justification: IPv4 and IPv6 will both be around during the 127 foreseeable future. 129 (2) Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be 130 supported and should be compressed efficiently. For IPv4 these 131 include headers of tunneled packets. For IPv6 these include headers 132 containing the Routing Header, the Binding Update Destination 133 Option, and the Home Address option. 135 Justification: It is very likely that Mobile IP will be used by 136 cellular devices. 138 (3) IPSEC: The scheme should be able to compress headers containing 139 IPSEC sub-headers. 141 Justification: IPSEC is expected to be used to provide necessary 142 end-to-end security. 144 Note: It is of course not possible to compress the encrypted part 145 of an ESP header, nor the cryptographic data in an AH header. 147 3.3. SCTP specific requirements 149 (1) Generality: Must support efficient compression of the SCTP 150 information in a SCTP packet. This means that the scheme must be 151 able to work with the protocol structure of the SCTP protocol 152 (chunk header, chunk body, chunk header, chunk body ...) in a 153 proper way. 155 Justification: There must be a generic scheme which reflects the 156 structure of SCTP packets. 158 (2) Context synchronization failure, concerning certain stream, must 159 not affect the handling of other streams. 161 Justification: The compression stream must support the multiple 162 streams feature in a way that head of line blocking is not 163 introduced again by RoHC. Context update should be restricted to a 164 minimum. 166 (3) SCTP extensions as described in [USCTP] and [ADDIP] should be 167 compressed efficiently. 169 Justification: SCTP extensions will be a normal part of the 170 protocol. To reach good efficiency for SCTP, these extension have 171 to be handled in an appropriate way. 173 (4) Generic extendibility describes the handling of yet not defined 174 chunks, the compression scheme must be able to handle this chunks. 176 Justification: The compression scheme must support full SCTP 177 functionality. 179 3.4. Performance issues 181 (1) Performance/Spectral Efficiency: Must provide low relative overhead 182 under expected operating conditions. 184 Justification: Spectrum efficiency is the primary goal here. 186 (2) Error propagation: For SCTP traffic, link layer retransmissions 187 should be applied to make use of the bandwidth in the most 188 efficient way. Lost or damaged headers should thus not occur and 189 therefore it is not a primary goal to have mechanisms for error 190 propagation avoidance in case of such events. 192 Justification: To provide robustness against loss or damage 193 introduced by the link, efficiency must be sacrificed. Since loss 194 or damage is not expected for SCTP traffic, efficiency should 195 instead be prioritized. This does not mean that some robustness 196 should not be provided, if efficiency can still be optimized. 198 Note: In general, error propagation due to header compression 199 should be kept at an absolute minimum. Error propagation is defined 200 as the loss or damage of headers subsequent to headers lost or 201 damaged by the link, even if those subsequent headers are not lost 202 or damaged. 204 Note: There are at least two kinds of error propagation; loss 205 propagation, where a lost header causes subsequent headers to be 206 lost or damaged, and damage propagation, where a damaged header 207 causes subsequent headers to be lost or damaged. 209 (3) Short lived SCTP transfers: The scheme should provide mechanisms 210 for efficient compression of short-lived SCTP transfers, minimizing 211 the size of context initiation headers. 213 Justification: Many SCTP transfers are short-lived. This means that 214 the gain of header compression could be low since normally header 215 compression sends full headers initially and small compressed 216 headers first after the initiation phase. 218 Note: This requirement implies that mechanisms for "context 219 sharing" or "context re-use" should be considered. 221 (4a) Moderate Packet Reordering: The scheme should efficiently handle 222 moderate reordering (2-3 packets) in the packet stream reaching the 223 compressor. 225 Justification: This kind of reordering is common. 227 (4b) Packet Reordering: The scheme should be able to compress when there 228 are reordered packets in the SCTP stream reaching the compressor. 230 Justification: Reordering happens regularly in the Internet. 231 However, since the Internet is engineered to run SCTP reasonably 232 well, excessive reordering will not be common and need not be 233 handled with optimum efficiency. 235 (5) Processing delay: The scheme must not contribute significantly to 236 system delay budget. 238 3.5. Capability requirements related to link layer characteristics 240 (1) Unidirectional links: Must be possible to implement (possibly with 241 less efficiency) without explicit feedback messages from 242 decompressor to compressor. 244 Justification: There are links that do not provide a feedback 245 channel or feedback is not desirable for other reasons. 247 (2) Link delay: Must operate under all expected link delay conditions. 249 (3) Header compression coexistence: The scheme must fit into the ROHC 250 framework together with other ROHC profiles 252 3.6. Open issues - For further discussions 254 (1) What is the level of complexity, are we willing to pay for the most 255 efficient way to compress multi-streaming SCTP? 257 4. IANA Considerations 259 A protocol which meets these requirements, e.g., [ROHC], will require 260 the IANA to assign various numbers. This document by itself, however, 261 does not require any IANA involvement. 263 5. Security Considerations 265 A protocol specified to meet these requirements, e.g., [ROHC], must be 266 able to compress packets containing IPSEC headers according to the IPSEC 267 requirement, 2.2.4. The efficiency of the compression may be influenced 268 by encrypted protocol header elements. This document by itself, however, 269 does not add any security risks. 271 6. References 273 [RFC-2960] R. R. Stewart et al., "Stream Control Transmission 274 Protocol", November 2000. 276 [ADDIP] R. R. Stewart et al., "SCTP Extensions for Dynamic 277 Reconfiguration of IP Addresses and Enforcement of Flow and 278 Message Limits", draft-ietf-tsvwg-addip-sctp-02.txt, June 279 2001. 281 [USCTP] Q. Xie et al., "SCTP Unreliable Data Mode Extension", draft- 282 ietf-tsvwg-usctp-00.txt, April 2001. 284 [RFC-1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed 285 Serial Links", RFC 1144, February 1990. 287 [RFC-2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header 288 Compression", RFC 2507, February 1999. 290 [RFC-3096] Mikael Degermark, "Requirements for IP/UDP/RTP header 291 compression", RFC 3096, July 2001. 293 [TCPREQ] Lars-Erik Jonsson, "Requirements for ROHC IP/TCP 294 Compression", draft-ietf-rohc-tcp-requirements-01.txt, June 295 2001. 297 7. Authors' Addresses 299 Christian Schmidt Tel.: +49 89 722 27822 300 Siemens AG e-mail: Christian.Schmidt@icn.siemens.de 301 Werner von Siemens Ring 20 302 D-85630 Grasbrunn 303 Germany 304 Michael Tuexen Tel.: +49 89 722 47210 305 Siemens AG e-mail: Michael.Tuexen@icn.siemens.de 306 Hofmannstrasse 51 307 D-81359 Munich 308 Germany 310 This Internet Draft expires March 14, 2002.