Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 3320

Proposed STD
Pages: 62
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ROHC

Signaling Compression (SigComp)

Part 1 of 3, p. 1 to 15
None       Next RFC Part

Updated by:    4896

Top       ToC       Page 1 
Network Working Group                                           R. Price
Request for Comments: 3320                            Siemens/Roke Manor
Category: Standards Track                                     C. Bormann
                                                          TZI/Uni Bremen
                                                      J. Christoffersson
                                                                H. Hannu
                                                                  Z. Liu
                                                            J. Rosenberg
                                                            January 2003

                    Signaling Compression (SigComp)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


   This document defines Signaling Compression (SigComp), a solution for
   compressing messages generated by application protocols such as the
   Session Initiation Protocol (SIP) (RFC 3261) and the Real Time
   Streaming Protocol (RTSP) (RFC 2326).  The architecture and
   prerequisites of SigComp are outlined, along with the format of the
   SigComp message.

   Decompression functionality for SigComp is provided by a Universal
   Decompressor Virtual Machine (UDVM) optimized for the task of running
   decompression algorithms.  The UDVM can be configured to understand
   the output of many well-known compressors such as DEFLATE (RFC-1951).

Top       Page 2 
Table of Contents

   1.  Introduction...................................................2
   2.  Terminology....................................................3
   3.  SigComp architecture...........................................5
   4.  SigComp dispatchers...........................................15
   5.  SigComp compressor............................................18
   6.  State Handling and Feedback...................................20
   7.  SigComp message format........................................23
   8.  Overview of the UDVM..........................................28
   9.  UDVM instruction set..........................................37
   10. Security Considerations.......................................56
   11. IANA Considerations...........................................58
   12. Acknowledgements..............................................59
   13. References....................................................59
   14. Authors' Addresses............................................60
   15. Full Copyright Statement......................................62

1.  Introduction

   Many application protocols used for multimedia communications are
   text-based and engineered for bandwidth rich links.  As a result the
   messages have not been optimized in terms of size.  For example,
   typical SIP messages range from a few hundred bytes up to two
   thousand bytes or more [RFC3261].

   With the planned usage of these protocols in wireless handsets as
   part of 2.5G and 3G cellular networks, the large message size is
   problematic.  With low-rate IP connectivity the transmission delays
   are significant.  Taking into account retransmissions, and the
   multiplicity of messages that are required in some flows, call setup
   and feature invocation are adversely affected.  SigComp provides a
   means to eliminate this problem by offering robust, lossless
   compression of application messages.

   This document outlines the architecture and prerequisites of the
   SigComp solution, the format of the SigComp message and the Universal
   Decompressor Virtual Machine (UDVM) that provides decompression

   SigComp is offered to applications as a layer between the application
   and an underlying transport.  The service provided is that of the
   underlying transport plus compression.  SigComp supports a wide range
   of transports including TCP, UDP and SCTP [RFC-2960].

Top      ToC       Page 3 
2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in BCP 14, RFC 2119


      Entity that invokes SigComp and performs the following tasks:

      1. Supplying application messages to the compressor dispatcher
      2. Receiving decompressed messages from the decompressor
      3. Determining the compartment identifier for a decompressed


      Machine code that can be executed by a virtual machine.


      Entity that encodes application messages using a certain
      compression algorithm, and keeps track of state that can be used
      for compression.  The compressor is responsible for ensuring that
      the messages it generates can be decompressed by the remote UDVM.

   Compressor Dispatcher

      Entity that receives application messages, invokes a compressor,
      and forwards the resulting SigComp compressed messages to a remote

   UDVM Cycles

      A measure of the amount of "CPU power" required to execute a UDVM
      instruction (the simplest UDVM instructions require a single UDVM
      cycle).  An upper limit is placed on the number of UDVM cycles
      that can be used to decompress each bit in a SigComp message.

   Decompressor Dispatcher

      Entity that receives SigComp messages, invokes a UDVM, and
      forwards the resulting decompressed messages to the application.

