--- 1/draft-ietf-rohc-sigcomp-sip-00.txt 2006-02-05 01:26:27.000000000 +0100 +++ 2/draft-ietf-rohc-sigcomp-sip-01.txt 2006-02-05 01:26:27.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group Zhigang Liu, Editor, Nokia INTERNET-DRAFT Richard Price, Siemens/Roke Manor -Expires: December 17, 2003 - June 17, 2003 +Expires: August 12, 2004 + February 12, 2004 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) - + 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. @@ -28,58 +28,62 @@ 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@ietf.org. Abstract This document describes some specifics when Signaling Compression - (SigComp) [RFC-3320] is applied to the Session Initiation Protocol - (SIP) [RFC-3261]. Any SigComp implementation that is used for SIP - compression must follow this document, in addition to [RFC-3320] and - [RFC-3485]. + (SigComp) is applied to the Session Initiation Protocol (SIP), such + as default minimum values of SigComp parameters, compartment and + state management, and few issues on SigComp over TCP. Any + implementation of SigComp for use with SIP must conform to this + document, in addition to SigComp and 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 message compression must - follow this document, in addition to [RFC-3320] and [RFC-3485]. + SigComp implementation that is used for the compression of SIP + messages must conform to this document, as 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 is also - considered as a key factor. + SigComp behaviour (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 was 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. @@ -116,101 +120,100 @@ 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 it can be created in the remote endpoint due to lack of - memory. + 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?] + with stateless SIP proxies. Is this 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 value for ANY/SigComp: none, see section 3.3.3 of [RFC-3320] + Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC-3320] - Minimum value for SIP/SigComp: the SIP/SDP-specific static dictionary - as defined in [RFC-3485]. + Minimum LAS for SIP/SigComp: the SIP/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 presentation 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. + associated with the dialog. However, the actual representation 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 sigcomp endpoint may + created the (same) state are closed. However, a SigComp 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 - sigcomp endpoint by announcing the (partial) state ID in the returned + SigComp 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 sigcomp endpoint is a SIP registrar server and its peer endpoints + one SigComp 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 of the draft.] + improvements and alternatives being discussed in the 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 @@ -228,44 +231,55 @@ 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. + a SigComp 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?] + enabled below 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. Normative References +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., @@ -274,42 +288,42 @@ [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. Authors' Addresses +9. Authors' Addresses Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-5935 E-mail: zhigang.c.liu@nokia.com Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Phone: +44 1794 833681 Email: richard.price@roke.co.uk -9. Full copyright statement +10. Full copyright statement - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (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 @@ -321,11 +335,11 @@ 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. +This Internet-Draft will expire on August 12, 2004.