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

Versions: (draft-ietf-rohc-sigcomp-udvm) 00 01 02 03 04 05 06 RFC 3320

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)
                    <draft-ietf-rohc-sigcomp-03.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 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.
               <draft-ietf-rohc-sigcomp-udvm-00.txt>

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


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