Top      ToC       Page 4 

      One instance of an application, a SigComp layer, and a transport
      layer for sending and/or receiving SigComp messages.

   Message-based Transport

      A transport that carries data as a set of bounded messages.


      An application-specific grouping of messages that relate to a peer
      endpoint.  Depending on the signaling protocol, this grouping may
      relate to application concepts such as "session", "dialog",
      "connection", or "association".  The application allocates state
      memory on a per-compartment basis, and determines when a
      compartment should be created or closed.

   Compartment Identifier

      An identifier (in a locally chosen format) that uniquely
      references a compartment.


      The overall compression solution, comprising the compressor, UDVM,
      dispatchers and state handler.

   SigComp Message

      A message sent from the compressor dispatcher to the decompressor
      dispatcher.  In case of a message-based transport such as UDP, a
      SigComp message corresponds to exactly one datagram.  For a
      stream-based transport such as TCP, the SigComp messages are
      separated by reserved delimiters.

   Stream-based transport

      A transport that carries data as a continuous stream with no
      message boundaries.


      Mechanism for passing data between two endpoints.  SigComp is
      capable of sending messages over a wide range of transports
      including TCP, UDP and SCTP [RFC-2960].

Top      ToC       Page 5 
   Universal Decompressor Virtual Machine (UDVM)

      The machine architecture described in this document.  The UDVM is
      used to decompress SigComp messages.


      Data saved for retrieval by later SigComp messages.

   State Handler

      Entity responsible for accessing and storing state information
      once permission is granted by the application.

   State Identifier

      Reference used to access a previously created item of state.

3.  SigComp Architecture

   In the SigComp architecture, compression and decompression is
   performed at two communicating endpoints.  The layout of a single
   endpoint is illustrated in Figure 1:

Top      ToC       Page 6 
   |                                                                   |
   |                         Local application                         |
   |                                                                   |
                           |                       ^  |
     Application message & |          Decompressed |  | Compartment
    compartment identifier |               message |  | identifier
                           |                       |  |
   +-- -- -- -- -- -- -- --|-- -- -- -- -- -- -- --|--|-- -- -- -- -- -+
                           v                       |  v
   |    +------------------------+         +----------------------+    |
        |                        |         |                      |
   | +--|       Compressor       |         |     Decompressor     |<-+ |
     |  |       dispatcher       |         |      dispatcher      |  |
   | |  |                        |         |                      |  | |
     |  +------------------------+         +----------------------+  |
   | |  ^    ^                                             ^         | |
     |  |    |                                             |         |
   | |  |    v                                             |         | |
     |  |  +--------------+   +---------------+            |         |
   | |  |  |              |   |   +-------+   |            v         | |
     |  |  | Compressor 1 |<----->|State 1|   |    +--------------+  |
   | |  |  |              |   |   +-------+   |    |              |  | |
     |  |  +--------------+   |               |    | Decompressor |  |
   | |  |                     | State handler |<-->|              |  | |
     |  |  +--------------+   |               |    |    (UDVM)    |  |
   | |  |  |              |   |   +-------+   |    |              |  | |
     |  +->| Compressor 2 |<----->|State 2|   |    +--------------+  |
   | |     |              |   |   +-------+   |                      | |
     |     +--------------+   +---------------+      SigComp layer   |
   | |                                                               | |
   +-| -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --|-+
     |                                                               |
     | SigComp                                               SigComp |
     | message                                               message |
     v                                                               |
   |                                                                   |
   |                          Transport layer                          |
   |                                                                   |

    Figure 1: High-level architectural overview of one SigComp endpoint

