Network Working Group Ch. Schmidt Internet-Draft Siemens AG Expires: March 26, 2004 M. Tuexen Univ. of Applied Sciences Muenster September 26, 2003 Requirements for RoHC IP/SCTP Robust Header Compression draft-ietf-rohc-sctp-requirements-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 March 26, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document contains requirements for the IP/SCTP header compression scheme (profile) to be developed by the ROHC WG. The structure of this document is inherited from the document defining IP/TCP requirements for ROHC. Schmidt & Tuexen Expires March 26, 2004 [Page 1] Internet-Draft RoHC IP/SCTP Requirements September 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Header compression requirements . . . . . . . . . . . . . . . 4 2.1 Impact on Internet infrastructure . . . . . . . . . . . . . . 4 2.2 Supported headers . . . . . . . . . . . . . . . . . . . . . . 4 2.3 SCTP specific requirements . . . . . . . . . . . . . . . . . . 5 2.4 Performance issues . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Capability requirements related to link layer characteristics . . . . . . . . . . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Schmidt & Tuexen Expires March 26, 2004 [Page 2] Internet-Draft RoHC IP/SCTP Requirements September 2003 1. Introduction The goal of the ROHC WG is to develop header compression schemes that perform well over links with high error rates and long link round trip times. The schemes must perform well for cellular links, using technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes should also be applicable to other future link technologies with high loss and long round trip times. The main objective for ROHC has been robust compression of IP/UDP/ RTP. Next step was IP/TCP compression. SCTP is the new reliable transport protocol from the IETF. It offers a number of features not available in other reliable transport protocols such as TCP, including multi-streaming, multi-homing and resistance to flooding and masquerade attacks. SCTP is designed to transport PSTN signaling messages over IP networks but its rich feature set makes it capable of many broader applications. Additionally, SCTP is required for reliable server pooling (transport between name servers and between pool elements and name servers) and recommended for SIP signaling. The selection of SCTP for this purpose will improve the quality of these services. One of the most important innovations of SCTP is the multi-streaming function. This feature allows data to be partitioned into multiple streams where each stream is delivered independently, so in-sequence delivery can be guaranteed for data sent within a single stream. The advantage of this technique is that when a packet is lost, only certain streams are affected. From the header compression point of view the multi-streaming function raises a number of new issues to solve. Most importantly a SCTP packet consists of a common header followed by a sequence of chunks. User payload is transported in DATA chunks which contain stream specific information. All other chunks do not contain stream specific information. To obtain maximum compression efficiency it is important to maintain a separate context for the stream-specific fields from each stream, but to use a shared context for all general fields. The remaining requirements will be similar to IP / TCP compression [5]. Schmidt & Tuexen Expires March 26, 2004 [Page 3] Internet-Draft RoHC IP/SCTP Requirements September 2003 2. Header compression requirements The following requirements have, more or less arbitrarily, been divided into five groups. The first group deals with requirements concerning the impact of a header compression scheme on the rest of the Internet infrastructure. The second group defines what kind of headers that must be compressed efficiently. The third group defines SCTP specific requirements, while the forth and fifth groups concern performance requirements and capability requirements from the properties of the anticipated link technologies. 2.1 Impact on Internet infrastructure Transparency: When a header is compressed and then decompressed, the resulting header must be semantically identical to the original header. If this cannot be achieved, the packet containing the erroneous header must be discarded. Justification: The header compression process must not produce headers that might cause problems for any current or future part of the Internet infrastructure. Note: The ROHC WG has not found a case where "semantically identical" is not the same as "bitwise identical". Ubiquity: Must not require modifications to existing IP (v4 or v6) or SCTP implementations. Justification: Ease of deployment. 2.2 Supported headers IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all possible changes in the IP header fields must be handled by the compression scheme and commonly changing fields should be compressed efficiently. Justification: IPv4 and IPv6 will both be around during the foreseeable future. Schmidt & Tuexen Expires March 26, 2004 [Page 4] Internet-Draft RoHC IP/SCTP Requirements September 2003 Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be supported and should be compressed efficiently. For IPv4 these include headers of tunneled packets. For IPv6 these include headers containing the Routing Header, the Binding Update Destination Option, and the Home Address option. Justification: It is very likely that Mobile IP will be used by cellular devices. IPSEC: The scheme should be able to compress headers containing IPSEC sub-headers. Justification: IPSEC is expected to be used to provide necessary end-to-end security. Note: It is of course not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header. 2.3 SCTP specific requirements Generality: Must support efficient compression of the SCTP information in a SCTP packet. This means that the scheme must be able to work with the protocol structure of the SCTP protocol (SCTP common header, chunk-1 header, chunk-1 body, chunk-2 header, chunk-2 body...) in a proper way. Justification: There must be a generic scheme which reflects the structure of SCTP packets. Streams: Multi-streaming function of SCTP has to be kept in most of the cases. Justification: The independent transport of multiple streams is a big advantage of SCTP. In case of a packet loss at the compressed link, two cases have to be differentiated: Case 1: The verification of the decompression via CRC compression checksum went well. In this case, uncompressed SCTP packets will be forwarded and the SCTP endpoints will take care about Schmidt & Tuexen Expires March 26, 2004 [Page 5] Internet-Draft RoHC IP/SCTP Requirements September 2003 multi-streaming functionality. Case 2: The verification of the decompression via CRC compression checksum fails. In this case, the release of the related SCTP packet could influence unrelated streams as well. The only way to avoid this would be the generation of a new SCTP packet by the decompressor (without the data chunks from the involved stream) - in violation to the transparency transport requirement. The compression stream must support the multiple streams feature in a way that head of line blocking is introduced by RoHC only in very rare cases. Context update should be restricted to a minimum. Extensions: SCTP extensions as described in ADDIP [2] and PRSCTP [3] should be compressed efficiently. Justification: SCTP extensions will be a normal part of the protocol. To reach good efficiency for SCTP, these extension have to be handled in an appropriate way. Extendibility: Generic extendibility describes the handling of yet not defined chunks, the compression scheme must be able to handle this chunks. Justification: The compression scheme must support full SCTP functionality. 2.4 Performance issues Performance/Spectral Efficiency: Must provide low relative overhead under expected operating conditions. Justification: Spectrum efficiency is the primary goal here. Error propagation: For SCTP traffic, link layer retransmissions should be applied to make use of the bandwidth in the most efficient way. Lost or damaged headers should thus not occur and therefore it is not a primary goal to have mechanisms for error propagation avoidance in Schmidt & Tuexen Expires March 26, 2004 [Page 6] Internet-Draft RoHC IP/SCTP Requirements September 2003 case of such events. Justification: To provide robustness against loss or damage introduced by the link, efficiency must be sacrificed. Since loss or damage is not expected for SCTP traffic, efficiency should instead be prioritized. This does not mean that some robustness should not be provided, if efficiency can still be optimized. Note: In general, error propagation due to header compression should be kept at an absolute minimum. Error propagation is defined as the loss or damage of headers subsequent to headers lost or damaged by the link, even if those subsequent headers are not lost or damaged. Note: There are at least two kinds of error propagation; loss propagation, where a lost header causes subsequent headers to be lost or damaged, and damage propagation, where a damaged header causes subsequent headers to be lost or damaged. Moderate Packet Reordering: The scheme should efficiently handle moderate reordering (2-3 packets) in the packet stream reaching the compressor. Justification: This kind of reordering is common. Packet Reordering: The scheme should be able to compress when there are reordered packets in the packet stream reaching the compressor. Justification: Reordering happens regularly in the Internet. However, since the Internet is engineered to run SCTP reasonably well, excessive reordering will not be common and need not be handled with optimum efficiency. Processing delay: The scheme must not contribute significantly to system delay budget. 2.5 Capability requirements related to link layer characteristics Unidirectional links: Must be possible to implement (possibly with less efficiency) without explicit feedback messages from decompressor to Schmidt & Tuexen Expires March 26, 2004 [Page 7] Internet-Draft RoHC IP/SCTP Requirements September 2003 compressor. Justification: There are links that do not provide a feedback channel or feedback is not desirable for other reasons. Link delay: Must operate under all expected link delay conditions. Header compression coexistence: The scheme must fit into the ROHC framework together with other ROHC profiles. Schmidt & Tuexen Expires March 26, 2004 [Page 8] Internet-Draft RoHC IP/SCTP Requirements September 2003 3. IANA Considerations A protocol which meets these requirements will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement. Schmidt & Tuexen Expires March 26, 2004 [Page 9] Internet-Draft RoHC IP/SCTP Requirements September 2003 4. Security Considerations A protocol specified to meet these requirements must be able to compress packets containing IPSEC headers according to the IPSEC requirement, 2.2.4. The efficiency of the compression may be influenced by encrypted protocol header elements. This document by itself, however, does not add any security risks. Schmidt & Tuexen Expires March 26, 2004 [Page 10] Internet-Draft RoHC IP/SCTP Requirements September 2003 References [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [2] Stewart, R., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp-08 (work in progress), September 2003. [3] Ramalho, M. and R. Stewart, "SCTP Partial Reliability Extension", draft-stewart-tsvwg-prsctp-04 (work in progress), May 2003. [4] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001. [5] Jonsson, L., "Requirements for ROHC IP/TCP Header Compression", draft-ietf-rohc-tcp-requirements-06 (work in progress), June 2003. Authors' Addresses Christian Schmidt Siemens AG St.-Martin-Str. 76 81541 Munich Germany Phone: +49 89 63675192 EMail: Christian-Schmidt@siemens.com Michael Tuexen Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany Phone: +49 2551 962550 EMail: tuexen@fh-muenster.de Schmidt & Tuexen Expires March 26, 2004 [Page 11] Internet-Draft RoHC IP/SCTP Requirements September 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Schmidt & Tuexen Expires March 26, 2004 [Page 12] Internet-Draft RoHC IP/SCTP Requirements September 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schmidt & Tuexen Expires March 26, 2004 [Page 13]