Network Working Group Zhigang Liu, Editor, Nokia INTERNET-DRAFT Richard Price, Siemens/Roke Manor Expires:
December 17, 2003 June 17, 2003August 12, 2004 February 12, 2004 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) <draft-ietf-rohc-sigcomp-sip-00.txt><draft-ietf-rohc-sigcomp-sip-01.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 document is a submission of the IETF ROHC WG. Comments should be directed to its mailing list, firstname.lastname@example.org. Abstract This document describes some specifics when Signaling Compression (SigComp) [RFC-3320]is applied to the Session Initiation Protocol (SIP) [RFC-3261]. Any(SIP), such as default minimum values of SigComp parameters, compartment and state management, and few issues on SigComp over TCP. Any implementation that is usedof SigComp for use with SIP compressionmust followconform to this document, in addition to [RFC-3320]SigComp and [RFC-3485].support of the SIP and Session Description Protocol (SDP) static dictionary. 1. Introduction SigComp [RFC-3320] is a solution for compressing messages generated by application protocols. Although its primary driver is to compress SIP messages, the solution itself has been intentionally designed to be application agnostic so that it can be applied to any application protocols. (This is denoted as ANY/SigComp.) Consequently, many application dependent specifics are left out. It is intended that a separate document will be needed to describe those specifics when SigComp is applied to a particular application protocol. This document binds SigComp and SIP (denoted as SIP/SigComp). Any SigComp implementation that is used for SIP messagethe compression of SIP messages must followconform to this document, in additionas well as to SigComp [RFC-3320] and must support the SIP/SDP static dictionary as specified in [RFC-3485]. Note: the mechanism of discovering SigComp support at SIP layer is specified in [RFC-3486]. 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 BCP 14, RFC 2119 [RFC-2119]. 2. Minimum Values of SigComp Parameters for SIP/SigComp In order to support a wide range of capabilities among endpoints implementing SigComp, SigComp defines a few parameters to describe SigComp behaviour when receiving SigComp messages(see section 3.3 of [RFC-3320]). For each parameter, [RFC-3320] specifies a minimum value that any SigComp endpoint MUST support for ANY/SigComp. Those minimum values were determined with the consideration of all imaginable devices in which SigComp may be implemented. Scalability iswas also considered as a key factor. However, some of the minimum values specified in [RFC-3320] are too small to allow good performance for SIP message compression. Therefore, they are increased for SIP/SigComp as specified in the following sections. For completeness, those parameters that are the same for SIP/SigComp as they are for ANY/SigComp are also listed. Note: the new minimum values are specific to SIP/SigComp. They do not apply to any other application protocols. Note: a SigComp endpoint MAY offer additional resources if available; these resources can be advertised to remote endpoints as described in section 9.4.9 of [RFC-3320]. 2.1. decompression_memory_size (DMS) for SIP/SigComp Minimum value for ANY/SigComp: 2048 bytes, as specified in section 3.3.1 of [RFC-3320]. Minimum value for SIP/SigComp: 8192 bytes. Reason: DMS of 2048 bytes is too small for SIP message compression, as it seriously limits the compression ratio and even makes compression impossible for certain messages. For example, the condition set by [RFC-3320] for SigComp over UDP means: C + 2*B + R + 2*S + 128 < DMS (each term is described below). On the other hand, 8KB additional memory should not cause any problem for an endpoint that implements SIP, SigComp, and applications that use SIP. C = size of compressed application message, depending on R. B = size of bytecode (note: two copies - one as part of SigComp message and one in UDVM memory) R = size of ring buffer in UDVM memory S = any additional state uploaded other than that created from the content of the ring buffer at the end of decompression. Similar to B, two copies of S are needed 128 = the smallest address in UDVM memory to copy bytecode Note: DMS is per SigComp message and the memory can be reclaimed after the message has been decompressed. 2.2. state_memory_size (SMS) for SIP/SigComp Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in section 3.3.1 of [RFC-3320]. Minimum value for SIP/SigComp: 2048 bytes. Reason: a non-zero SMS allows an endpoint to upload a state in the first SIP message sent to a remote endpoint without the uncertainty of whether or not it can be created in the remote endpoint due to lack of memory. Note: SMS is per compartment. An endpoint MAY offer different SMS for different compartments as long as the SMS is not less than 2048 bytes. [Editor's note: this would prevent the use of SigComp in conjunction with stateless SIP proxies. Is this acceptable?]acceptable? Discussions on benefit/cost are ongoing in the ROHC mailing list.] 2.3. cycles_per_bit (CPB) for SIP/SigComp Minimum value for ANY/SigComp: 16, as specified in section 3.3.1 of [RFC-3320]. Minimum value for SIP/SigComp: 16 (same as above) 2.4. SigComp_version (SV) for SIP/SigComp For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC-3320]. For SIP/SigComp: 0x01 (same as above) 2.5. locally available state (LAS) for SIP/SigComp Minimum valueLAS for ANY/SigComp: none, see section 3.3.3 of [RFC-3320] Minimum valueLAS for SIP/SigComp: the SIP/SDP-specificSIP/SDP static dictionary as defined in [RFC-3485]. 3. Compartment and State Management for SIP/SigComp When SigComp is applied to SIP, there is a one-to-one relationship between a SIP dialog (see section 12 of [RFC-3261]) and a pair of peer SigComp compartments. The mapping is handled by SIP (not SigComp) as follows: - When a SIP user agent client (UAC) compresses and sends a request that can establish a dialog (such as INVITE), it creates a compartment associated with the dialog. - When a SIP user agent server (UAS) receives a compressed request and decides to respond with a response that establishes a dialog (such as a 2xx to INVITE), it creates a compartment associated with the dialog. - Conceptually, the SIP layer of each SigComp endpoint uses the dialog ID as the SigComp compartment ID for the compartment associated with the dialog. However, the actual presentationrepresentation of the compartment ID is a local implementation issue. The only requirement is to maintain a local one-to-one mapping between a dialog ID and a compartment ID. - A SigComp compartment will be closed by SIP when the corresponding dialog is terminated. Usually, any states created during the lifetime of a compartment will be "logically" deleted when the compartment is closed. A logical deletion becomes a physical one when all the compartments that created the (same) state are closed. However, a sigcompSigComp endpoint may offer to keep a state created upon request from its peer endpoint during a dialog beyond the duration of that dialog. This may improve compression efficiency of SIP messages generated by the same peer endpoint in subsequent dialogs. In that case, it can inform its peer sigcompSigComp endpoint by announcing the (partial) state ID in the returned SigComp parameters at the end of the dialog. That signals the state will be maintained until the associated timer times out. Since there is no mechanism in SigComp and SIP to convey the timeout value, a default value needs to be specified [Editor's note: actual value will be determined later]. The default value can be overwritten by different means in a particular SIP configuration so long as the value is known to and agreed by all SigComp endpoints involved. If one sigcompSigComp endpoint is a SIP registrar server and its peer endpoints register with it, the lifetime of the state can be specified to be the same as that of the registration. [Editor's note: this is more complicated than it appears. Above is only preliminary text serving as a starting point. There are alternative approaches such as associating states or compartments with URIs that are persistent through dialogs. More work is needed on this section before the next version ofimprovements and alternatives being discussed in the draft.]ROHC WG.] 4. Delimiting SIP Messages and SigComp Messages on the Same Port In order to limit the number of ports required by a SigComp-aware endpoint, it is possible to multiplex SigComp messages and 'vanilla' SIP messages (i.e. uncompressed SIP messages with no SigComp header) on the same port. For a message-based transport such as UDP, the receiving endpoint checks the first octet of the UDP payload to determine whether the message has been compressed using SigComp. If the MSBs of the octet are "11111" then the message is considered to be a SigComp message and is parsed as per [RFC-3320]. If the MSBs of the octet take any other value, then the message is assumed to be an uncompressed SIP message, and is passed directly to the application with no further effect on the SigComp layer. For a stream-based transport such as TCP, the receiving endpoint checks the first octet of the TCP data stream to determine whether the stream has been compressed using SigComp. If the MSBs of the octet are "11111" then the stream is considered to contain SigComp messages and is parsed as per [RFC-3320]. If the MSBs of the octet take any other value, then the stream is assumed to contain uncompressed SIP messages, and is passed directly to the application with no further effect on the SigComp layer. Note that SigComp message delimiters MUST NOT be used if the stream contains uncompressed SIP messages. Applications MUST NOT mix SIP messages and SigComp messages on a single TCP connection. If the TCP connection is used to carry SigComp messages then all messages sent over the connection MUST have a SigComp header.header and be delimited by the use of 0xFFFF as described in [RFC 3320]. [Editor's note: there have been discussions on the need of multiplexing SigComp and non-SigComp messages on the same TCP connection. However, no conclusion was reached.] 5. Continuous Mode over TCP Continuous Mode is a special feature of SigComp, which is designed to improve the overall compression ratio for long-lived connections. However, it requires the transport itself to provide a certain level of protection against denial of service attacks. TCP is not considered to provide enough protection, and so Continuous Mode MUST NOT be used over TCP. [Editor's note: is this too restrictive in cases where IPsec is enabled below TCP?]TCP? There have been no comments on this issue so far.] 6. Security Considerations The same security considerations as described in [RFC-3320] apply to this document. Note that keeping SigComp states longer than the duration of a SIP dialog should not pose new security risks for two reasons: a) the state has been allowed to be created in the first place; and b) this is on voluntary basis and a SigComp endpoint can choose not to offer it. 7. Acknowledgements The authors would like to thank the following people for their comments and suggestions: Carsten Bormann, Jan Christoffersson, Pekka Pessi, Robert Sugar, Abigail Surtees, and Mark West. 8. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC-3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. [RFC-3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A. Adam, "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003. [RFC-3486] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003. 8.9. Authors' Addresses Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-5935 E-mail: email@example.com Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Phone: +44 1794 833681 Email: firstname.lastname@example.org 9.10. Full copyright statement Copyright (C) The Internet Society (2003).(2004). 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft will expire on December 17, 2003.August 12, 2004.