Top      ToC       Page 7 
   Note that SigComp is offered to applications as a layer between the
   application and the underlying transport, and so Figure 1 is an
   endpoint when viewed from a transport layer perspective.  From the
   perspective of multi-hop application layer protocols however, SigComp
   is applied on a per-hop basis.

   The SigComp layer is further decomposed into the following entities:

   1. Compressor dispatcher - the interface from the application.  The
      application supplies the compressor dispatcher with an application
      message and a compartment identifier (see Section 3.1 for further
      details).  The compressor dispatcher invokes a particular
      compressor, which returns a SigComp message to be forwarded to the
      remote endpoint.

   2. Decompressor dispatcher - the interface towards the application.
      The decompressor dispatcher receives a SigComp message and invokes
      an instance of the Universal Decompressor Virtual Machine (UDVM).
      It then forwards the resulting decompressed message to the
      application, which may return a compartment identifier if it
      wishes to allow state to be saved for the message.

   3. One or more compressors - the entities that convert application
      messages into SigComp messages.  Distinct compressors are invoked
      on a per-compartment basis, using the compartment identifiers
      supplied by the application.  A compressor receives an application
      message from the compressor dispatcher, compresses the message,
      and returns a SigComp message to the compressor dispatcher.  Each
      compressor chooses a certain algorithm to encode the data (e.g.,

   4. UDVM - the entity that decompresses SigComp messages. Note that
      since SigComp can run over an unsecured transport layer, a
      separate instance of the UDVM is invoked on a per-message basis.
      However, during the decompression process the UDVM may invoke the
      state handler to access existing state or create new state.

   5. State handler - the entity that can store and retrieve state.
      State is information that is stored between SigComp messages,
      avoiding the need to upload the data on a per-message basis.  For
      security purposes it is only possible to create new state with the
      permission of the application.  State creation and retrieval are
      further described in Chapter 6.

Top      ToC       Page 8 
   When compressing a bidirectional application protocol the choice to
   use SigComp can be made independently in both directions, and
   compression in one direction does not necessarily imply compression
   in the reverse direction.  Moreover, even when two communicating
   endpoints send SigComp messages in both directions, there is no need
   to use the same compression algorithm in each direction.

   Note that a SigComp endpoint can decompress messages from multiple
   remote endpoints at different locations in a network, as the
   architecture is designed to prevent SigComp messages from one
   endpoint interfering with messages from a different endpoint.  A
   consequence of this design choice is that it is difficult for a
   malicious user to disrupt SigComp operation by inserting false
   compressed messages on the transport layer.

3.1.  Requirements on the Application

   From an application perspective the SigComp layer appears as a new
   transport, with similar behavior to the original transport used to
   carry uncompressed data (for example SigComp/UDP behaves similarly to
   native UDP).

   Mechanisms for discovering whether an endpoint supports SigComp are
   beyond the scope of this document.

   All SigComp messages contain a prefix (the five most-significant bits
   of the first byte are set to one) that does not occur in UTF-8
   encoded text messages [RFC-2279], so for applications which use this
   encoding (or ASCII encoding) it is possible to multiplex uncompressed
   application messages and SigComp messages on the same port.
   Applications can still reserve a new port specifically for SigComp
   however (e.g., as part of the discovery mechanism).

   If a particular endpoint wishes to be stateful then it needs to
   partition its decompressed messages into "compartments" under which
   state can be saved.  SigComp relies on the application to provide
   this partition.  So for stateful endpoints a new interface is
   required to the application in order to leverage the authentication
   mechanisms used by the application itself.

   When the application receives a decompressed message it maps the
   message to a certain compartment and supplies the compartment
   identifier to SigComp.  Each compartment is allocated a separate
   compressor and a certain amount of memory to store state information,
   so the application must assign distinct compartments to distinct
   remote endpoints.  However it is possible for a local endpoint to
   establish several compartments that relate to the same remote
   endpoint (this should be avoided where possible as it may waste

Top      ToC       Page 9 
   memory and reduce the overall compression ratio, but it does not
   cause messages to be incorrectly decompressed).  In this case,
   reliable stateful operation is possible only if the decompressor does
   not lump several messages into one compartment when the compressor
   expected them to be assigned different compartments.

   The exact format of the compartment identifier is unimportant
   provided that different identifiers are given to different

   Applications that wish to communicate using SigComp in a stateful
   fashion should use an authentication mechanism to securely map
   decompressed messages to compartment identifiers.  They should also
   agree on any limits to the lifetime of a compartment, to avoid the
   case where an endpoint accesses state information that has already
   been deleted.

3.2.  SigComp feedback mechanism

   If a signaling protocol sends SigComp messages in both directions and
   there is a one-to-one relationship between the compartments
   established by the applications on both ends ("peer compartments"),
   the two endpoints can cooperate more closely.  In this case, it is
   possible to send feedback information that monitors the behavior of
   an endpoint and helps to improve the overall compression ratio.
   SigComp performs feedback on a request/response basis, so a
   compressor makes a feedback request and receives some feedback data
   in return.  The procedure for requesting and returning feedback in
   SigComp is illustrated in Figure 2:

Top      ToC       Page 10 
    +---------------------+                     +---------------------+
    | +-----------------+ |                     | +-----------------+ |
   -->|   Compressor    |------------------------>|      UDVM       |<->
    | |  sending to B   | |   SigComp message   | |                 | |2
    | +-----------------+ | requesting feedback | +-----------------+ |
    |          ^     1,9  |                     |  3       |          |
    |          |          |                     |          v          |
    | +-----------------+ |                     | +-----------------+ |
    | |      State      | |                     | |      State      | |
    | |     handler     | |                     | |     handler     | |
    | +-----------------+ |                     | +-----------------+ |
    |          ^       8  |                     |  4       |          |
    |          |          |                     |          v          |
    | +-----------------+ |                     | +-----------------+ |
    | |      UDVM       | |                     | |   Compressor    | |
   <->|                 |<------------------------|  sending to A   |<--
   6| +-----------------+ |   SigComp message   | +-----------------+ |
    |                  7  | returning feedback  |  5                  |
    |     Endpoint A      |                     |     Endpoint B      |
    +---------------------+                     +---------------------+

       Figure 2: Steps involved in the transmission of feedback data

   The dispatchers, the application and the transport layer are omitted
   from the diagram for clarity.  Note that the decompressed messages
   pass via the decompressor dispatcher to the application; moreover the
   SigComp messages transmitted from the compressor to the remote UDVM
   are sent via first the compressor dispatcher, followed by the
   transport layer and finally the decompressor dispatcher.

   The steps for requesting and returning feedback data are described in
   more detail below:

   1. The compressor that sends messages to Endpoint B piggybacks a
      feedback request onto a SigComp message.

   2. When the application receives the decompressed message, it may
      return the compartment identifier for the message.

   3. The UDVM in Endpoint B forwards the requested feedback data to the
      state handler.

   4. If the UDVM can supply a valid compartment identifier, then the
      state handler forwards the feedback data to the appropriate
      compressor (namely the compressor sending to Endpoint A).

   5. The compressor returns the requested feedback data to Endpoint A
      piggybacked onto a SigComp message.

Top      ToC       Page 11 
   6. When the application receives the decompressed message, it may
      return the compartment identifier for the message.

   7. The UDVM in Endpoint A forwards the returned feedback data to the
      state handler.

   8. If the UDVM can supply a valid compartment identifier, then the
      state handler forwards the feedback data to the appropriate
      compressor (namely the compressor sending to Endpoint B).

   9. The compressor makes use of the returned feedback data.

   The detailed role played by each entity in the transmission of
   feedback data is explained in subsequent chapters.

3.3.  SigComp Parameters

   An advantage of using a virtual machine for decompression is that
   almost all of the implementation flexibility lies in the SigComp
   compressors.  When receiving SigComp messages an endpoint generally
   behaves in a predictable manner.

   Note however that endpoints implementing SigComp will typically have
   a wide range of capabilities, each offering a different amount of
   working memory, processing power etc.  In order to support this wide
   variation in endpoint capabilities, the following parameters are
   provided to modify SigComp behavior when receiving SigComp messages:

   locally available state (a set containing 0 or more state items)

   Each parameter has a minimum value that MUST be offered by all
   receiving SigComp endpoints.  Moreover, endpoints MAY offer
   additional resources if available; these resources can be advertised
   to remote endpoints using the SigComp feedback mechanism.

   Particular applications may also agree a-priori to offer additional
   resources as mandatory (e.g., SigComp for SIP offers a dictionary of
   common SIP phrases as a mandatory state item).

   Each of the SigComp parameters is described in greater detail below.

Top      ToC       Page 12 
3.3.1.  Memory Size and UDVM Cycles

   The decompression_memory_size parameter specifies the amount of
   memory available to decompress one SigComp message.  (Note that the
   term "amount of memory" is used on a conceptual level in order to
   specify decompressor behavior and allow resource planning on the side
   of the compressor -- an implementation could require additional,
   bounded amounts of actual memory resources or could even organize its
   memory in a completely different way as long as this does not cause
   decompression failures where the conceptual model would not.)  A
   portion of this memory is used to buffer a SigComp message before it
   is decompressed; the remainder is given to the UDVM.  Note that the
   memory is allocated on a per-message basis and can be reclaimed after
   the message has been decompressed.  All endpoints implementing
   SigComp MUST offer a decompression_memory_size of at least 2048

   The state_memory_size parameter specifies the number of bytes offered
   to a particular compartment for the creation of state.  This
   parameter is set to 0 if the endpoint is stateless.

   Unlike the other SigComp parameters, the state_memory_size is offered
   on a per-compartment basis and may vary for different compartments.
   The memory for a compartment is reclaimed when the application
   determines that the compartment is no longer required.

   The cycles_per_bit parameter specifies the number of "UDVM cycles"
   available to decompress each bit in a SigComp message.  Executing a
   UDVM instruction requires a certain number of UDVM cycles; a complete
   list of UDVM instructions and their cost in UDVM cycles can be found
   in Chapter 9.  An endpoint MUST offer a minimum of 16 cycles_per_bit.

   Each of the three parameter values MUST be chosen from the limited
   set given below, so that the parameters can be efficiently encoded
   for transmission using the SigComp feedback mechanism.

   The cycles_per_bit parameter is encoded using 2 bits, whilst the
   decompression_memory_size and state_memory_size are both encoded
   using 3 bits.  The bit encodings and their corresponding values are
   as follows:

Top      ToC       Page 13 
   Encoding:   cycles_per_bit:   Encoding:   state_memory_size (bytes):

   00          16                000         0
   01          32                001         2048
   10          64                010         4096
   11          128               011         8192
                                 100         16384
                                 101         32768
                                 110         65536
                                 111         131072

   The decompression_memory_size is encoded in the same manner as the
   state_memory_size, except that the bit pattern 000 cannot be used (as
   an endpoint cannot offer a decompression_memory_size of 0 bytes).

3.3.2.  SigComp Version

   The SigComp_version parameter specifies whether only the basic
   version of SigComp is available, or whether an upgraded version is
   available offering additional instructions etc.  Within the UDVM, it
   is available as a 2-byte value, generated by zero-extending the 1-
   byte SigComp_version parameter (i.e., the first byte of the 2-byte
   value is always zero).

   The basic version of SigComp is Version 0x01, which is the version
   described in this document.

   To ensure backwards compatibility, if a SigComp message is
   successfully decompressed by Version 0x01 of SigComp then it will be
   successfully decompressed on upgraded versions.  Similarly, if the
   message triggers a manual decompression failure (see Section 8.7),
   then it will also continue to do so.

   However, messages that cause an unexpected decompression failure on
   Version 0x01 of SigComp may be successfully decompressed by upgraded

   The simplest way to upgrade SigComp in a backwards-compatible manner
   is to add additional UDVM instructions, as this will not affect the
   decompression of SigComp messages compatible with Version 0x01.
   Reserved addresses in the UDVM memory (Useful Values, see Section
   7.2) may also be assigned values in future versions of SigComp.

Top      ToC       Page 14 
3.3.3.  Locally Available State Items

   A SigComp state item is an item of data that is retained between
   SigComp messages.  State items can be retrieved and loaded into the
   UDVM memory as part of the decompression process, often significantly
   improving the compression ratio as the same information does not have
   to be uploaded on a per-message basis.

   Each endpoint maintains a set of state items where every item is
   composed of the following information:

   Name:                      Type of data:

   state_identifier           20-byte value
   state_length               2-byte value
   state_address              2-byte value
   state_instruction          2-byte value
   minimum_access_length      2-byte value from 6 to 20 inclusive
   state_value                String of state_length consecutive bytes

   State items are typically created at an endpoint upon successful
   decompression of a SigComp message.  The remote compressor sending
   the message makes a state creation request by invoking the
   appropriate UDVM instruction, and the state is saved once permission
   is granted by the application.

   However, an endpoint MAY also wish to offer a set of locally
   available state items that have not been uploaded as part of a
   SigComp message.  For example it might offer well-known decompression
   algorithms, dictionaries of common phrases used in a specific
   signaling protocol, etc.

   Since these state items are established locally without input from a
   remote endpoint, they are most useful if publicly documented so that
   a wide collection of remote endpoints can determine the data
   contained in each state item and how it may be used.  Further
   Internet Documents and RFCs may be published to describe particular
   locally available state items.

   Although there are no locally available state items that are
   mandatory for every SigComp endpoint, certain state items can be made
   mandatory in a specific environment (e.g., the dictionary of common
   phrases for a specific signaling protocol could be made mandatory for
   that signaling protocol's usage of SigComp).  Also, remote endpoints
   can indicate their interest in receiving a list of some of the state
   items available locally at an endpoint using the SigComp feedback

Top      ToC       Page 15 
   It is a matter of local decision for an endpoint what items of
   locally available state it advertises; this decision has no influence
   on interoperability, but may increase or decrease the efficiency of
   the compression achievable between the endpoints.

(page 15 continued on part 2)

Next RFC Part