GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3320

Network Working Group R. Price Request for Comments: 3320 Siemens/Roke Manor Category: Standards Track C. Bormann

                                                        TZI/Uni Bremen
                                                    J. Christoffersson
                                                              H. Hannu
                                                              Ericsson
                                                                Z. Liu
                                                                 Nokia
                                                          J. Rosenberg
                                                           dynamicsoft
                                                          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.

Abstract

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

Price, et. al. Standards Track [Page 1] RFC 3320 Signaling Compression (SigComp) January 2003

Table of Contents

 1.  Introduction...................................................2
 2.  Terminology....................................................3
 3.  SigComp architecture...........................................5
 4.  SigComp dispatchers...........................................15
 5.  SigComp compressor............................................18
 6.  SigComp state handler.........................................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
 functionality.
 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].

Price, et. al. Standards Track [Page 2] RFC 3320 Signaling Compression (SigComp) January 2003

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 BCP 14, RFC 2119
 [RFC-2119].
 Application
    Entity that invokes SigComp and performs the following tasks:
    1. Supplying application messages to the compressor dispatcher
    2. Receiving decompressed messages from the decompressor
       dispatcher
    3. Determining the compartment identifier for a decompressed
       message.
 Bytecode
    Machine code that can be executed by a virtual machine.
 Compressor
    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
    endpoint.
 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.

Price, et. al. Standards Track [Page 3] RFC 3320 Signaling Compression (SigComp) January 2003

 Endpoint
    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.
 Compartment
    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.
 SigComp
    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.
 Transport
    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].

Price, et. al. Standards Track [Page 4] RFC 3320 Signaling Compression (SigComp) January 2003

 Universal Decompressor Virtual Machine (UDVM)
    The machine architecture described in this document.  The UDVM is
    used to decompress SigComp messages.
 State
    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:

Price, et. al. Standards Track [Page 5] RFC 3320 Signaling Compression (SigComp) January 2003

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

Price, et. al. Standards Track [Page 6] RFC 3320 Signaling Compression (SigComp) January 2003

 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.,
    DEFLATE).
 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.

Price, et. al. Standards Track [Page 7] RFC 3320 Signaling Compression (SigComp) January 2003

 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

Price, et. al. Standards Track [Page 8] RFC 3320 Signaling Compression (SigComp) January 2003

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

Price, et. al. Standards Track [Page 9] RFC 3320 Signaling Compression (SigComp) January 2003

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

Price, et. al. Standards Track [Page 10] RFC 3320 Signaling Compression (SigComp) January 2003

 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:
 decompression_memory_size
 state_memory_size
 cycles_per_bit
 SigComp_version
 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.

Price, et. al. Standards Track [Page 11] RFC 3320 Signaling Compression (SigComp) January 2003

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

Price, et. al. Standards Track [Page 12] RFC 3320 Signaling Compression (SigComp) January 2003

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

Price, et. al. Standards Track [Page 13] RFC 3320 Signaling Compression (SigComp) January 2003

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

Price, et. al. Standards Track [Page 14] RFC 3320 Signaling Compression (SigComp) January 2003

 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.

4. SigComp Dispatchers

 This chapter defines the behavior of the compressor and decompressor
 dispatcher.  The function of these entities is to provide an
 interface between SigComp and its environment, minimizing the effort
 needed to integrate SigComp into an existing protocol stack.

4.1. Compressor Dispatcher

 The compressor dispatcher receives messages from the application and
 passes the compressed version of each message to the transport layer.
 Note that SigComp invokes compressors on a per-compartment basis, so
 when the application provides a message to be compressed it must also
 provide a compartment identifier.  The compressor dispatcher forwards
 the application message to the correct compressor based on the
 compartment identifier (invoking a new compressor if a new
 compartment identifier is encountered).  The compressor returns a
 SigComp message that can be passed to the transport layer.
 Additionally, the application should indicate to the compressor
 dispatcher when it wishes to close a particular compartment, so that
 the resources taken by the corresponding compressor can be reclaimed.

4.2. Decompressor Dispatcher

 The decompressor dispatcher receives messages from the transport
 layer and passes the decompressed version of each message to the
 application.
 To ensure that SigComp can run over an unsecured transport layer, the
 decompressor dispatcher invokes a new instance of the UDVM for each
 new SigComp message.  Resources for the UDVM are released as soon as
 the message has been decompressed.
 The dispatcher MUST NOT make more than one SigComp message available
 to a given instance of the UDVM.  In particular, the dispatcher MUST
 NOT concatenate two SigComp messages to form a single message.

Price, et. al. Standards Track [Page 15] RFC 3320 Signaling Compression (SigComp) January 2003

