Network Working Group Khiem Le INTERNET-DRAFT Zhigang Liu Date: 7 June 2001 Christopher Clanton Expires: 7 December 2001 Ka Cheong Leung Nokia Research Center Requirements for Compression of Signaling Protocol Messages Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [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 document is an individual submission to the IETF ROHC WG. Comments should be directed to its mailing list, rohc@cdt.luth.se. Abstract This document contains requirements for robust compression of signaling protocol messages, such as SIP messages. It is intended to be input material to the official working group requirements draft. Le, Liu, Clanton, and Leung [Page i] INTERNET-DRAFT Requirements for Compression 7 June 2001 Table of Contents Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2.1. Impact on Protocols and Internet Intrastructure . . . . . . 1 2.2. Coexistence with Other Schemes . . . . . . . . . . . . . . . 2 2.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 3 2.5. Compression Efficiency . . . . . . . . . . . . . . . . . . . 4 3. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 Le, Liu, Clanton, and Leung [Page ii] INTERNET-DRAFT Requirements for Compression 7 June 2001 1. Introduction The following requirements are intended to guide the design and specification of robust compression of signaling protocol messages, such as SIP messages. Robust refers to resilience against message loss, message corruption and message misordering between the compressor and decompressor. 2. Requirements 2.1. Impact on Protocols and Internet Intrastructure a) Transparency When a message is compressed and then decompressed, the resulting message must be bit-wise identical to the original message. Justification: The compression/decompression process must not alter the original protocol message because no assumption can be made about the syntax and semantics of the protocol message. Note: It is assumed that the compressed message is not subject to undetected error(s). The issue of errors is dealt with by the resilience against residual errors requirement (see section 2.3). b) Ubiquity Must not require modifications to the protocol being compressed. In particular, must not assume any traffic pattern of the protocol to be compressed. Justification: Needed for genericity of the compression scheme. c) Delay The scheme must not contribute significantly to system delay budget. Justification: Needed for genericity of the compression scheme. Le, Liu, Clanton, and Leung [Page 1] INTERNET-DRAFT Requirements for Compression 7 June 2001 2.2. Coexistence with Other Schemes a) Header Compression Must be able to use the message compression scheme in conjunction with any header compression schemes, in particular the ones defined in ROHC. Justification: Protocol compression is used because there is a need to conserve bandwidth usage. In that case, header compression will likely be needed too. Note: This requirement does not necessarily imply that the protocol message compression/decompression entity is co-located with the header compression/decompression entity. b) Encryption Must be able to use the message compression scheme in conjunction with message encryption schemes which can be end-to-end, and the compression ratio must not be degraded when encryption is present. Justification: There will likely be cases where both message compression and message encryption are required. Note: This requirement does not necessarily imply that the protocol message compression/decompression entity is co-located with the encryption entity. 2.3. Robustness a) Resilience against message loss between compressor and decompressor When such message loss happens, the decompressor must still be able to decompress correctly messages which are subsequently received without errors. Justification: A primary case of application is in cellular systems, where the path between the compressor and decompressor includes a cellular link. Message loss on the cellular link can be non-negligible. Note: It is assumed that the compressed message is not subject to undetected error(s). The issue of errors is dealt with in the Le, Liu, Clanton, and Leung [Page 2] INTERNET-DRAFT Requirements for Compression 7 June 2001 next item. b) Resilience against residual errors between compressor and decompressor The scheme must be resilient against errors undetected by the lower layers, i.e. the probability of incorrect decompression caused by such undetected errors is low. The probability should be adjustable by a design parameter. Justification: A primary case of application is in cellular systems, where the path between the compressor and decompressor includes a cellular link. Undetected errors can happen on the cellular link. c) Resilience against message misordering between compressor and decompressor The decompressor must still decompress correctly a message delivered out-of-sequence. A maximum degree of misordering is assumed, and the maximum degree of misordering that the scheme can cope with should be adjustable by a design parameter. Justification: The protocol can be carried over transport such as UDP, which do not guarantee in-order delivery. Note: It is assumed that the compressed message is not subject to undetected error(s). See item b) above. 2.4. Scalability a) Memory scalability The scheme must be scalable to accommodate a range of compressors/decompressors with varying storage capabilities. A more capable compressor must be able to interoperate with a less capable decompressor, and vice-versa. Justification: A primary case of application is in cellular systems, where one end of compression/decompression is at a mobile terminal, likely with limited memory. b) Processing scalability The scheme must be scalable to accommodate a range of compressors/decompressors with varying processing capabilities. A Le, Liu, Clanton, and Leung [Page 3] INTERNET-DRAFT Requirements for Compression 7 June 2001 more capable compressor must be able to interoperate with a less capable decompressor, and vice-versa. Justification: A primary case of application is in cellular systems, where one end of compression/decompression is at a mobile terminal, likely with limited processing power. c) Compression scalability The scheme should allow one to use additional mechanisms and/or more advanced compression methods to boost the compression efficiency, when permitted by memory and processing capabilities. An example of such a mechanism is the pre-population and downloading of the dictionary. 2.5. Compression Efficiency a) Average ratio Must provide highest compression ratio under the constraints that the above requirements are met. b) Compression efficiency should not be affected by handover, i.e. compression ratio is the same as if handover had not occurred. Justification: A primary case of application is in cellular systems, where handovers are part of normal operation. One or more handovers can happen during the life of a protocol session. Le, Liu, Clanton, and Leung [Page 4] INTERNET-DRAFT Requirements for Compression 7 June 2001 3. Authors' Addresses Khiem Le Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-4882 Fax: +1 972 894-4589 E-mail: khiem.le@nokia.com Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-5935 Fax: +1 972 894-4589 E-mail: zhigang.liu@nokia.com Christopher Clanton Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-4886 Fax: +1 972 894-4589 E-mail: christopher.clanton@nokia.com Ka Cheong Leung Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 374-0630 Fax: +1 972 894-4589 E-mail: kacheong.leung@nokia.com Le, Liu, Clanton, and Leung [Page 5]