[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 5049

Network Working Group                         Zhigang Liu, Editor, Nokia
INTERNET-DRAFT                         Richard Price, Siemens/Roke Manor
Expires: August 12, 2004
                                                       February 12, 2004



Applying Signaling Compression (SigComp) to the Session Initiation
                             Protocol (SIP)
                  <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, rohc@ietf.org.


Abstract

   This document describes some specifics when Signaling Compression
   (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.




Liu & Price                                                     [Page 1]

INTERNET-DRAFT           Applying SigComp to SIP       February 12, 2004


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 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 (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.

   Note: a SigComp endpoint MAY offer additional resources if available;
   these resources can be advertised to remote endpoints as described in



Liu & Price                                                     [Page 2]

INTERNET-DRAFT           Applying SigComp to SIP       February 12, 2004


   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.




Liu & Price                                                     [Page 3]

INTERNET-DRAFT           Applying SigComp to SIP       February 12, 2004


   [Editor's note: this would prevent the use of SigComp in conjunction
   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 LAS for ANY/SigComp: none, see section 3.3.3 of [RFC-3320]

   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 representation of
   the compartment ID is a local implementation issue. The only



Liu & Price                                                     [Page 4]

INTERNET-DRAFT           Applying SigComp to SIP       February 12, 2004


   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
   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 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
   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
   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
   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.





Liu & Price                                                     [Page 5]

INTERNET-DRAFT           Applying SigComp to SIP       February 12, 2004


   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 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? 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.








Liu & Price                                                     [Page 6]

INTERNET-DRAFT           Applying SigComp to SIP       February 12, 2004


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.





















Liu & Price                                                     [Page 7]

INTERNET-DRAFT           Applying SigComp to SIP       February 12, 2004


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




10.  Full copyright statement

   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
   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



Liu & Price                                                     [Page 8]

INTERNET-DRAFT           Applying SigComp to SIP       February 12, 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



This Internet-Draft will expire on August 12, 2004.













































Liu & Price                                                     [Page 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/