4.2.1. Decompressor Dispatcher Strategies

 Once the UDVM has been invoked it is initialized using the SigComp
 message of Chapter 7.  The message is then decompressed by the UDVM,
 returned to the decompressor dispatcher, and passed on to the
 receiving application.  Note that the UDVM has no awareness of
 whether the underlying transport is message-based or stream-based,
 and so it always outputs decompressed data as a stream.  It is the
 responsibility of the dispatcher to provide the decompressed message
 to the application in the expected form (i.e., as a stream or as a
 distinct, bounded message).  The dispatcher knows that the end of a
 decompressed message has been reached when the UDVM instruction END-
 MESSAGE is invoked (see Section 9.4.9).
 For a stream-based transport, two strategies are therefore possible
 for the decompressor dispatcher:
 1) The dispatcher collects a complete SigComp message and then
    invokes the UDVM.  The advantage is that, even in implementations
    that have multiple incoming compressed streams, only one instance
    of the UDVM is ever required.
 2) The dispatcher collects the SigComp header (see Section 7) and
    invokes the UDVM; the UDVM stays active while the rest of the
    message arrives.  The advantage is that there is no need to buffer
    up the rest of the message; the message can be decompressed as it
    arrives, and any decompressed output can be relayed to the
    application immediately.
 In general, which of the strategies is used is an implementation
 choice.
 However, the compressor may want to take advantage of strategy 2 by
 expecting that some of the application message is passed on to the
 application before the SigComp message is terminated, e.g., by
 keeping the UDVM active while expecting the application to
 continuously receive decompressed output.  This approach ("continuous
 mode") invalidates some assumptions of the SigComp security model and
 can only be used if the transport itself can provide the required
 protection against denial of service attacks.  Also, since only
 strategy 2 works in this approach, the use of continuous mode
 requires previous agreement between the two endpoints.

4.2.2. Record Marking

 For a stream-based transport, the dispatcher delimits messages by
 parsing the compressed data stream for instances of 0xFF and taking
 the following actions:

Price, et. al. Standards Track [Page 16] RFC 3320 Signaling Compression (SigComp) January 2003

 Occurs in data stream:     Action:
 0xFF 00                    one 0xFF byte in the data stream
 0xFF 01                    same, but the next byte is quoted (could
                            be another 0xFF)
    :                                           :
 0xFF 7F                    same, but the next 127 bytes are quoted
 0xFF 80 to 0xFF FE         (reserved for future standardization)
 0xFF FF                    end of SigComp message
 The combinations 0xFF01 to 0xFF7F are useful to limit the worst case
 expansion of the record marking scheme:  the 1 (0xFF01) to 127
 (0xFF7F) bytes following the byte combination are copied literally by
 the decompressor without taking any special action on 0xFF.  (Note
 that 0xFF00 is just a special case of this, where zero following
 bytes are copied literally.)
 In UDVM version 0x01, any occurrence of the combinations 0xFF80 to
 0xFFFE that are not protected by quoting causes decompression
 failure; the decompressor SHOULD close the stream-based transport in
 this case.

4.3. Returning a Compartment Identifier

 Upon receiving a decompressed message the application may supply the
 dispatcher with a compartment identifier.  Supplying this identifier
 grants permission for the following:
 1. Items of state accompanying the decompressed message can be saved
    using the state memory reserved for the specified compartment.
 2. The feedback data accompanying the decompressed message can be
    trusted sufficiently that it can be used when sending SigComp
    messages that relate to the compressor's equivalent for the
    compartment.
 The dispatcher passes the compartment identifier to the UDVM, where
 it is used as per the END-MESSAGE instruction (see Section 9.4.9).
 The application uses a suitable authentication mechanism to determine
 whether the decompressed message belongs to a legitimate compartment
 or not.  If the application fails to authenticate the message with
 sufficient confidence to allow state to be saved or feedback data to
 be trusted, it supplies a "no valid compartment" error to the
 dispatcher and the UDVM is terminated without creating any state or
 forwarding any feedback data.

Price, et. al. Standards Track [Page 17] RFC 3320 Signaling Compression (SigComp) January 2003

5. SigComp Compressor

 An important feature of SigComp is that decompression functionality
 is provided by a Universal Decompressor Virtual Machine (UDVM).  This
 means that the compressor can choose any algorithm to generate
 compressed SigComp messages, and then upload bytecode for the
 corresponding decompression algorithm to the UDVM as part of the
 SigComp message.
 To help with the implementation and testing of a SigComp endpoint,
 further Internet Documents and RFCs may be published to describe
 particular compression algorithms.
 The overall requirement placed on the compressor is that of
 transparency, i.e., the compressor MUST NOT send bytecode which
 causes the UDVM to incorrectly decompress a given SigComp message.
 The following more specific requirements are also placed on the
 compressor (they can be considered particular instances of the
 transparency requirement):
 1. For robustness, it is recommended that the compressor supply some
    form of integrity check (not necessarily of cryptographic
    strength) over the application message to ensure that successful
    decompression has occurred.  A UDVM instruction is provided for
    CRC verification; also, another instruction can be used to compute
    a SHA-1 cryptographic hash.
 2. The compressor MUST ensure that the message can be decompressed
    using the resources available at the remote endpoint.
 3. If the transport is message-based, then the compressor MUST map
    each application message to exactly one SigComp message.
 4. If the transport is stream-based but the application defines its
    own internal message boundaries, then the compressor SHOULD map
    each application message to exactly one SigComp message.
 Message boundaries should be preserved over a stream-based transport
 so that accidental or malicious damage to one SigComp message does
 not affect the decompression of subsequent messages.
 Additionally, if the state handler passes some requested feedback to
 the compressor, then it SHOULD be returned in the next SigComp
 message generated by the compressor (unless the state handler passes
 some newer requested feedback before the older feedback has been
 sent, in which case the older feedback is deleted).

Price, et. al. Standards Track [Page 18] RFC 3320 Signaling Compression (SigComp) January 2003

 If present, the requested feedback item SHOULD be copied unmodified
 into the returned_feedback_item field provided in the SigComp
 message.  Note that there is no need to transmit any requested
 feedback item more than once.
 The compressor SHOULD also upload the local SigComp parameters to the
 remote endpoint, unless the endpoint has indicated that it does not
 wish to receive these parameters or the compressor determines that
 the parameters have already successfully arrived (see Section 5.1 for
 details of how this can be achieved).  The SigComp parameters are
 uploaded to the UDVM memory at the remote endpoint as described in
 Section 9.4.9.

5.1. Ensuring Successful Decompression

 A compressor MUST be certain that all of the data needed to
 decompress a SigComp message is available at the receiving endpoint.
 One way to ensure this is to send all of the needed information in
 every SigComp message (including bytecode to decompress the message).
 However, the compression ratio for this method will be relatively
 low.
 To obtain the best overall compression ratio the compressor needs to
 request the creation of new state items at the remote endpoint.  The
 information saved in these state items can then be accessed by later
 SigComp messages, avoiding the need to upload the data on a per-
 message basis.
 Before the compressor can access saved state however, it must ensure
 that the SigComp message carrying the state creation request arrived
 successfully at the receiving endpoint.  For a reliable transport
 (e.g., TCP or SCTP) this is guaranteed.  For an unreliable transport
 however, the compressor must provide a suitable mechanism itself (see
 [RFC-3321] for further details).
 The compressor must also ensure that the state item it wishes to
 access has not been rejected due to a lack of state memory.  This can
 be accomplished by checking the state_memory_size parameter using the
 SigComp feedback mechanism (see Section 9.4.9 for further details).

5.2. Compression Failure

 The compressor SHOULD make every effort to successfully compress an
 application message, but in certain cases this might not be possible
 (particularly if resources are scarce at the receiving endpoint). In
 this case a "compression failure" is called.

Price, et. al. Standards Track [Page 19] RFC 3320 Signaling Compression (SigComp) January 2003

 If a compression failure occurs then the compressor informs the
 dispatcher and takes no further action.  The dispatcher MUST report
 this failure to the application so that it can try other methods to
 deliver the message.

6. State Handling and Feedback

 This chapter defines the behavior of the SigComp state handler.  The
 function of the state handler is to retain information between
 received SigComp messages; it is the only SigComp entity that is
 capable of this function, and so it is of particular importance from
 a security perspective.

6.1. Creating and Accessing State

 To provide security against the malicious insertion or modification
 of SigComp messages, a separate instance of the UDVM is invoked to
 decompress each message.  This ensures that damaged SigComp messages
 do not prevent the successful decompression of subsequent valid
 messages.
 Note, however, that the overall compression ratio is often
 significantly higher if messages can be compressed relative to the
 information contained in previous messages.  For this reason, it is
 possible to create state items for access when a later message is
 being decompressed.  Both the creation and access of state are
 designed to be secure against malicious tampering with the compressed
 data.  The UDVM can only create a state item when a complete message
 has been successfully decompressed and the application has returned a
 compartment identifier under which the state can be saved.
 State access cannot be protected by relying on the application alone,
 since the authentication mechanism may require information from the
 decompressed message (which of course is not available until after
 the state has been accessed).  Instead, SigComp protects state access
 by creating a state identifier that is a hash over the item of state
 to be retrieved.  This state_identifier must be supplied to retrieve
 an item of state from the state handler.
 Also note that state is not deleted when it is accessed.  So even if
 a malicious sender manages to access some state information,
 subsequent messages compressed relative to this state can still be
 successfully decompressed.
 Each state item contains a state_identifier that is used to access
 the state.  One state identifier can be supplied in the SigComp
 message header to initialize the UDVM (see Chapter 7); additional
 state items can be retrieved using the STATE-ACCESS instruction.  The

Price, et. al. Standards Track [Page 20] RFC 3320 Signaling Compression (SigComp) January 2003

 UDVM can also request the creation of a new state item by using the
 STATE-CREATE and END-MESSAGE instructions (see Chapter 9 for further
 details).

6.2. Memory Management

 The state handler manages state memory on a per-compartment basis.
 Each compartment can store state up to a certain state_memory_size
 (where the application may assign different values for the
 state_memory_size parameter to different compartments).
 As well as storing the state items themselves, the state handler
 maintains a list of the state items created by a particular
 compartment and ensures that no compartment exceeds its allocated
 state_memory_size.  For the purpose of calculation, each state item
 is considered to cost (state_length + 64) bytes.
 Each instance of the UDVM can pass up to four state creation requests
 to the state handler, as well as up to four state free requests (the
 latter are requests to free the memory taken by a state item in a
 certain compartment).  When the state handler receives a state
 creation request from the UDVM it takes the following steps:
 1. The state handler MUST reject all state creation requests that are
    not accompanied by a valid compartment identifier, or if the
    compartment is allocated 0 bytes of state memory. Note that if a
    state creation request fails due to lack of state memory then it
    does not mean that the corresponding SigComp message is damaged;
    compressors will often make state creation requests in the first
    SigComp message of a compartment, before they have discovered the
    state_memory_size using the SigComp feedback mechanism.
 2. If the state creation request needs more state memory than the
    total state_memory_size for the compartment, the state handler
    deletes all but the first (state_memory_size - 64) bytes from the
    state_value.  It sets the state_length to (state_memory_size -
    64), and recalculates the state_identifier as defined in Section
    9.4.9.
 3. If the state creation request contains a state_identifier that
    already exists then the state handler checks whether the requested
    state item is identical to the established state item and counts
    the state creation request as successful if this is the case.  If
    not then the state creation request is unsuccessful (although the
    probability that this will occur is vanishingly small).

Price, et. al. Standards Track [Page 21] RFC 3320 Signaling Compression (SigComp) January 2003

 4. If the state creation request exceeds the state memory allocated
    to the compartment, sufficient items of state created by the same
    compartment are freed until enough memory is available to
    accommodate the new state.  When a state item is freed, it is
    removed from the list of states created by the compartment and the
    memory cost of the state item no longer counts towards the total
    cost for the compartment.  Note, however, that identical state
    items may be created by several different compartments, so a state
    item must not be physically deleted unless the state handler
    determines that it is no longer required by any compartment.
 5. The order in which the existing state items are freed is
    determined by the state_retention_priority, which is set when the
    state items are created.  The state_retention_priority of 65535 is
    reserved for locally available states; these states must always be
    freed first.  Apart from this special case, states with the lowest
    state_retention_priority are always freed first.  In the event of
    a tie, then the state item created first in the compartment is
    also the first to be freed.
 The state_retention_priority is always stored on a per-compartment
 basis as part of the list of state items created by each compartment.
 In particular, the same state item might have several priority values
 if it has been created by several different compartments.
 Note that locally available state items (as described in Section
 3.3.3) need not be mapped to any particular compartment.  However, if
 they are created on a per-compartment basis, then they must not
 interfere with the state created at the request of the remote
 endpoint.  The special state_retention_priority of 65535 is reserved
 for locally available state items to ensure that this is the case.
 The UDVM may also explicitly request the state handler to free a
 specific state item in a compartment.  In this case, the state
 handler deletes the state item from the list of state items created
 by the compartment (as before the state item itself must not be
 physically deleted unless the state handler determines that it is not
 longer required by any compartment).
 The application should indicate to the state handler when it wishes
 to close a particular compartment, so that the resources taken by the
 corresponding state can be reclaimed.

Price, et. al. Standards Track [Page 22] RFC 3320 Signaling Compression (SigComp) January 2003

6.3. Feedback Data

 The SigComp feedback mechanism allows feedback data to be received by
 a UDVM and forwarded via the state handler to the correct compressor.
 Since this feedback data is retained between SigComp messages, it is
 considered to be part of the overall state and can only be forwarded
 if accompanied by a valid compartment identifier.  If this is the
 case, then the state handler forwards the feedback data to the
 compressor responsible for sending messages that pertain to the peer
 compartment of the specified compartment.

7. SigComp Message Format

 This chapter describes the format of the SigComp message and how the
 message is used to initialize the UDVM memory.
 Note that the SigComp message is not copied into the UDVM memory as
 soon as it arrives; instead, the UDVM indicates when it requires
 compressed data using a specific instruction.  It then pauses and
 waits for the information to be supplied before executing the next
 instruction.  This means that the UDVM can begin to decompress a
 SigComp message before the entire message has been received.
 A consequence of the above behavior is that when the UDVM is invoked,
 the size of the UDVM memory depends on whether the transport used to
 provide the SigComp message is stream-based or message-based.  If the
 transport is message-based then sufficient memory must be available
 to buffer the entire SigComp message before it is passed to the UDVM.
 So if the message is n bytes long, then the UDVM memory size is set
 to (decompression_memory_size - n), up to a maximum of 65536 bytes.
 If the transport is stream-based however, then a fixed-size input
 buffer is required to accommodate the stream, independently of the
 size of each SigComp message. So, for simplicity, the UDVM memory
 size is set to (decompression_memory_size / 2).
 As a separate instance of the UDVM is invoked on a per-message basis,
 each SigComp message must explicitly indicate its chosen
 decompression algorithm as well as any additional information that is
 needed to decompress the message (e.g., one or more previously
 received messages, a dictionary of common SIP phrases etc.).  This
 information can either be uploaded as part of the SigComp message or
 retrieved from an item of state.

Price, et. al. Standards Track [Page 23] RFC 3320 Signaling Compression (SigComp) January 2003

 A SigComp message takes one of two forms depending on whether it
 accesses a state item at the receiving endpoint.  The two variants of
 a SigComp message are given in Figure 3.  (The T-bit controls the
 format of the returned feedback item and is defined in Section 7.1.)
   0   1   2   3   4   5   6   7       0   1   2   3   4   5   6   7
 +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
 | 1   1   1   1   1 | T |  len  |   | 1   1   1   1   1 | T |   0   |
 +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
 |                               |   |                               |
 :    returned feedback item     :   :    returned feedback item     :
 |                               |   |                               |
 +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
 |                               |   |           code_len            |
 :   partial state identifier    :   +---+---+---+---+---+---+---+---+
 |                               |   |   code_len    |  destination  |
 +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
 |                               |   |                               |
 :   remaining SigComp message   :   :    uploaded UDVM bytecode     :
 |                               |   |                               |
 +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
                                     |                               |
                                     :   remaining SigComp message   :
                                     |                               |
                                     +---+---+---+---+---+---+---+---+
                 Figure 3: Format of a SigComp message
 Decompression failure occurs if the SigComp message is too short to
 contain the expected fields (see Section 8.7 for further details).
 The fields except for the "remaining SigComp message" are referred to
 as the "SigComp header" (note that this may include the uploaded UDVM
 bytecode).

7.1. Returned feedback item

 For both variants of the SigComp message, the T-bit is set to 1
 whenever the SigComp message contains a returned feedback item.  The
 format of the returned feedback item is illustrated in Figure 4.

Price, et. al. Standards Track [Page 24] RFC 3320 Signaling Compression (SigComp) January 2003

   0   1   2   3   4   5   6   7       0   1   2   3   4   5   6   7
 +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
 | 0 |  returned_feedback_field  |   | 1 | returned_feedback_length  |
 +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
                                     |                               |
                                     :    returned_feedback_field    :
                                     |                               |
                                     +---+---+---+---+---+---+---+---+
              Figure 4: Format of returned feedback item
 Note that the returned feedback length specifies the size of the
 returned feedback field (from 0 to 127 bytes).  So the total size of
 the returned feedback item lies between 1 and 128 bytes.
 The returned feedback item is not copied to the UDVM memory; instead,
 it is buffered until the UDVM has successfully decompressed the
 SigComp message.  It is then forwarded to the state handler with the
 rest of the feedback data (see Section 9.4.9 for further details).

7.2. Accessing Stored State

 The len field of the SigComp message determines which fields follow
 the returned feedback item.  If the len field is non-zero, then the
 SigComp message contains a state identifier to access a state item at
 the receiving endpoint.  All state items include a 20-byte state
 identifier as per Section 3.3.3, but it is possible to transmit as
 few as 6 bytes from the identifier if the sender believes that this
 is sufficient to match a unique state item at the receiving endpoint.
 The len field encodes the number of transmitted bytes as follows:
 Encoding:   Length of partial state identifier
 01          6 bytes
 10          9 bytes
 11          12 bytes
 The partial state identifier is passed to the state handler, which
 compares it with the most significant bytes of the state_identifier
 in every currently stored state item.  Decompression failure occurs
 if no state item is matched or if more than one state item is
 matched.

Price, et. al. Standards Track [Page 25] RFC 3320 Signaling Compression (SigComp) January 2003

 Decompression failure also occurs if exactly one state item is
 matched but the state item contains a minimum_access_length greater
 than the length of the partial state identifier.  This prevents
 especially sensitive state items from being accessed maliciously by
 brute force guessing of the state_identifier.
 If a state item is successfully accessed then the state_value byte
 string is copied into the UDVM memory beginning at state_address.
 The first 32 bytes of UDVM memory are then initialized to special
 values as illustrated in Figure 5.
                    0             7 8            15
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |       UDVM_memory_size        |  0 - 1
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |        cycles_per_bit         |  2 - 3
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |        SigComp_version        |  4 - 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |    partial_state_ID_length    |  6 - 7
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |         state_length          |  8 - 9
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                               |
                   :           reserved            :  10 - 31
                   |                               |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 5: Initializing Useful Values in UDVM memory
 The first five 2-byte words are initialized to contain some values
 that might be useful to the UDVM bytecode (Useful Values).  Note that
 these values are for information only and can be overwritten when
 executing the UDVM bytecode without any effect on the endpoint.  The
 MSBs of each 2-byte word are stored preceding the LSBs.
 Addresses 0 to 5 indicate the resources available to the receiving
 endpoint.  The UDVM memory size is expressed in bytes modulo 2^16, so
 in particular, it is set to 0 if the UDVM memory size is 65536 bytes.
 The cycles_per_bit is expressed as a 2-byte integer taking the value
 16, 32, 64 or 128.  The SigComp_version is expressed as a 2-byte
 value as per Section 3.3.2.
 Addresses 6 to 9 are initialized to the length of the partial state
 identifier, followed by the state_length from the retrieved state
 item.  Both are expressed as 2-byte values.

Price, et. al. Standards Track [Page 26] RFC 3320 Signaling Compression (SigComp) January 2003

 Addresses 10 to 31 are reserved and are initialized to 0 for Version
 0x01 of SigComp.  Future versions of SigComp can use these locations
 for additional Useful Values, so a decompressor MUST NOT rely on
 these values being zero.
 Any remaining addresses in the UDVM memory that have not yet been
 initialized MUST be set to 0.
 The UDVM then begins executing instructions at the memory address
 contained in state_instruction (which is part of the retrieved item
 of state).  Note that the remaining SigComp message is held by the
 decompressor dispatcher until requested by the UDVM.
 (Note that the Useful Values are only set at UDVM startup; there is
 no special significance to this memory area afterwards.  This means
 that the UDVM bytecode is free to use these locations for any other
 purpose a memory location might be used for; it just has to be aware
 they are not necessarily initialized to zero.)

7.3. Uploading UDVM bytecode

 If the len field is set to 0 then the bytecode needed to decompress
 the SigComp message is supplied as part of the message itself.  The
 12-bit code_len field specifies the size of the uploaded UDVM
 bytecode (from 0 to 4095 bytes inclusive); eight most significant
 bits are in the first byte, followed by the four least significant
 bits in the most significant bits in the second byte.  The remaining
 bits in the second byte are interpreted as a 4-bit destination field
 that specifies the starting memory address to which the bytecode is
 copied.  The destination field is encoded as follows:
                   Encoding:   Destination address:
                   0000        reserved
                   0001        2  *  64  =  128
                   0010        3  *  64  =  196
                   0011        4  *  64  =  256
                     :                :
                   1111        16 *  64  =  1024
 Note that the encoding 0000 is reserved for future SigComp versions,
 and causes a decompression failure in Version 0x01.

Price, et. al. Standards Track [Page 27] RFC 3320 Signaling Compression (SigComp) January 2003

 The UDVM memory is initialized as per Figure 5, except that addresses
 6 to 9 inclusive are set to 0 because no state item has been
 accessed.  The UDVM then begins executing instructions at the memory
 address specified by the destination field.  As above, the remaining
 SigComp message is held by the decompressor dispatcher until needed
 by the UDVM.

8. Overview of the UDVM

 Decompression functionality for SigComp is provided by a Universal
 Decompressor Virtual Machine (UDVM).  The UDVM is a virtual machine
 much like the Java Virtual Machine but with a key difference:  it is
 designed solely for the purpose of running decompression algorithms.
 The motivation for creating the UDVM is to provide flexibility when
 choosing how to compress a given application message.  Rather than
 picking one of a small number of pre-negotiated algorithms, the
 compressor implementer has the freedom to select an algorithm of
 their choice.  The compressed data is then combined with a set of
 UDVM instructions that allow the original data to be extracted, and
 the result is outputted as a SigComp message.  Since the UDVM is
 optimized specifically for running decompression algorithms, the code
 size of a typical algorithm is small (often sub 100 bytes).
 Moreover, the UDVM approach does not add significant extra processing
 or memory requirements compared to running a fixed preprogrammed
 decompression algorithm.
 Figure 6 gives a detailed view of the interfaces between the UDVM and
 its environment.

Price, et. al. Standards Track [Page 28] RFC 3320 Signaling Compression (SigComp) January 2003

 +----------------+                                 +----------------+
 |                |     Request compressed data     |                |
 |                |-------------------------------->|                |
 |                |<--------------------------------|                |
 |                |     Provide compressed data     |                |
 |                |                                 |                |
 |                |    Output decompressed data     |  Decompressor  |
 |                |-------------------------------->|   dispatcher   |
 |                |                                 |                |
 |                |     Indicate end of message     |                |
 |                |-------------------------------->|                |
 |                |<--------------------------------|                |
 |      UDVM      | Provide compartment identifier  |                |
 |                |                                 +----------------+
 |                |
 |                |                                 +----------------+
 |                |    Request state information    |                |
 |                |-------------------------------->|                |
 |                |<--------------------------------|                |
 |                |    Provide state information    |     State      |
 |                |                                 |    handler     |
 |                |   Make state creation request   |                |
 |                |-------------------------------->|                |
 |                |  Forward feedback information   |                |
 +----------------+                                 +----------------+
       Figure 6: Interfaces between the UDVM and its environment
 Note that once the UDVM has been initialized, additional compressed
 data and state information are only provided at the request of a
 specific UDVM instruction.
 This chapter describes the basic features of the UDVM including the
 UDVM registers and the format of UDVM bytecode.

8.1. UDVM Registers

 The UDVM registers are 2-byte words in the UDVM memory that have
 special tasks, for example specifying the location of the stack used
 by the CALL and RETURN instructions.
 The UDVM registers are illustrated in Figure 7.

Price, et. al. Standards Track [Page 29] RFC 3320 Signaling Compression (SigComp) January 2003

                    0             7 8            15
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |        byte_copy_left         |  64 - 65
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |        byte_copy_right        |  66 - 67
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |        input_bit_order        |  68 - 69
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |        stack_location         |  70 - 71
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 7: Memory addresses of the UDVM registers
 The MSBs of each register are always stored before the LSBs.  So, for
 example, the MSBs of byte_copy_left are stored at Address 64 whilst
 the LSBs are stored at Address 65.
 The use of each UDVM register is defined in the following sections.
 (Note that the UDVM registers start at Address 64, that is 32 bytes
 after the area reserved for Useful Values.  The intention is that the
 gap, i.e., the area between Address 32 and Address 63, will often be
 used as scratch-pad memory that is guaranteed to be zero at UDVM
 startup and is efficiently addressable in operand types reference ($)
 and multitype (%).)

8.2. Requesting Additional Compressed Data

 The decompressor dispatcher stores the compressed data from the
 SigComp message before it is requested by the UDVM via one of the
 INPUT instructions.  When the UDVM bytecode is first executed, the
 dispatcher contains the remaining SigComp message after the header
 has been used to initialize the UDVM as per Chapter 7.
 Note that the INPUT-BITS and INPUT-HUFFMAN instructions retrieve a
 stream of individual compressed bits from the dispatcher.  To provide
 bitwise compatibility with various well-known compression algorithms,
 the input_bit_order register can modify the order in which individual
 bits are passed within a byte.
 The input_bit_order register contains the following three flags:
                    0             7 8            15
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |         reserved        |F|H|P|  68 - 69
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Price, et. al. Standards Track [Page 30] RFC 3320 Signaling Compression (SigComp) January 2003

 The P-bit controls the order in which bits are passed from the
 dispatcher to the INPUT instructions.  If set to 0, it indicates that
 the bits within an individual byte are passed to the INPUT
 instructions in MSB to LSB order.  If it is set to 1, the bits are
 passed in LSB to MSB order.
 Note that the input_bit_order register cannot change the order in
 which the bytes themselves are passed to the INPUT instructions
 (bytes are always passed in the same order as they occur in the
 SigComp message).
 The following diagram illustrates the order in which bits are passed
 to the INPUT instructions for both cases:
  MSB         LSB MSB         LSB     MSB         LSB MSB         LSB
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 1 2 3 4 5 6 7|8 9 ...        |   |7 6 5 4 3 2 1 0|        ... 9 8|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Byte 0           Byte 1              Byte 0          Byte 1
               P = 0                               P = 1
 Note that after one or more INPUT instructions the dispatcher may
 hold a fraction of a byte (what used to be the LSBs if P = 0, or, the
 MSBs, if P = 1).  If an INPUT instruction is encountered and the P-
 bit has changed since the last INPUT instruction, any fraction of a
 byte still held by the dispatcher MUST be discarded (even if the
 INPUT instruction requests zero bits).  The first bit passed to the
 INPUT instruction is taken from the subsequent byte.
 When an INPUT instruction requests n bits of compressed data, it
 interprets the received bits as an integer between 0 and 2^n - 1.
 The F-bit and the H-bit specify whether the bits in these integers
 are considered to arrive in MSB to LSB order (bit set to 0) or in LSB
 to MSB order (bit set to 1).
 If the F-bit is set to 0, the INPUT-BITS instruction interprets the
 received bits as arriving MSBs first, and if it is set to 1, it
 interprets the bits as arriving LSBs first.  The H-bit performs the
 same function for the INPUT-HUFFMAN instruction.  Note that it is
 possible to set these two bits to different values in order to use
 different bit orders for the two instructions (certain algorithms
 actually require this, e.g., DEFLATE [RFC-1951]).  (Note that there
 are no special considerations for changing the F- or H-bit between
 INPUT instructions, unlike the discard rule for the P-bit described
 above.)

Price, et. al. Standards Track [Page 31] RFC 3320 Signaling Compression (SigComp) January 2003

 Decompression failure occurs if an INPUT-BITS or an INPUT-HUFFMAN
 instruction is encountered and the input_bit_order register does not
 lie between 0 and 7 inclusive.

8.3. UDVM Stack

 Certain UDVM instructions make use of a stack of 2-byte words stored
 at the memory address specified by the 2-byte word stack_location.
 The stack contains the following words:
             Name:                 Starting memory address:
             stack_fill            stack_location
             stack[0]              stack_location + 2
             stack[1]              stack_location + 4
             stack[2]              stack_location + 6
                :                       :
 The notation stack_location is an abbreviation for the contents of
 the stack_location register, i.e., the 2-byte word at locations 70
 and 71.  The notation stack_fill is an abbreviation for the 2-byte
 word at stack_location and stack_location+1.  Similarly, the notation
 stack[n] is an abbreviation for the 2-byte word at
 stack_location+2*n+2 and stack_location+2*n+3.  (As always, the
 arithmetic is modulo 2^16.)
 The stack is used by the CALL, RETURN, PUSH and POP instructions.
 "Pushing" a value on the stack is an abbreviation for copying the
 value to stack[stack_fill] and then increasing stack_fill by 1.  CALL
 and PUSH push values on the stack.
 "Popping" a value from the stack is an abbreviation for decreasing
 stack_fill by 1, and then using the value stored in
 stack[stack_fill].  Decompression failure occurs if stack_fill is
 zero at the commencement of a popping operation.  POP and RETURN pop
 values from the stack.
 For both of these abstract operations, the UDVM first takes note of
 the current value of stack_location and uses this value for both
 sub-operations (accessing the stack and manipulating stack_fill),
 i.e., overwriting stack_location in the course of the operation is
 inconsequential for the operation.

Price, et. al. Standards Track [Page 32] RFC 3320 Signaling Compression (SigComp) January 2003

8.4. Byte copying

 A number of UDVM instructions require a string of bytes to be copied
 to and from areas of the UDVM memory.  This section defines how the
 byte copying operation should be performed.
 The string of bytes is copied in ascending order of memory address,
 respecting the bounds set by byte_copy_left and byte_copy_right.
 More precisely, if a byte is copied from/to Address m then the next
 byte is copied from/to Address n where n is calculated as follows:
 Set k := m + 1 (modulo 2^16)
 If k = byte_copy_right then set n := byte_copy_left, else set n := k
 Decompression failure occurs if a byte is copied from/to an address
 beyond the UDVM memory.
 Note that the string of bytes is copied one byte at a time.  In
 particular, some of the later bytes to be copied may themselves have
 been written into the UDVM memory by the byte copying operation
 currently being performed.
 Equally, it is possible for a byte copying operation to overwrite the
 instruction that invoked the byte copy.  If this occurs, then the
 byte copying operation MUST be completed as if the original
 instruction were still in place in the UDVM memory (this also applies
 if byte_copy_left or byte_copy_right are overwritten).
 Byte copying is used by the following UDVM instructions:
 SHA-1, COPY, COPY-LITERAL, COPY-OFFSET, MEMSET, INPUT-BYTES, STATE-
 ACCESS, OUTPUT, END-MESSAGE

8.5. Instruction operands and UDVM bytecode

 Each of the UDVM instructions in a piece of UDVM bytecode is
 represented by a single byte, followed by 0 or more bytes containing
 the operands required by the instruction.
 During instruction execution, conceptually the UDVM first fetches the
 first byte of the instruction, determines the number and types of
 operands required for this instruction, and then decodes all the
 operands in sequence before starting to act on the instruction.
 (Note that the UDVM instructions have been designed in such a way
 that this sequence remains conceptual in those cases where it would
 result in an unreasonable burden on the implementation.)

Price, et. al. Standards Track [Page 33] RFC 3320 Signaling Compression (SigComp) January 2003

 To reduce the size of typical UDVM bytecode, each operand for a UDVM
 instruction is compressed using variable-length encoding.  The aim is
 to store more common operand values using fewer bytes than rarely
 occurring values.
 Four different types of operand are available: the literal, the
 reference, the multitype and the address.  Chapter 9 gives a complete
 list of UDVM instructions and the operand types that follow each
 instruction.
 The UDVM bytecode for each operand type is illustrated in Figure 8 to
 Figure 10, together with the integer values represented by the
 bytecode.
 Note that the MSBs in the bytecode are illustrated as preceding the
 LSBs.  Also, any string of bits marked with k consecutive "n"s is to
 be interpreted as an integer N from 0 to 2^k - 1 inclusive (with the
 MSBs of n illustrated as preceding the LSBs).
 The decoded integer value of the bytecode can be interpreted in two
 ways.  In some cases it is taken to be the actual value of the
 operand.  In other cases it is taken to be a memory address at which
 the 2-byte operand value can be found (MSBs found at the specified
 address, LSBs found at the following address).  The latter cases are
 denoted by memory[X] where X is the address and memory[X] is the 2-
 byte value starting at Address X.
 The simplest operand type is the literal (#), which encodes a
 constant integer from 0 to 65535 inclusive.  A literal operand may
 require between 1 and 3 bytes depending on its value.
 Bytecode:                       Operand value:      Range:
 0nnnnnnn                        N                   0 - 127
 10nnnnnn nnnnnnnn               N                   0 - 16383
 11000000 nnnnnnnn nnnnnnnn      N                   0 - 65535
             Figure 8: Bytecode for a literal (#) operand
 The second operand type is the reference ($), which is always used to
 access a 2-byte value located elsewhere in the UDVM memory.  The
 bytecode for a reference operand is decoded to be a constant integer
 from 0 to 65535 inclusive, which is interpreted as the memory address
 containing the actual value of the operand.

Price, et. al. Standards Track [Page 34] RFC 3320 Signaling Compression (SigComp) January 2003

 Bytecode:                       Operand value:      Range:
 0nnnnnnn                        memory[2 * N]       0 - 65535
 10nnnnnn nnnnnnnn               memory[2 * N]       0 - 65535
 11000000 nnnnnnnn nnnnnnnn      memory[N]           0 - 65535
            Figure 9: Bytecode for a reference ($) operand
 Note that the range of a reference operand is always 0 - 65535
 independently of how many bits are used to encode the reference,
 because the operand always references a 2-byte value in the memory.
 The third kind of operand is the multitype (%), which can be used to
 encode both actual values and memory addresses.  The multitype
 operand also offers efficient encoding for small integer values (both
 positive and negative) and for powers of 2.
 Bytecode:                       Operand value:      Range:
 00nnnnnn                        N                   0 - 63
 01nnnnnn                        memory[2 * N]       0 - 65535
 1000011n                        2 ^ (N + 6)        64 , 128
 10001nnn                        2 ^ (N + 8)    256 , ... , 32768
 111nnnnn                        N + 65504       65504 - 65535
 1001nnnn nnnnnnnn               N + 61440       61440 - 65535
 101nnnnn nnnnnnnn               N                   0 - 8191
 110nnnnn nnnnnnnn               memory[N]           0 - 65535
 10000000 nnnnnnnn nnnnnnnn      N                   0 - 65535
 10000001 nnnnnnnn nnnnnnnn      memory[N]           0 - 65535
            Figure 10: Bytecode for a multitype (%) operand
 The fourth operand type is the address (@).  This operand is decoded
 as a multitype operand followed by a further step: the memory address
 of the UDVM instruction containing the address operand is added to
 obtain the correct operand value.  So if the operand value from
 Figure 10 is D then the actual operand value of an address is
 calculated as follows:
 operand_value = (memory_address_of_instruction + D) modulo 2^16
 Address operands are always used in instructions that control program
 flow, because they ensure that the UDVM bytecode is position-
 independent code (i.e., it will run independently of where it is
 placed in the UDVM memory).

Price, et. al. Standards Track [Page 35] RFC 3320 Signaling Compression (SigComp) January 2003

8.6. UDVM Cycles

 Once the UDVM has been invoked it executes the instructions contained
 in its memory consecutively unless otherwise indicated (for example
 when the UDVM encounters a JUMP instruction).  If the next
 instruction to be executed lies outside the available memory then
 decompression failure occurs (see Section 8.7).
 To ensure that a SigComp message cannot consume excessive processing
 resources, SigComp limits the number of "UDVM cycles" allocated to
 each message.  The number of available UDVM cycles is initialized to
 1000 plus the number of bits in the SigComp header (as described in
 Section 7); this sum is then multiplied by cycles_per_bit.  Each time
 an instruction is executed the number of available UDVM cycles is
 decreased by the amount specified in Chapter 9.  Additionally, if the
 UDVM successfully requests n bits of compressed data using one of the
 INPUT instructions then the number of available UDVM cycles is
 increased by n * cycles_per_bit once the instruction has been
 executed.
 This means that the maximum number of UDVM cycles available for
 processing an n-byte SigComp message is given by the formula:
         maximum_UDVM_cycles = (8 * n + 1000) * cycles_per_bit
 The reason that this total is not allocated to the UDVM when it is
 invoked is that the UDVM can begin to decompress a message that has
 only been partially received.  So the total message size may not be
 known when the UDVM is initialized.
 Note that the number of UDVM cycles MUST NOT be increased if a
 request for additional compressed data fails.
 The UDVM stops executing instructions when it encounters an END-
 MESSAGE instruction or if decompression failure occurs (see Section
 8.7 for further details).

8.7. Decompression Failure

 If a compressed message given to the UDVM is corrupted (either
 accidentally or maliciously), then the UDVM may terminate with a
 decompression failure.

Price, et. al. Standards Track [Page 36] RFC 3320 Signaling Compression (SigComp) January 2003

 Reasons for decompression failure include the following:
 1. A SigComp message contains an invalid header as per Chapter 7.
 2. A SigComp message is larger than the decompression_memory_size.
 3. An instruction costs more than the number of remaining UDVM
    cycles.
 4. The UDVM attempts to read from or write to a memory address beyond
    its memory size.
 5. An unknown instruction is encountered.
 6. An unknown operand is encountered.
 7. An instruction is encountered that cannot be processed
    successfully by the UDVM (for example a RETURN instruction when no
    CALL instruction has previously been encountered).
 8. A request to access some state information fails.
 9. A manual decompression failure is triggered using the
    DECOMPRESSION-FAILURE instruction.
 If a decompression failure occurs when decompressing a message then
 the UDVM informs the dispatcher and takes no further action.  It is
 the responsibility of the dispatcher to decide how to cope with the
 decompression failure.  In general a dispatcher SHOULD discard the
 compressed message (or the compressed stream if the transport is
 stream-based) and any decompressed data that has been outputted but
 not yet passed to the application.

9. UDVM Instruction Set

 The UDVM currently understands 36 instructions, chosen to support the
 widest possible range of compression algorithms with the minimum
 possible overhead.
 Figure 11 lists the different instructions and the bytecode values
 used to encode the instructions.  The cost of each instruction in
 UDVM cycles is also given:

Price, et. al. Standards Track [Page 37] RFC 3320 Signaling Compression (SigComp) January 2003

 Instruction:       Bytecode value:   Cost in UDVM cycles:
 DECOMPRESSION-FAILURE     0          1
 AND                       1          1
 OR                        2          1
 NOT                       3          1
 LSHIFT                    4          1
 RSHIFT                    5          1
 ADD                       6          1
 SUBTRACT                  7          1
 MULTIPLY                  8          1
 DIVIDE                    9          1
 REMAINDER                 10         1
 SORT-ASCENDING            11         1 + k * (ceiling(log2(k)) + n)
 SORT-DESCENDING           12         1 + k * (ceiling(log2(k)) + n)
 SHA-1                     13         1 + length
 LOAD                      14         1
 MULTILOAD                 15         1 + n
 PUSH                      16         1
 POP                       17         1
 COPY                      18         1 + length
 COPY-LITERAL              19         1 + length
 COPY-OFFSET               20         1 + length
 MEMSET                    21         1 + length
 JUMP                      22         1
 COMPARE                   23         1
 CALL                      24         1
 RETURN                    25         1
 SWITCH                    26         1 + n
 CRC                       27         1 + length
 INPUT-BYTES               28         1 + length
 INPUT-BITS                29         1
 INPUT-HUFFMAN             30         1 + n
 STATE-ACCESS              31         1 + state_length
 STATE-CREATE              32         1 + state_length
 STATE-FREE                33         1
 OUTPUT                    34         1 + output_length
 END-MESSAGE               35         1 + state_length
    Figure 11: UDVM instructions and corresponding bytecode values
 Each UDVM instruction costs a minimum of 1 UDVM cycle.  Certain
 instructions may cost additional cycles depending on the values of
 the instruction operands.  Named variables in the cost expressions
 refer to the values of the instruction operands with these names.
 Note that for the SORT instructions, the formula ceiling(log2(k))
 calculates the smallest value i such that k <= 2^i.

Price, et. al. Standards Track [Page 38] RFC 3320 Signaling Compression (SigComp) January 2003

 The UDVM instruction set offers a mix of low-level and high-level
 instructions.  The high-level instructions can all be emulated using
 combinations of low-level instructions, but given a choice it is
 generally preferable to use a single instruction rather than a large
 number of general-purpose instructions.  The resulting bytecode will
 be more compact (leading to a higher overall compression ratio) and
 decompression will typically be faster because the implementation of
 the high-level instructions can be more easily optimized.
 All instructions are encoded as a single byte to indicate the
 instruction type, followed by 0 or more bytes containing the operands
 required by the instruction.  The instruction specifies which of the
 four operand types of Section 8.5 is used in each case. For example
 the ADD instruction is followed by two operands:
 ADD ($operand_1, %operand_2)
 When converted into bytecode the number of bytes required by the ADD
 instruction depends on the value of each operand, and whether the
 multitype operand contains the operand value itself or a memory
 address where the actual value of the operand can be found.
 Each instruction is explained in more detail below.
 Whenever the description of an instruction uses the expression "and
 then", the intended semantics is that the effect explained before
 "and then" is completed before work on the effect explained after the
 "and then" is commenced.

9.1. Mathematical Instructions

 The following instructions provide a number of mathematical
 operations including bit manipulation, arithmetic and sorting.

9.1.1. Bit Manipulation

 The AND, OR, NOT, LSHIFT and RSHIFT instructions provide simple bit
 manipulation on 2-byte words.
 AND ($operand_1, %operand_2)
 OR ($operand_1, %operand_2)
 NOT ($operand_1)
 LSHIFT ($operand_1, %operand_2)
 RSHIFT ($operand_1, %operand_2)

Price, et. al. Standards Track [Page 39] RFC 3320 Signaling Compression (SigComp) January 2003

 After the operation is complete, the value of the first operand is
 overwritten with the result.  (Note that since this operand is a
 reference, it is the 2-byte word at the memory address specified by
 the operand that is overwritten.)
 The precise definitions of LSHIFT and RSHIFT are given below.  Note
 that m and n are the 2-byte values encoded by the operands, and that
 floor(x) calculates the largest integer not greater than x:
 LSHIFT (m, n) := m * 2^n (modulo 2^16)
 RSHIFT (m, n) := floor(m / 2^n)

9.1.2. Arithmetic

 The ADD, SUBTRACT, MULTIPLY, DIVIDE and REMAINDER instructions
 perform arithmetic on 2-byte words.
 ADD ($operand_1, %operand_2)
 SUBTRACT ($operand_1, %operand_2)
 MULTIPLY ($operand_1, %operand_2)
 DIVIDE ($operand_1, %operand_2)
 REMAINDER ($operand_1, %operand_2)
 After the operation is complete, the value of the first operand is
 overwritten with the result.
 The precise definition of each instruction is given below:
 ADD (m, n)       := m + n (modulo 2^16)
 SUBTRACT (m, n)  := m - n (modulo 2^16)
 MULTIPLY (m, n)  := m * n (modulo 2^16)
 DIVIDE (m, n)    := floor(m / n)
 REMAINDER (m, n) := m - n * floor(m / n)
 Decompression failure occurs if a DIVIDE or REMAINDER instruction
 encounters an operand_2 that is zero.

9.1.3. Sorting

 The SORT-ASCENDING and SORT-DESCENDING instructions sort lists of 2-
 byte words.
 SORT-ASCENDING (%start, %n, %k)
 SORT-DESCENDING (%start, %n, %k)
 The start operand specifies the starting memory address of the block
 of data to be sorted.

Price, et. al. Standards Track [Page 40] RFC 3320 Signaling Compression (SigComp) January 2003

 The block of data itself is divided into n lists each containing k
 2-byte words.  The SORT-ASCENDING instruction applies a certain
 permutation to the lists, such that the first list is sorted into
 ascending order (treating each 2-byte word as an unsigned integer).
 The same permutation is applied to all n lists, so lists other than
 the first will not necessarily be sorted into order.
 In the case that two words have the same value, the original ordering
 of the list is preserved.
 For example, the first list might contain a set of integers to be
 sorted whilst the second list might be used to keep track of where
 the integers appear in the sorted list:
          Before sorting              After sorting
       List 1        List 2        List 1        List 2
          8             1             1             2
          1             2             1             3
          1             3             3             4
          3             4             8             1
 The SORT-DESCENDING instruction behaves as above, except that the
 first list is sorted into descending order.

9.1.4. SHA-1

 The SHA-1 instruction calculates a 20-byte SHA-1 hash [RFC-3174] over
 the specified area of UDVM memory.
 SHA-1 (%position, %length, %destination)
 The position and length operands specify the starting memory address
 and the length of the byte string over which the SHA-1 hash is
 calculated.  Byte copying rules are enforced as per Section 8.4.
 The destination operand gives the starting address to which the
 resulting 20-byte hash will be copied.  Byte copying rules are
 enforced as above.

9.2. Memory Management Instructions

 The following instructions are used to set up the UDVM memory, and to
 copy byte strings from one memory location to another.

Price, et. al. Standards Track [Page 41] RFC 3320 Signaling Compression (SigComp) January 2003

9.2.1. LOAD

 The LOAD instruction sets a 2-byte word to a certain specified value.
 The format of a LOAD instruction is as follows:
 LOAD (%address, %value)
 The first operand specifies the starting address of a 2-byte word,
 whilst the second operand specifies the value to be loaded into this
 word.  As usual, MSBs are stored before LSBs in the UDVM memory.

9.2.2. MULTILOAD

 The MULTILOAD instruction sets a contiguous block of 2-byte words in
 the UDVM memory to specified values.
 MULTILOAD (%address, #n, %value_0, ..., %value_n-1)
 The first operand specifies the starting address of the contiguous
 2-byte words, whilst the operands value_0 through to value_n-1
 specify the values to load into these words (in the same order as
 they appear in the instruction).
 Decompression failure occurs if the set of 2-byte words set by the
 instruction would overlap the memory locations held by the
 instruction (including its operands) itself, i.e., if the instruction
 would be self-modifying.  (This restriction makes it simpler to
 implement MULTILOAD step-by-step instead of having to decode all
 operands before being able to copy data, as is implied by the
 conceptual model of instruction execution.)

9.2.3. PUSH and POP

 The PUSH and POP instructions read from and write to the UDVM stack
 (as defined in Section 8.3).
 PUSH (%value)
 POP (%address)
 The PUSH instruction pushes the value specified by its operand on the
 stack.
 The POP instruction pops a value from the stack and then copies the
 value to the specified memory address.  (Note that the expression
 "and then" implies that the copying of the value is inconsequential
 for the stack operation itself, which happens beforehand.)
 See Section 8.3 for possible error conditions.

Price, et. al. Standards Track [Page 42] RFC 3320 Signaling Compression (SigComp) January 2003

9.2.4. COPY

 The COPY instruction is used to copy a string of bytes from one part
 of the UDVM memory to another.
 COPY (%position, %length, %destination)
 The position operand specifies the memory address of the first byte
 in the string to be copied, and the length operand specifies the
 number of bytes to be copied.
 The destination operand gives the address to which the first byte in
 the string will be copied.
 Byte copying is performed as per the rules of Section 8.4.

9.2.5. COPY-LITERAL

 A modified version of the COPY instruction is given below:
 COPY-LITERAL (%position, %length, $destination)
 The COPY-LITERAL instruction behaves as a COPY instruction except
 that after copying is completed, the value of the destination operand
 is replaced by the address to which the next byte of data would be
 copied.  More precisely it is replaced by the value n, derived as per
 Section 8.4 with m set to the destination address of the last byte to
 be copied, if any (i.e., if the value of the length operand is zero,
 the value of the destination operand is not changed).

9.2.6. COPY-OFFSET

 A further version of the COPY-LITERAL instruction is given below:
 COPY-OFFSET (%offset, %length, $destination)
 The COPY-OFFSET instruction behaves as a COPY-LITERAL instruction
 except that an offset operand is given instead of a position operand.
 To derive the value of the position operand, starting at the memory
 address specified by destination, the UDVM counts backwards a total
 of offset memory addresses.
 If the memory address specified in byte_copy_left is reached, the
 next memory address is taken to be (byte_copy_right - 1) modulo 2^16.

Price, et. al. Standards Track [Page 43] RFC 3320 Signaling Compression (SigComp) January 2003

 The COPY-OFFSET instruction then behaves as a COPY-LITERAL
 instruction, taking the value of the position operand to be the last
 memory address reached in the above step.

9.2.7. MEMSET

 The MEMSET instruction initializes an area of UDVM memory to a
 specified sequence of values. The format of a MEMSET instruction is
 as follows:
 MEMSET (%address, %length, %start_value, %offset)
 The sequence of values used by the MEMSET instruction is specified by
 the following formula:
 Seq[n] := (start_value + n * offset) modulo 256
 The values Seq[0] to Seq[length - 1] inclusive are each interpreted
 as a single byte, and then concatenated to form a byte string where
 the first byte has value Seq[0], the second byte has value Seq[1] and
 so on up to the last byte which has value Seq[length - 1].
 The string is then byte copied into the UDVM memory beginning at the
 memory address specified as an operand to the MEMSET instruction,
 obeying the rules of Section 8.4.  (Note that the byte string may
 overwrite the MEMSET instruction or its operands; as explained in
 Section 8.5, the MEMSET instruction must be executed as if the
 original operands were still in place in the UDVM memory.)

9.3. Program Flow Instructions

 The following instructions alter the flow of UDVM code.  Each
 instruction jumps to one of a number of memory addresses based on a
 certain specified criterion.
 Note that certain I/O instructions (see Section 9.4) can also alter
 program flow.

9.3.1. JUMP

 The JUMP instruction moves program execution to the specified memory
 address.
 JUMP (@address)
 Decompression failure occurs if the value of the address operand lies
 beyond the overall UDVM memory size.

Price, et. al. Standards Track [Page 44] RFC 3320 Signaling Compression (SigComp) January 2003

9.3.2. COMPARE

 The COMPARE instruction compares two operands and then jumps to one
 of three specified memory addresses depending on the result.
 COMPARE (%value_1, %value_2, @address_1, @address_2, @address_3)
 If value_1 < value_2 then the UDVM continues instruction execution at
 the memory address specified by address 1. If value_1 = value_2 then
 it jumps to the address specified by address_2. If value_1 > value_2
 then it jumps to the address specified by address_3.

9.3.3. CALL and RETURN

 The CALL and RETURN instructions provide support for compression
 algorithms with a nested structure.
 CALL (@address)
 RETURN
 Both instructions use the UDVM stack of Section 8.3.  When the UDVM
 reaches a CALL instruction, it finds the memory address of the
 instruction immediately following the CALL instruction and pushes
 this 2-byte value on the stack, ready for later retrieval.  It then
 continues instruction execution at the memory address specified by
 the address operand.
 When the UDVM reaches a RETURN instruction it pops a value from the
 stack and then continues instruction execution at the memory address
 just popped.
 See Section 8.3 for error conditions.

9.3.4. SWITCH

 The SWITCH instruction performs a conditional jump based on the value
 of one of its operands.
 SWITCH (#n, %j, @address_0, @address_1, ... , @address_n-1)
 When a SWITCH instruction is encountered the UDVM reads the value of
 j. It then continues instruction execution at the address specified
 by address j.
 Decompression failure occurs if j specifies a value of n or more, or
 if the address lies beyond the overall UDVM memory size.

Price, et. al. Standards Track [Page 45] RFC 3320 Signaling Compression (SigComp) January 2003

9.3.5. CRC

 The CRC instruction verifies a string of bytes using a 2-byte CRC.
 CRC (%value, %position, %length, @address)
 The actual CRC calculation is performed using the generator
 polynomial x^16 + x^12 + x^5 + 1, which coincides with the 2-byte
 Frame Check Sequence (FCS) of PPP [RFC-1662].
 The position and length operands define the string of bytes over
 which the CRC is evaluated.  Byte copying rules are enforced as per
 Section 8.4.
 The CRC value is computed exactly as defined for the 16-bit FCS
 calculation in [RFC-1662].
 The value operand contains the expected integer value of the 2-byte
 CRC.  If the calculated CRC matches the expected value then the UDVM
 continues instruction execution at the following instruction.
 Otherwise the UDVM jumps to the memory address specified by the
 address operand.

9.4. I/O instructions

 The following instructions allow the UDVM to interface with its
 environment.  Note that in the overall SigComp architecture all of
 these interfaces pass to the decompressor dispatcher or to the state
 handler.

9.4.1. DECOMPRESSION-FAILURE

 The DECOMPRESSION-FAILURE instruction triggers a manual decompression
 failure.  This is useful if the UDVM bytecode discovers that it
 cannot successfully decompress the message (e.g., by using the CRC
 instruction).
 This instruction has no operands.

9.4.2. INPUT-BYTES

 The INPUT-BYTES instruction requests a certain number of bytes of
 compressed data from the decompressor dispatcher.
 INPUT-BYTES (%length, %destination, @address)

Price, et. al. Standards Track [Page 46] RFC 3320 Signaling Compression (SigComp) January 2003

 The length operand indicates the requested number of bytes of
 compressed data, and the destination operand specifies the starting
 memory address to which they should be copied.  Byte copying is
 performed as per the rules of Section 8.4.
 If the instruction requests data that lies beyond the end of the
 SigComp message, no data is returned.  Instead the UDVM moves program
 execution to the address specified by the address operand.
 If the INPUT-BYTES is encountered after an INPUT-BITS or an INPUT-
 HUFFMAN instruction has been used, and the dispatcher currently holds
 a fraction of a byte, then the fraction MUST be discarded before any
 data is passed to the UDVM.  The first byte to be passed is the byte
 immediately following the discarded data.

9.4.3. INPUT-BITS

 The INPUT-BITS instruction requests a certain number of bits of
 compressed data from the decompressor dispatcher.
 INPUT-BITS (%length, %destination, @address)
 The length operand indicates the requested number of bits.
 Decompression failure occurs if this operand does not lie between 0
 and 16 inclusive.
 The destination operand specifies the memory address to which the
 compressed data should be copied.  Note that the requested bits are
 interpreted as a 2-byte integer ranging from 0 to 2^length - 1, as
 explained in Section 8.2.
 If the instruction requests data that lies beyond the end of the
 SigComp message, no data is returned.  Instead the UDVM moves program
 execution to the address specified by the address operand.

9.4.4. INPUT-HUFFMAN

 The INPUT-HUFFMAN instruction requests a variable number of bits of
 compressed data from the decompressor dispatcher.  The instruction
 initially requests a small number of bits and compares the result
 against a certain criterion; if the criterion is not met, then
 additional bits are requested until the criterion is achieved.
 The INPUT-HUFFMAN instruction is followed by three mandatory operands
 plus n additional sets of operands.  Every additional set contains
 four operands as shown below:

Price, et. al. Standards Track [Page 47] RFC 3320 Signaling Compression (SigComp) January 2003

 INPUT-HUFFMAN (%destination, @address, #n, %bits_1, %lower_bound_1,
 %upper_bound_1, %uncompressed_1, ... , %bits_n, %lower_bound_n,
 %upper_bound_n, %uncompressed_n)
 Note that if n = 0 then the INPUT-HUFFMAN instruction is ignored and
 program execution resumes at the following instruction.
 Decompression failure occurs if (bits_1 + ... + bits_n) > 16.
 In all other cases, the behavior of the INPUT-HUFFMAN instruction is
 defined below:
 1. Set j := 1 and set H := 0.
 2. Request bits_j compressed bits.  Interpret the returned bits as an
    integer k from 0 to 2^bits_j - 1, as explained in Section 8.2.
 3. Set H := H * 2^bits_j + k.
 4. If data is requested that lies beyond the end of the SigComp
    message, terminate the INPUT-HUFFMAN instruction and move program
    execution to the memory address specified by the address operand.
 5. If (H < lower_bound_j) or (H > upper_bound_j) then set j := j + 1.
    Then go back to Step 2, unless j > n in which case decompression
    failure occurs.
 6. Copy (H + uncompressed_j - lower_bound_j) modulo 2^16 to the
    memory address specified by the destination operand.

9.4.5. STATE-ACCESS

 The STATE-ACCESS instruction retrieves some previously stored state
 information.
 STATE-ACCESS (%partial_identifier_start, %partial_identifier_length,
 %state_begin, %state_length, %state_address, %state_instruction)
 The partial_identifier_start and partial_identifier_length operands
 specify the location of the partial state identifier used to retrieve
 the state information.  This identifier has the same function as the
 partial state identifier transmitted in the SigComp message as per
 Section 7.2.
 Decompression failure occurs if partial_identifier_length does not
 lie between 6 and 20 inclusive.  Decompression failure also occurs if
 no state item matching the partial state identifier can be found, if

Price, et. al. Standards Track [Page 48] RFC 3320 Signaling Compression (SigComp) January 2003

 more than one state item matches the partial identifier, or if
 partial_identifier_length is less than the minimum_access_length of
 the matched state item. Otherwise, a state item is returned from the
 state handler.
 If any of the operands state_address, state_instruction or
 state_length is set to 0 then its value is taken from the returned
 item of state instead.
 Note that when calculating the number of UDVM cycles the STATE-ACCESS
 instruction costs (1 + state_length) cycles.  The value of
 state_length MUST be taken from the returned item of state in the
 case that the state_length operand is set to 0.
 The state_begin and state_length operands define the starting byte
 and number of bytes to copy from the state_value contained in the
 returned item of state.  Decompression failure occurs if bytes are
 copied from beyond the end of the state_value.  Note that
 decompression failure will always occur if the state_length operand
 is set to 0 but the state_begin operand is non-zero.
 The state_address operand contains a UDVM memory address.  The
 requested portion of the state_value is byte copied to this memory
 address using the rules of Section 8.4.
 Program execution then resumes at the memory address specified by
 state_instruction, unless this address is 0 in which case program
 execution resumes at the next instruction following the STATE-ACCESS
 instruction.  Note that the latter case only occurs if both the
 state_instruction operand and the state_instruction value from the
 requested state are set to 0.

9.4.6. STATE-CREATE

 The STATE-CREATE instruction requests the creation of a state item at
 the receiving endpoint.
 STATE-CREATE (%state_length, %state_address, %state_instruction,
 %minimum_access_length, %state_retention_priority)
 Note that the new state item cannot be created until a valid
 compartment identifier has been returned by the application.
 Consequently, when a STATE-CREATE instruction is encountered the UDVM
 simply buffers the five supplied operands until the END-MESSAGE
 instruction is reached.  The steps taken at this point are described
 in Section 9.4.9.

Price, et. al. Standards Track [Page 49] RFC 3320 Signaling Compression (SigComp) January 2003

 Decompression failure MUST occur if more than four state creation
 requests are made before the END-MESSAGE instruction is encountered.
 Decompression failure also occurs if the minimum_access_length does
 not lie between 6 and 20 inclusive, or if the
 state_retention_priority is 65535.

9.4.7. STATE-FREE

 The STATE-FREE instruction informs the receiving endpoint that the
 sender no longer wishes to use a particular state item.
 STATE-FREE (%partial_identifier_start, %partial_identifier_length)
 Note that the STATE-FREE instruction does not automatically delete a
 state item, but instead reclaims the memory taken by the state item
 within a certain compartment, which is generally not known before the
 END-MESSAGE instruction is reached.  So just as for the STATE-CREATE
 instruction, when a STATE-FREE instruction is encountered the UDVM
 simply buffers the two supplied operands until the END-MESSAGE
 instruction is reached.  The steps taken at this point are described
 in Section 9.4.9.
 Decompression failure MUST occur if more than four state free
 requests are made before the END-MESSAGE instruction is encountered.
 Decompression failure also occurs if partial_identifier_length does
 not lie between 6 and 20 inclusive.

9.4.8. OUTPUT

 The OUTPUT instruction provides successfully decompressed data to the
 dispatcher.
 OUTPUT (%output_start, %output_length)
 The operands define the starting memory address and length of the
 byte string to be provided to the dispatcher.  Note that the OUTPUT
 instruction can be used to output a partially decompressed message;
 each time the instruction is encountered it provides a new byte
 string that the dispatcher appends to the end of any bytes previously
 passed to the dispatcher via the OUTPUT instruction.
 The string of data is byte copied from the UDVM memory obeying the
 rules of Section 8.4.
 Decompression failure occurs if the cumulative number of bytes
 provided to the dispatcher exceeds 65536 bytes.

Price, et. al. Standards Track [Page 50] RFC 3320 Signaling Compression (SigComp) January 2003

 Since there is technically a difference between outputting a 0-byte
 decompressed message, and not outputting a decompressed message at
 all, the OUTPUT instruction needs to distinguish between the two
 cases.  Thus, if the UDVM terminates before encountering an OUTPUT
 instruction it is considered not to have outputted a decompressed
 message.  If it encounters one or more OUTPUT instructions, each of
 which provides 0 bytes of data to the dispatcher, then it is
 considered to have outputted a 0-byte decompressed message.

9.4.9. END-MESSAGE

 The END-MESSAGE instruction successfully terminates the UDVM and
 forwards the state creation and state free requests to the state
 handler together with any supplied feedback data.
 END-MESSAGE (%requested_feedback_location,
 %returned_parameters_location, %state_length, %state_address,
 %state_instruction, %minimum_access_length,
 %state_retention_priority)
 When the END-MESSAGE instruction is encountered, the decompressor
 dispatcher indicates to the application that a complete message has
 been decompressed.  The application may return a compartment
 identifier, which the UDVM forwards to the state handler together
 with the state creation and state free requests and any supplied
 feedback data.
 The actual decompressed message is outputted separately using the
 OUTPUT instruction; this conserves memory at the UDVM because there
 is no need to buffer an entire decompressed message before it can be
 passed to the dispatcher.
 The END-MESSAGE instruction may pass up to four state creation
 requests and up to four state free requests to the state handler.
 The requests are passed to the state handler in the same order as
 they are made; in particular it is possible for the state creation
 requests and the state free requests to be interleaved.
 The state creation requests are made by the STATE-CREATE instruction.
 Note however that the END-MESSAGE can make one state creation request
 itself using the supplied operands. If the specified
 minimum_access_length does not lie between 6 and 20 inclusive, or if
 the state_retention_priority is 65535 then the END-MESSAGE
 instruction fails to make a state creation request of its own
 (however decompression failure does not occur and the state creation
 requests made by the STATE-CREATE instruction are still valid).

Price, et. al. Standards Track [Page 51] RFC 3320 Signaling Compression (SigComp) January 2003

 Note that there is a maximum limit of four state creation requests
 per instance of the UDVM.  Therefore, decompression failure occurs if
 the END-MESSAGE instruction makes a state creation request and four
 instances of the STATE-CREATE instruction have already been
 encountered.
 When creating a state item it is necessary to give the state_length,
 state address, state_instruction and minimum_access_length; these are
 supplied as operands in the STATE-CREATE instruction (or the END-
 MESSAGE instruction).  A complete item of state also requires a
 state_value and a state_identifier, which are derived as follows:
 The UDVM byte copies a string of state_length bytes from the UDVM
 memory beginning at state_address (obeying the rules of Section 8.4).
 This is the state_value.
 The UDVM then calculates a 20-byte SHA-1 hash [RFC-3174] over the
 byte string formed by concatenating the state_length, state_address,
 state_instruction, minimum_access_length and state_value (in the
 order given).  This is the state_identifier.
 The state_retention_priority is not part of the state item itself,
 but instead determines the order in which state will be deleted when
 the compartment exceeds its allocated state memory.  The
 state_retention_priority is supplied as an operand in the STATE-
 CREATE or END-MESSAGE instruction and is passed to the state handler
 as part of each state creation request.
 The state free requests are made by the STATE-FREE instruction. Each
 STATE-FREE instruction supplies the values partial_identifier_start
 and partial_identifier_length; upon reaching the END-MESSAGE
 instruction these values are used to byte copy a partial state
 identifier from the UDVM memory.  If no state item matching the
 partial state identifier can be found or if more than one state item
 in the compartment matches the partial state identifier, then the
 state free request is ignored (this does not cause decompression
 failure to occur).  Otherwise, the state handler frees the matched
 state item as specified in Section 6.2.
 As well as forwarding the state creation and state free requests, the
 END-MESSAGE instruction may also pass feedback data to the state
 handler.  Feedback data is used to inform the receiving endpoint
 about the capabilities of the sending endpoint, which can help to
 improve the overall compression ratio and to reduce the working
 memory requirements of the endpoints.

Price, et. al. Standards Track [Page 52] RFC 3320 Signaling Compression (SigComp) January 2003

 Two types of feedback data are available: requested feedback and
 returned feedback.  The format of the requested feedback data is
 given in Figure 12.  As outlined in Section 3.2, the requested
 feedback data can be used to influence the contents of the returned
 feedback data in the reverse direction.
 The returned feedback data is itself subdivided into a returned
 feedback item and a list of returned SigComp parameters.  The
 returned feedback item is of sufficient importance to warrant its own
 field in the SigComp header as described in Section 7.1.  The
 returned SigComp parameters are illustrated in Figure 13.
 Note that the formats of Figure 12 and Figure 13 are only for local
 presentation of the feedback data on the interface between the UDVM
 and state handler.  The formats do not mandate any bits on the wire;
 the compressor can transmit the data in any form provided that it is
 loaded into the UDVM memory at the correct addresses.
 Moreover, the responsibility for ensuring that feedback data arrives
 successfully over an unreliable transport lies with the sender.  The
 receiving endpoint always uses the last received value for each field
 in the feedback data, even if the values are out of date due to
 packet loss or misordering.
 If the requested_feedback_location operand is set to 0, then no
 feedback request is made; otherwise, it points to the starting memory
 address of the requested feedback data as shown in Figure 12.
      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    |     reserved      | Q | S | I |  requested_feedback_location
    +---+---+---+---+---+---+---+---+
    |                               |
    :    requested feedback item    :  if Q = 1
    |                               |
    +---+---+---+---+---+---+---+---+
             Figure 12: Format of requested feedback data
 The reserved bits may be used in future versions of SigComp, and are
 set to 0 in Version 0x01.  Non-zero values should be ignored by the
 receiving endpoint.
 The Q-bit indicates whether a requested feedback item is present or
 not.  The compressor can set the requested feedback item to an
 arbitrary value, which will then be transmitted unmodified in the
 reverse direction as a returned feedback item.  See Chapter 5 for
 further details of how the requested feedback item is returned.

Price, et. al. Standards Track [Page 53] RFC 3320 Signaling Compression (SigComp) January 2003

 The format of the requested feedback item is identical to the format
 of the returned feedback item illustrated in Figure 4.
 The compressor sets the S-bit to 1 if it does not wish (or no longer
 wishes) to save state information at the receiving endpoint and also
 does not wish to access state information that it has previously
 saved.  Consequently, if the S-bit is set to 1 then the receiving
 endpoint can reclaim the state memory allocated to the remote
 compressor and set the state_memory_size for the compartment to 0.
 The compressor may change its mind and switch the S-bit back to 0 in
 a later message.  However, the receiving endpoint is under no
 obligation to use the original state_memory_size for the compartment;
 it may choose to allocate less memory to the compartment or possibly
 none at all.
 Similarly the compressor sets the I-bit to 1 if it does not wish (or
 no longer wishes) to access any of the locally available state items
 offered by the receiving endpoint.  This can help to conserve
 bandwidth because the list of locally available state items no longer
 needs to be returned in the reverse direction.  It may also conserve
 memory at the receiving endpoint, as the state handler can delete any
 locally available state items that it determines are no longer
 required by any remote endpoint.  Note that the compressor can set
 the I-bit back to 0 in a later message, but it cannot access any
 locally available state items that were previously offered by the
 receiving endpoint unless they are subsequently re-announced.
 If the returned_parameters_location operand is set to 0, then no
 SigComp parameters are returned; otherwise, it points to the starting
 memory address of the returned parameters as shown in Figure 13.

Price, et. al. Standards Track [Page 54] RFC 3320 Signaling Compression (SigComp) January 2003

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    |  cpb  |    dms    |    sms    |  returned_parameters_location
    +---+---+---+---+---+---+---+---+
    |        SigComp_version        |
    +---+---+---+---+---+---+---+---+
    | length_of_partial_state_ID_1  |
    +---+---+---+---+---+---+---+---+
    |                               |
    :  partial_state_identifier_1   :
    |                               |
    +---+---+---+---+---+---+---+---+
            :               :
    +---+---+---+---+---+---+---+---+
    | length_of_partial_state_ID_n  |
    +---+---+---+---+---+---+---+---+
    |                               |
    :  partial_state_identifier_n   :
    |                               |
    +---+---+---+---+---+---+---+---+
           Figure 13: Format of returned SigComp parameters
 The first byte encodes the SigComp parameters cycles_per_bit,
 decompression_memory_size and state_memory_size as per Section 3.3.1.
 The byte can be set to 0 if the three parameters are not included in
 the feedback data.  (This may be useful to save bits in the
 compressed message if the remote endpoint is already satisfied all
 necessary information has reached the endpoint receiving the
 message.)
 The second byte encodes the SigComp_version as per Section 3.3.2.
 Similar to the first byte, the second byte can be set to 0 if the
 parameter is not included in the feedback data.
 The remaining bytes encode a list of partial state identifiers for
 the locally available state items offered by the sending endpoint.
 Each state item is encoded as a 1-byte length field, followed by a
 partial state identifier containing as many bytes as indicated in the
 length field.  The sender can choose to send as few as 6 bytes if it
 believes that this is sufficient for the receiver to determine which
 state item is being offered.
 The list of state identifiers is terminated by a byte in the position
 where the next length field would be expected that is set to a value
 below 6 or above 20.  Note that upgraded SigComp versions may append
 additional items of data after the final length field.

Price, et. al. Standards Track [Page 55] RFC 3320 Signaling Compression (SigComp) January 2003

10. Security Considerations

10.1. Security Goals

 The overall security goal of the SigComp architecture is to not
 create risks that are in addition to those already present in the
 application protocols.  There is no intention for SigComp to enhance
 the security of the application, as it always can be circumvented by
 not using compression.  More specifically, the high-level security
 goals can be described as:
 1. Do not worsen security of existing application protocol
 2. Do not create any new security issues
 3. Do not hinder deployment of application security.

10.2. Security Risks and Mitigation

 This section identifies the potential security risks associated with
 SigComp, and explains how each risk is minimized by the scheme.

10.2.1. Confidentiality Risks

  1. Attacking SigComp by snooping into state of other users:
 State is accessed by supplying a state identifier, which is a
 cryptographic hash of the state being referenced.  This implies that
 the referencing message already needs knowledge about the state.  To
 enforce this, a state item cannot be accessed without supplying a
 minimum of 48 bits from the hash.  This also minimizes the
 probability of an accidental state collision.  A compressor can,
 using the minimum_access_length operand of the STATE-CREATE and END-
 MESSAGE instructions, increase the number of bits that need to be
 supplied to access the state, increasing the protection against
 attacks.
 Generally, ways to obtain knowledge about the state identifier (e.g.,
 passive attacks) will also easily provide knowledge about the
 referenced state, so no new vulnerability results.
 An endpoint needs to handle state identifiers with the same care it
 would handle the state itself.

Price, et. al. Standards Track [Page 56] RFC 3320 Signaling Compression (SigComp) January 2003

10.2.2. Integrity Risks

 The SigComp approach assumes that there is appropriate integrity
 protection below and/or above the SigComp layer.  The state creation
 mechanism provides some additional potential to compromise the
 integrity of the messages; however, this would most likely be
 detectable at the application layer.
  1. Attacking SigComp by faking state or making unauthorized changes to

state:

 State cannot be destroyed by a malicious sender unless it can send
 messages that the application identifies as belonging to the same
 compartment the state was created under; this adds additional
 security risks only when the application allows the installation of
 SigComp state from a message where it would not have installed state
 itself.
 Faking or changing state is only possible if the hash allows
 intentional collision.

10.2.3. Availability Risks (Avoiding DoS Vulnerabilities)

  1. Use of SigComp as a tool in a DoS attack to another target:
 SigComp cannot easily be used as an amplifier in a reflection attack,
 as it only generates one decompressed message per incoming compressed
 message.  This message is then handed to the application; the utility
 as a reflection amplifier is therefore limited by the utility of the
 application for this purpose.
 However, it must be noted that SigComp can be used to generate larger
 messages as input to the application than have to be sent from the
 malicious sender; this therefore can send smaller messages (at a
 lower bandwidth) than are delivered to the application.  Depending on
 the reflection characteristics of the application, this can be
 considered a mild form of amplification.  The application MUST limit
 the number of packets reflected to a potential target - even if
 SigComp is used to generate a large amount of information from a
 small incoming attack packet.

Price, et. al. Standards Track [Page 57] RFC 3320 Signaling Compression (SigComp) January 2003

  1. Attacking SigComp as the DoS target by filling it with state:
 Excessive state can only be installed by a malicious sender (or a set
 of malicious senders) with the consent of the application.  The
 system consisting of SigComp and application is thus approximately as
 vulnerable as the application itself, unless it allows the
 installation of SigComp state from a message where it would not have
 installed application state itself.
 If this is desirable to increase the compression ratio, the effect
 can be mitigated by making use of feedback at the application level
 that indicates whether the state requested was actually installed -
 this allows a system under attack to gracefully degrade by no longer
 installing compressor state that is not matched by application state.
 Obviously, if a stream-based transport is used, the streams
 themselves constitute state that has to be handled in the same way
 that the application itself would handle a stream-based transport; if
 an application is not equipped for stream-based transport, it should
 not allow SigComp connections on a stream-based transport.  For the
 alternative SigComp usage described as "continuous mode" in Section
 4.2.1, an attacker could create any number of active UDVMs unless
 there is some DoS protection at a lower level (e.g., by using TLS in
 appropriate configurations).
  1. Attacking the UDVM by faking state or making unauthorized changes

to state:

 This is covered in Section 10.2.2.
  1. Attacking the UDVM by sending it looping code:
 The application sets an upper limit to the number of "UDVM cycles"
 that can be used per compressed message and per input bit in the
 compressed message.  The damage inflicted by sending packets with
 looping code is therefore limited, although this may still be
 substantial if a large number of UDVM cycles are offered by the UDVM.
 However, this would be true for any decompressor that can receive
 packets over an unsecured transport.

11. IANA Considerations

 SigComp requires a 1-byte name space, the SigComp_version, which has
 been created by the IANA.  Upgraded versions of SigComp must be
 backwards-compatible with Version 0x01, described in this document.
 Adding additional UDVM instructions and assigning values to the
 reserved UDVM memory addresses are two possible upgrades for which
 this is the case.

Price, et. al. Standards Track [Page 58] RFC 3320 Signaling Compression (SigComp) January 2003

 Following the policies outlined in [RFC-2434], the IANA policy for
 assigning a new value for the SigComp_version shall require a
 Standards Action.  Values are thus assigned only for Standards Track
 RFCs approved by the IESG.

12. Acknowledgements

 Thanks to
    Abigail Surtees
    Mark A West
    Lawrence Conroy
    Christian Schmidt
    Max Riegel
    Lars-Erik Jonsson
    Stefan Forsgren
    Krister Svanbro
    Miguel Garcia
    Christopher Clanton
    Khiem Le
    Ka Cheong Leung
    Robert Sugar
 for valuable input and review.

13. References

13.1. Normative References

 [RFC-1662]  Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC
             1662, July 1994.
 [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC-3174]  Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm
             1 (SHA1)", RFC 3174, September 2001.

13.2. Informative References

 [RFC-1951]  Deutsch, P., "DEFLATE Compressed Data Format
             Specification version 1.3", RFC 1951, May 1996.
 [RFC-2026]  Bradner, S., "The Internet Standards Process - Revision
             3", BCP 9, RFC 2026, October 1996.
 [RFC-2279]  Yergeau, F., "UTF-8, a transformation format of ISO
             10646", RFC 2279, January 1998.

Price, et. al. Standards Track [Page 59] RFC 3320 Signaling Compression (SigComp) January 2003

 [RFC-2326]  Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time
             Streaming Protocol (RTSP)", RFC 2326, April 1998.
 [RFC-2434]  Alvestrand, H. and T. Narten, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.
 [RFC-2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
             Schwartzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
             Zhang, L. and V. Paxson, "Stream Control Transmission
             Protocol", RFC 2960, October 2000.
 [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-3321]  Hannu, H., Christoffersson, J., Forsgren, S., Leung,
             K.-C., Liu, Z. and R. Price, "Signaling Compression
             (SigComp) - Extended Operations", RFC 3321, January
             2003.

14. Authors' Addresses

 Richard Price
 Roke Manor Research Ltd
 Romsey, Hants, SO51 0ZN
 United Kingdom
 Phone: +44 1794 833681
 EMail: richard.price@roke.co.uk
 Carsten Bormann
 Universitaet Bremen TZI
 Postfach 330440
 D-28334 Bremen, Germany
 Phone: +49 421 218 7024
 EMail: cabo@tzi.org

Price, et. al. Standards Track [Page 60] RFC 3320 Signaling Compression (SigComp) January 2003

 Jan Christoffersson
 Box 920
 Ericsson AB
 SE-971 28 Lulea, Sweden
 Phone: +46 920 20 28 40
 EMail: jan.christoffersson@epl.ericsson.se
 Hans Hannu
 Box 920
 Ericsson AB
 SE-971 28 Lulea, Sweden
 Phone: +46 920 20 21 84
 EMail: hans.hannu@epl.ericsson.se
 Zhigang Liu
 Nokia Research Center
 6000 Connection Drive
 Irving, TX 75039
 Phone: +1 972 894-5935
 EMail: zhigang.c.liu@nokia.com
 Jonathan Rosenberg
 dynamicsoft
 72 Eagle Rock Avenue
 First Floor
 East Hanover, NJ 07936
 EMail: jdrosen@dynamicsoft.com

Price, et. al. Standards Track [Page 61] RFC 3320 Signaling Compression (SigComp) January 2003

15. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Price, et. al. Standards Track [Page 62]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3320.txt · Last modified: 2003/01/03 20:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki