Network Working Group H. Hannu (Editor), Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson Expires: July 2002 C. Clanton, Nokia S. Forsgren. Ericsson K. Le, Nokia K. Leung, Nokia Z. Liu, Nokia R. Price, Siemens/Roke Manor J. Rosenberg, Dynamicsoft K. Svanbro, Ericsson January 28, 2002 Signaling Compression (SigComp) 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 This document defines one out of two parts for a basic solution for compressing messages generated by protocols, such as SIP, called SigComp. The architecture and pre-requisites of SigComp is outlined, along with the format of the SigComp message. Hannu, et al. [Page 1] INTERNET-DRAFT SigComp January 28 , 2002 0. Document History - October 19, 2001, version 00 First version. The draft describes the current ideas, from people involved in the ROHC WG, of how to perform compression of application signaling messages. - October 31, 2001, version 01 Second version. Additional section, 5.2.1, which describes when a message identifier can be reused. - November 21, 2001, version 02 Third version. Section 6 has been moved to a separate draft. The third version describes a modular solution, providing flexibility for implementers to decide which functions they want to integrate. - January 28, 2002, version 03 Fourth version. SigComp version 02 is divided into this draft, a UDVM draft and a extended operation mechanisms draft. Compressor/decompressor (UDVM) state approach has been introduced for security reasons. Table of contents 1. Introduction..................................................3 2. Terminology...................................................3 3. The SigComp Architecture......................................5 4. Applicability of SigComp......................................6 5. SigComp operation.............................................6 5.1. Pre-requisites..............................................6 5.2. Compression states..........................................7 5.3. Saving and deleting states..................................7 6. SigComp message...............................................8 7. Capability exchange...........................................8 8. Security considerations......................................10 9. IANA considerations..........................................10 10. Acknowledgements.............................................10 11. AuthorsĘ addresses...........................................10 12. References...................................................12 Hannu, et al. [Page 2] INTERNET-DRAFT SigComp January 28 , 2002 1. Introduction The Session Initiation Protocol (SIP) [SIP], along with many other application protocols used for multimedia communications, such as RTSP [RTSP], are textual protocols engineered for bandwidth rich links. As a result, these messages have not been optimized for message size. Typical SIP messages are from a few hundred bytes to as high as 2000. To date, this has not been a significant problem. With the planned usage of these protocols in wireless handsets as part of 2.5G and 3G cellular networks, the large size of these messages is problematic. With low-rate IP connectivity, store-and- forward delays are significant. Taking into account retransmits, and the multiplicity of messages that are required in some flows, call setup and feature invocation are adversely affected. Therefore, we believe there is a merit in reducing these message sizes. From the view of external users, SigComp is only to provide compression service. The service provided is that of the underlying transport plus compression. This document outline the architecture and pre-requisites of SigComp, along with the format of the SigComp message. This document does not specify a negotiation or capability exchange mechanism. The application that applies SigComp should also negotiate the usage of SigComp including capability exchange. Compression/decompression algorithms functionality for SigComp is provided by [UDVM]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Universal Decompressor Virtual Machine (UDVM) The virtual machine described in [UDVM]. The UDVM is used for decompression of SigComp messages. The UDVM is capable of interoperating with a wide range of compression algorithms. Decompressor The decompressor invokes the UDVM. It is responsible for supplying the UDVM with compressed data and make decompressed data available for the application. Hannu, et al. [Page 3] INTERNET-DRAFT SigComp January 28 , 2002 Encoder Encodes data according to a (compression) algorithm into UDVM readable code. The encoded data can be decoded by a UDVM provided with the needed instructions. Compressor The compressor invokes the encoder, and keeps track of states that can be used for compression. Responsible for supplying UDVM instructions to the peer decompressor in order for compressed data to be decompressed. State Data saved either by a compressor or a decompressor. The data reflects the contents of a UDVM memory. State index Reference to a state saved either by a compressor or a decompressor. Application Invokes the SigComp compressor and decompressor. SigComp message In case of a message oriented transport mechanism, such as UDP, a SigComp message corresponds to exactly one (UDP) packet. For a stream oriented transport, such as TCP, each SigComp message is separated by a 0xFFFF delimiter, see [UDVM]. Application data (message) Data, also referred to as message, which is to be compressed by the compressor. When delivered from the decompressor the data has passed through the decompression process and is referred to as decompressed data or decompressed message. Hannu, et al. [Page 4] INTERNET-DRAFT SigComp January 28 , 2002 3. The SigComp Architecture Compression and decompression is performed at two communicating end- points, see Figure 1. +--------------------+ +--------------------+ | Compressor 1 | | Decompressor 1 | | +---------+ | | +---------+ | | | Encoder | | | | UDVM | | | +---------+ | | +---------+ | +--------------------+ +--------------------+ ^ App. ^ | ^ | App. ^ | data | | | v data | +----|-------------|-+ +-|-------------|----+ | | | | SigComp | | | | | | Application v | message | | Application | | | v +---------->----------+ v | | +-------+ | | +-------+ | | | State | | Data transport | | State | | | +-------+ | | +-------+ | | ^ +----------<----------+ ^ | | | | | SigComp | ^ | | | | | | message | | | | +----|-------------|-+ +-|-------------|----+ | App. ^ | | | App. | v data | v | v data v +--------------------+ +--------------------+ | Decompressor 2 | | Compressor 2 | | +---------+ | | +---------+ | | | UDVM | | | | Encoder | | | +---------+ | | +---------+ | +--------------------+ +--------------------+ Figure 1. SigComp High-level view. The different components in the SigComp architecture are described below. The application is responsible for invoking the SigComp compressor and decompressor, and establish the applicability of SigComp between two communicating end points. The compressor is responsible for providing its peer decompressor with the UDVM instructions for decompression of messages. For the actual compression it invokes the encoder. The compressor also keeps track of available states, that may contain useful information for the compression process. The decompressor contains the UDVM, and is responsible for providing it with input. Hannu, et al. [Page 5] INTERNET-DRAFT SigComp January 28 , 2002 A state is data saved either by a compressor or a decompressor. The data reflects the contents of a UDVM memory. The saved state may be used for decompression/compression between a compressor and its peer decompressor, e.g. compressor 1 and decompressor 1 in Figure 1. The same state information is used both for compression and decompression. In order to retrieve a certain state its reference must be given, denoted state index. State parameters and retrieval of states are further described in [UDVM]. 4. Applicability of SigComp The application is responsible for establishing the applicability of SigComp between the communicating end points. This involves finding out the transport (e.g. UDP or TCP) and port to use for SigComp messages. [Editors note: This should be further described in draft XXXX] The parameters for the UDVM operation should be exchanged/negotiated together with the parameters in Section 7. [Editors note: This should be further described in draft XXXX] 5. SigComp operation The application provides the compressor with data to be compressed. The data is compressed by the encoder in such away that the peer decompressor with the UDVM can decompress the data correctly if the compressed data is not tampered with during the transportation. When a message is to be compressed the compressor identifies the state to use. If no state exists, one is created. An indication of the used state MUST be sent along with the compressed message to the peer decompressor. The SigComp message is then passed on to underlying layers for transport to the peer decompressor. Upon the arrival of a SigComp message the decompressor will load the UDVM with the indicated state. The message is then decompressed by the UDVM, and possible passed on to the receiving application. 5.1. Pre-requisites A compressor MUST be certain that compressed data can be decompressed before the data is to be sent, i.e. the UDVM instructions for decompression MUST be available at the peer decompressor. Some options exists: Hannu, et al. [Page 6] INTERNET-DRAFT SigComp January 28 , 2002 1. Each SigComp message sent from the compressor contains the necessary UDVM instructions for decompression. 2. By setting up a reliable connection, such as a TCP connection, between a compressor and its peer decompressor the UDVM instructions can be transferred, and an initial state is established. In order to save delay for "time-critical" sessions, the UDVM instructions should be sent prior to any initiation of "time- critical" sessions. 5.2. Compression states The UDVM may request the decompressor to save the contents of its memory, i.e. request that a state is created based on the information in the UDVM memory. If a UDVM will perform such a request depends on the instructions sent from its peer compressor. See [UDVM] for details on how a request to save a state is performed. The kind of information, which is included in a state, is up to the implementation of the compressor and the downloaded instructions to the peer decompressor's UDVM. However, as said in Section 5.1. a compressor MUST not use a state that is not known to be established at the peer decompressor. 5.3. Saving and deleting states Saving states If there already exists a state for a state index, then this state MUST not be replaced with the requested state to be saved. This is to avoid that a compressed message cannot be decompressed because its state has been replaced. Deleting states A decompressor SHOULD NOT delete a state before it is enough confident that the state is not used by a peer compressor anymore. [Editors note: I think some rules are needed to handle deletion of states] Hannu, et al. [Page 7] INTERNET-DRAFT SigComp January 28 , 2002 6. SigComp message The basic SigComp message consist of compressed data, a reference to the state the decompressor should initialize its UDVM with, and possible also a CRC. Figure 2, shows a basic SigComp message. A decompressor must be able to separate two SigComp messages, in case of UDP a SigComp message corresponds exactly to one UDP packet. For TCP each 0xFFFF delimiter, see [UDVM] is followed by a new SigComp message. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | i | c | Reserved | +---+---+---+---+---+---+---+---+ | | : state_index (n-bytes) : Present if 'i' is set | | +---+---+---+---+---+---+---+---+ | | : CRC : Present if 'c' is set | | +---+---+---+---+---+---+---+---+ | Possible | : Compressed data that should : | be given as input to the UDVM | +---+---+---+---+---+---+---+---+ Figure 2. Basic SigComp message The CRC is calculated over the uncompressed message. The reserved bits are set to zero by the compressor. In case a decompressor encounters that the Reserved bits are not all zeros, it should remove m-bytes from the SigComp message following the CRC according to: m-bytes = (bit(2) + bit(3)) * n. For the value of n see Section 7. 7. Capability exchange Applications that use SigComp MUST agree on the capabilities they intend to use. This involves exchange/negotiation of the parameters below, see also [UDVM]. Preferably the exchange of parameters is done simultaneously with the negotiation of the applicability of SigComp. Consider also Section 5.1. Hannu, et al. [Page 8] INTERNET-DRAFT SigComp January 28 , 2002 CRC Two CRCs are available to use with SigComp. CRC_1: C(x) = 1 + x + x^2 + x^8 CRC_2: C(x) = 1 + x^5 + x^12 + x^16 [Editors note: is it feasible (for implementation) to provide two CRCs in the spec?] For the parameters below consult also [UDVM]. maximum_compressed_size The maximum_compressed_size parameter limits the size of one compressed message. maximum_uncompressed_size The maximum_uncompressed_size parameter limits the size of one uncompressed message. minimum_hash_size (n-bytes) The minimum_hash_size parameter specifies the minimum size of the state index that can be used to reference state. This corresponds to the n in n-bytes. overall_memory_size The overall_memory_size parameter specifies the total number of bytes in the UDVM memory. working_memory_start The working_memory_start parameter specifies the start of the UDVM memory area that can be modified. Memory addresses below this value are considered read-only by the UDVM. working_memory_end The working_memory_end parameter specifies the end of the UDVM memory area that can be modified. Memory addresses above this value are considered read-only by the UDVM. cycles_per_bit The cycles_per_bit parameter specifies the number of "CPU cycles" that can be used to decompress a single bit of data. One CPU cycle typically corresponds to a single UDVM instruction, although some of the high-level instructions may require additional cycles. Hannu, et al. [Page 9] INTERNET-DRAFT SigComp January 28 , 2002 cycles_per_message The cycles_per_message parameter specifies the number of additional CPU cycles made available at the start of a compressed message. These cycles can be useful when decompressing algorithms that download additional data on a per-message basis, for example a new set of Huffman codes as with [DEFLATE]. The total number of "CPU cycles" available for each compressed message is specified by the following formula: total_cycles = message_size * cycles_per_bit + cycles_per_message first_instruction The first_instruction parameter specifies the memory address of the first instruction to be executed when the UDVM is initialized. 8. Security considerations [Editors note: TBW] 9. IANA considerations [Editors note: TBW] 10. Acknowledgements [Editors note: TBW] 11. AuthorsĘ addresses Hans Hannu, Editor Phone: +46 920 20 21 84 Fax: +46 920 20 20 99 E-Mail: hans.hannu@epl.ericsson.se Jan Christoffersson Phone: +46 920 20 28 40 Fax: +46 920 20 20 99 E-Mail: jan.christoffersson@epl.ericsson.se Stefan Forsgren Phone: +46 920 20 23 39 Fax: +46 920 20 20 99 E-Mail: stefan.forsgren@epl.ericsson.se Hannu, et al. [Page 10] INTERNET-DRAFT SigComp January 28 , 2002 Krister Svanbro Phone: +46 920 20 20 77 Fax: +46 920 20 20 99 E-Mail: krister.svanbro@epl.ericsson.se Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Christopher Clanton Phone: +1 972 894-4886 Fax: +1 972 894-4589 E-mail: christopher.clanton@nokia.com Khiem Le Phone: +1 972 894-4882 Fax: +1 972 894-4589 E-mail: khiem.le@nokia.com Ka Cheong Leung Phone: +1 972 374-0630 Fax: +1 972 894-4589 E-mail: kacheong.leung@nokia.com Zhigang Liu Phone: +1 972 894-5935 Fax: +1 972 894-4589 E-Mail: zhigang.liu@nokia.com Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Richard Price Phone: +44 1794 833681 E-mail: richard.price@roke.co.uk Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Jonathan Rosenberg E-mail: jdrosen@dynamicsoft.com dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 Hannu, et al. [Page 11] INTERNET-DRAFT SigComp January 28 , 2002 12. References [DEFLATE] "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, P. Deutsch, May 1996. [UDVM] R. Price et. al., Universal Decompressor Virtual Machine (UDVM), Internet Draft (work in progress), January 2002. [RTSP] H. Schulzrinne, A. Rao and R. Lanphier, Real Time Streaming Protocol (RTSP), RFC 2326, 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 July 2002. Hannu, et al. [Page 12]