Network Working Group Hans Hannu, Ericsson (Editor) INTERNET-DRAFT Sweden Expires: December 2001 June 7, 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 an individual submission to the IETF. Comments should be directed to the authors. 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 June 7, 2001 0. Document History - June 7, 2001, version 00. First version 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.......................................5 5. IANA considerations...........................................5 6. Editor's address..............................................5 7. References....................................................5 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. 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 Hannu [Page 2] INTERNET-DRAFT Signaling Compression req. & assumptions June 7, 2001 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 June 7, 2001 3.1. General requirements 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. This is to ensure that the compression scheme will not cause problems for any current or future part of the Internet infrastructure. The compression scheme must be able to coexist with 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. Modifications to the protocols, which generates the messages that are to be compressed, must not be required for the compression scheme to work. This will simplify deployment of the compression scheme. Compression of arbitrary message streams must be supported. The compression scheme must not be limited to certain protocols, traffic patterns or sessions. This does not preclude optimization for certain streams. The compression scheme must be able to operate on unidirectional links, i.e. without explicit feedback messages from the decompressor. However, implementations on unidirectional links are expected to show a degraded performance compared to implementations on bi-directional links 3.2. Performance requirements The compression scheme must be able to operate under all expected link delay conditions. The compression scheme must be able to operate under all expected packet loss conditions. The compression scheme must be able to operate under all expected residual bit error conditions. The compression scheme should aim at minimizing transmission delay and maximizing the bitwise efficiency. Since there are no previously defined solutions for compression of application signaling protocols it is difficult to find a suitable benchmark. 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. Hannu [Page 4] INTERNET-DRAFT Signaling Compression req. & assumptions June 7, 2001 Error propagation must be minimized. Loss or damage to a single or several messages should not prevent compression and decompression of later messages. The compression scheme should be able to compress and decompress when there are reordered messages reaching the compressor. Reordering is frequent on the Internet, which implies that the compressor must be able to handle reordering. 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. Hannu [Page 5] INTERNET-DRAFT Signaling Compression req. & assumptions June 7, 2001 [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. [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 December 2001. Hannu [Page 6]