Network Working Group Hans Hannu, Ericsson (Editor) INTERNET-DRAFT Sweden Expires: January 2002 July 06, 2001 Signaling Compression Requirements & Assumptions 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF ROHC WG. Comments should be directed to its mailing list, rohc@cdt.luth.se. Abstract The purpose of this document is to outline requirements on a signaling compression scheme to be made in the ROHC WG, and assumptions on the link it is used over. The scheme should be able to compress/decompress messages from signaling protocols, such as SIP/SDP. Hannu [Page 1] INTERNET-DRAFT Signaling Compression req. & assumptions July 06, 2001 0. Document History - June 7, 2001, version 00. First version - July 06, 2001, version 01. Updated with additional requirements TABLE OF CONTENTS 1. Introduction..................................................2 2. Assumptions...................................................3 3. Requirements..................................................3 3.1. General requirements........................................4 3.2. Performance requirements....................................4 4. Security considerations.......................................6 5. IANA considerations...........................................6 6. Editor's address..............................................6 7. References....................................................6 1. Introduction The purpose of this document is to outline requirements on a signaling compression scheme to be made in the ROHC WG, and assumptions on the link it is used over. The scheme should be able to compress/decompress messages from signaling protocols, such as SIP/SDP [SIP], [SDP]. In wireless environments and especially in cellular systems, such as GSM/GPRS, there is a need to maximize the transport efficiency of data over the radio interface. The radio spectrum is rather expensive [CELL] and must be used carefully. Therefore the cellular systems must support a sufficient number of users to make them economical feasible. Thus, there is a limitation in the per user bandwidth. Compressing the headers of the IP-protocols used for carrying user data is one way to make more efficient use of the scarce radio resources [ROHC]. However, compression of the messages from signaling protocols, such as SIP/SDP, should also be considered to increase the radio resource usage even further. Compression will also improve the service quality, by reducing the user idle time, at e.g. call setup. Hannu [Page 2] INTERNET-DRAFT Signaling Compression req. & assumptions July 06, 2001 When IP will be used end-to-end, new applications, such as streaming, will be brought to the cellular devices. This will introduce additional traffic in cellular systems. Compression of signaling messages, such as RTSP [RTSP], should also be considered to improve both the service availability and quality. New services with their corresponding signaling protocols make it reasonable to consider a scheme that is generic. The scheme should be generic in the meaning that the scheme efficiently can be applied to arbitrary protocols with certain characteristics, such as the ASCII based protocols SIP and RTSP, [APP]. 2. Assumptions SIP/SDP messages are some of the messages that could be compressed by a signaling compression scheme. The statement in [GUIDE]: "Compression of SIP messages SHOULD be handled at lower layers, for example, using IP payload compression [9] or link layer compression" implies that signaling compression should be placed below the application layer. The use of the signaling compression scheme should be negotiated. In [ROHC-PPP], an option to negotiate the use of robust header compression (ROHC) on IP datagrams transmitted over the Point-to- Point Protocol [RFC1661] is described. It is out of the scope of this document to specify options to negotiate the use of signaling compression. When using IP to traverse voice data (VoIP) over wireless links, such as cellular links, there will be comparisons between the VoIP service and the existing circuit-switched voice service. Most likely capacity (users/cell) will be used in the comparisons. Using near the same bandwidth per user as for the circuit-switched voice service will most likely be preferred also for the VoIP service due to scarce radio resources. Therefore it is assumed that the same bandwidth used for the actual speech data is also used for the signaling ,when one is to compare different signaling compression approaches. Processor load and memory requirements are two essential issues with mobile handheld terminals, such as cellular phones. However, it is hard to predict both how complex a signaling compression scheme will become and also what memory and processor capacity handheld terminals will have in the future. Thus, no assumption on the capabilities of future terminals are made. 3. Requirements The requirements are divided into two parts. Section 3.1 sets general requirements concerning the Internet infrastructure, while section 3.2 sets requirements on the scheme itself. Hannu [Page 3] INTERNET-DRAFT Signaling Compression req. & assumptions July 06, 2001 3.1. General requirements 1. The compression must be transparent: when a message is compressed and then decompressed the result must be bitwise identical to the original message. The transparency must be maintained independently of the payload. Justification: This is to ensure that the compression scheme will not cause problems for any current or future part of the Internet infrastructure. 2. The compression scheme must be able to coexist with header compression, specially the ROHC protocol. Compression of IP/UDP and IP/TCP should be inherited from existing profiles, like the existing ROHC profile for IP/UDP compression. Justification: Signaling compression is used because there is a need to conserve bandwidth usage. In that case, header compression will likely be needed too. 3. Modifications to the protocols, which generates the messages that are to be compressed, must not be required for the compression scheme to work. Justification: This will simplify deployment of the compression scheme. 4. Compression of arbitrary message streams must be supported. The compression scheme must not be limited to certain protocols, traffic patterns or sessions. Justification: Needed for generality of the compression scheme. Note: This does not preclude optimization for certain streams. 5. The compression scheme must be able to operate on unidirectional links, i.e. without explicit feedback messages from the decompressor. Note: Implementations on unidirectional links might possibly show a degraded performance compared to implementations on bi-directional links 3.2. Performance requirements 6. The compression scheme must be able to operate under all expected link delay conditions. Hannu [Page 4] INTERNET-DRAFT Signaling Compression req. & assumptions July 06, 2001 7. The compression scheme must be able to operate under all expected packet loss conditions, including loss events due to typical handover operations. 8. The compression scheme must be able to operate under all expected residual bit error conditions. Note: See also requirement 11. 9. The compression scheme should aim at minimizing transmission delay and maximizing the bitwise efficiency. Note: Since there are no previously defined solutions for compression of application signaling protocols it is difficult to find a suitable benchmark. 10. The total delay, including processing time of the compression scheme, must decrease when compression is applied compared to sending the packets uncompressed on the same channel bandwidth. Justification: This is one of the primary goals for signaling compression. 11. Error propagation must be minimized. Loss or damage to a single or several messages, on the link between compressor and decompressor should not prevent compression and decompression of later messages. Justification: Error propagation reduces resource utilization and quality. 12. The compression scheme should be able to compress and decompress when there are reordered messages reaching the compressor. Justification: Reordering is frequent on the Internet, which implies that the compressor must be able to handle reordering. 13. The scheme must be flexible to accommodate a range of compressor/decompressor with varying memory and processor capabilities. Justification: A primary target for the signaling compression scheme is cellular systems, where the mobile terminals have varying capabilities. Hannu [Page 5] INTERNET-DRAFT Signaling Compression req. & assumptions July 06, 2001 4. Security considerations A protocol specified to meet these requirements must be able to cope with packets that has undergone security measures, such as encryption, without adding any security risks. This document by itself, however, does not add any security risks. 5. 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. 6. Editor's Address Hans Hannu Tel: +46 920 20 21 84 Ericsson Erisoft AB Lulea, Sweden EMail: Hans.Hannu@epl.ericsson.se 7. References [APP] H. Hannu, J. Christoffersson and K. Svanbro, Application signaling over cellular links, Internet Draft (work in progress), March 2001. [CELL] L. Westberg and M. Lindqvist, Realtime traffic over cellular access networks, Internet Draft (work in progress), June 2001. [GUIDE] J. Rosenberg, H. Schulzrinne, Guidelines for Authors of SIP Extensions, Internet Draft (work in progress), March 2001. [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [ROHC] C. Bormann, Et. al., RObust Header Compression, Internet Draft (work in progress), February 2001. [ROHC-PPP] C. Bormann, ROHC over PPP, Internet Draft (work in progress), March 2001. [RTSP] H. Schulzrinne, A. Rao and R. Lanphier, Real Time Streaming Protocol (RTSP), RFC 2326, April 1998. Hannu [Page 6] INTERNET-DRAFT Signaling Compression req. & assumptions July 06, 2001 [SDP] M. Handley and V. Jacobson, SDP: Session Description Protocol, RFC 2327, April 1998. [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, SIP: Session Initiation Protocol, RFC 2543, August 2000. This Internet-Draft expires in January 2002. Hannu [Page 7]