WDIFF

draft-ietf-rohc-sigcomp-05.txt --> draft-ietf-rohc-sigcomp-06.txt

Network Working Group Richard Price, Siemens/Roke Manor
INTERNET-DRAFT Hans Hannu, Ericsson
Expires: September November 2002 Carsten Bormann, TZI/Uni Bremen
Jan Christoffersson, Ericsson
Zhigang Liu, Nokia
Jonathan Rosenberg, dynamicsoft

March 1,

May 6, 2002

Signaling Compression (SigComp)
<draft-ietf-rohc-sigcomp-05.txt>
<draft-ietf-rohc-sigcomp-06.txt>

Status of this memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@ietf.org.

Abstract

This document defines SigComp, a solution for compressing messages
generated by application protocols such as [SIP] SIP [RFC-2543] and [RTSP]. RTSP
[RFC-2326]. The architecture and pre-requisites of SigComp are
outlined, along with the format of the SigComp message.

Decompression functionality for the SigComp solution is provided by a "Universal
Decompressor Virtual Machine" 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]. DEFLATE [RFC-1951].

Price, Hannu, et al. [Page 1]

INTERNET-DRAFT SigComp March 1, 2002 Signaling Compression 2002-05-06

Table of contents

1. Introduction..................................................2
2. Terminology...................................................3
3. SigComp Architecture..........................................6 architecture..........................................5
4. SigComp message flow..........................................11 dispatchers...........................................13
5. SigComp compressor............................................14 compressor............................................16
6. State handling and announcement...............................16 SigComp state handler.........................................18
7. SigComp message format........................................21
8. Overview of the UDVM..........................................20
8. Decompressing a SigComp message...............................23 UDVM..........................................25
9. UDVM instruction set..........................................26 set..........................................34
10. Security considerations.......................................38 considerations.......................................51
11. IANA considerations...........................................40 considerations...........................................54
12. Acknowledgements..............................................41 Acknowledgements..............................................54
13. AuthorsÆ addresses............................................41 Authors' addresses............................................55
14. References....................................................42
Appendix A. Document history......................................43 References....................................................56

1. Introduction

The Session Initiation Protocol [SIP], along with many other

Many application protocols used for multimedia communications such as
[RTSP], is a textual protocol are
text-based and engineered for bandwidth rich links. As a result, SIP result the
messages have not been optimized in terms of size.
Typical For example,
typical SIP messages range from a few hundred bytes up to as high as two
thousand. To date, this has not been a significant problem.
thousand bytes or more.

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

This document outlines the architecture and pre-requisites of the
SigComp solution, the format of the SigComp message, algorithm
upload, message and the Universal
Decompressor Virtual Machine (UDVM) that provides decompression
functionality.

SigComp is offered to applications as a "shim" layer between the application
and the an underlying transport. The service provided is that of the
underlying transport plus compression. Both connection-oriented and
connectionless transports are supported by SigComp.

This document focuses on the signaling scenario where an end-terminal
communicates with a proxy. However SigComp may be applicable to other
scenarios with multiple endpoints compressing supports a wide range
of transports including TCP, UDP and decompressing data. SCTP [RFC-2960].

Price, Hannu, et al. [Page 2]

INTERNET-DRAFT SigComp March 1, 2002 Signaling Compression 2002-05-06

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119].

Application

Entity that invokes SigComp

The overall solution for signaling compression, comprising the
compressor, decompressor, dispatchers and state handler.

Application

For performs the purpose of this document, an application is a text-based
protocol software that:

a) sends following tasks:

1. Supplying application data messages to the compressor dispatcher
b) receives data
2. Receiving decompressed messages from the decompressor
dispatcher
c) authenticates
3. Determining the sender of 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 gives
permission for keeps track of state to that can be saved in used
for compression. The compressor is responsible for ensuring that
the sender's name

Application message

An uncompressed message provided to or from messages it generates can be decompressed by the application.

Endpoint

One instance of an remote UDVM.

Compressor dispatcher

Entity that receives application plus messages, invokes a compressor,
and forwards the resulting SigComp layer. Each endpoint 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 capable 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.

Endpoint

One instance of an application, a SigComp layer, and a transport

Price, Hannu, et al. [Page 3]

INTERNET-DRAFT Signaling Compression 2002-05-06

layer for sending and/or receiving SigComp messages.

Endpoint identity

Message-based transport

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

Compartment

An application-specific grouping of messages that relate to each endpoint by a peer
endpoint. Depending on the signaling protocol, this grouping may
relate to application
(for example an URI). concepts such as "session", "dialog",
"connection", or "association". The application authenticates 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 sender compressor, UDVM,
dispatchers and state handler.

SigComp message

A message sent from the compressor dispatcher to the decompressor
dispatcher. In case of a decompressed message, and provides their endpoint identity message-based transport such as UDP, a
SigComp message corresponds to exactly one datagram. For a stream-
based transport such as TCP, the SigComp state handler. 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].

Message-based transport

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

Stream-based transport

A transport that carries data as a continuous stream with no
message boundaries. SCTP [RFC-2960].

Universal Decompressor Virtual Machine (UDVM)

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

Price, Hannu, et al. [Page 3] 4]

INTERNET-DRAFT SigComp March 1, 2002

Application-defined parameters

Parameters that must be agreed upon by the local and remote
endpoints invoking SigComp. Values Signaling Compression 2002-05-06

State

Data saved for the application-defined
parameters are typically fixed to meet the requirements of a
particular signaling application.

SigComp message

May contain a compressed application message in the form of UDVM
bytecode. In case of a message-based transport such as UDP, a
SigComp message corresponds to exactly one (UDP) datagram. For a
stream-based transport such as TCP, each SigComp message is
separated retrieval by a reserved delimiter.

Standalone SigComp message

A SigComp message that does not include any compressed application
data. Certain signaling applications may not allow standalone later SigComp messages due to security requirements.

Compressor messages.

State handler

Entity that invokes an encoder, and keeps track of states that can
be used for compression. It is responsible for supplying UDVM
bytecode to the remote decompressor in order for compressed
data to be decompressed.

Encoder

Encodes data according to a particular compression algorithm.

Compressor dispatcher

Entity that receives uncompressed application messages, invokes a
compressor, accessing and forwards storing state information
once permission is granted by the resulting SigComp messages application.

State identifier

Reference used to access a remote
endpoint.

Decompressor

Entity that is responsible for converting a previously created item of state.

3. SigComp message into
uncompressed data. Decompression functionality is provided by architecture

In the
UDVM.

Decompressor dispatcher

Entity that receives SigComp messages, invokes a decompressor, and
forwards the decompressed application messages to an application.

Price, Hannu, et al. [Page 4]

INTERNET-DRAFT SigComp March 1, 2002

Virtual machine

A machine architecture designed to be implemented in software
(although silicon implementations are of course possible).

Universal Decompressor Virtual Machine (UDVM)

The virtual machine described in this document. The UDVM is used
for decompression of SigComp messages.

Bytecode

Machine code that can be executed by a virtual machine. UDVM
bytecode is a combination of UDVM instructions and compressed data.

Per-message compression

Compression that does not reference data from previous messages.
SigComp can decompress a message of this type using only the
application-defined parameters and the data in the message itself.

Dynamic compression

Compression relative to messages sent prior to the current
compressed message. SigComp stores and retrieves this data using
the state handler.

State

Data saved for retrieval by later SigComp messages. An item of
state typically reflects the contents of the UDVM memory after
decompressing a message, but state can also be created by the
compressor or by the application.

State handler

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

State identifier

Reference used to access an item of state previously created by the
compressor, the decompressor or the application.

CPU cycles

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

Price, Hannu, et al. [Page 5]

INTERNET-DRAFT SigComp March 1, 2002

3. SigComp Architecture

In the SigComp architecture compression architecture, compression and decompression is
performed at two communicating entities. SigComp is offered to
applications as endpoints. The layout of a "shim" layer between the application and the
underlying transport, and so these entities are endpoints when viewed
from a transport layer perspective. Note however that from the
application perspective SigComp is applied on a per-hop basis.

Figure 1 shows the layout of a communicating single
endpoint that implements
a SigComp layer. The figure does not mandate any particular
implementation, but is shown to the reader for the sake of clarity.

The SigComp layer is further decomposed illustrated in the following components:

- A compressor dispatcher: this is the interface from the
application. The compressor dispatcher receives an Figure 1:

+-------------------------------------------------------------------+
| |
| Local application |
| |
+-------------------------------------------------------------------+
| ^ |
Application message and an & | Decompressed | | Compartment
compartment identifier for the receiving endpoint. Based on the
endpoint identity the compressor dispatcher invokes a particular
compressor, which returns a SigComp message that is forwarded to
the remote SigComp endpoint.

- A decompressor dispatcher: this is the interface towards the
application. A SigComp | message is received by the decompressor | | identifier
| | |
+-- -- -- -- -- -- -- --|-- -- -- -- -- -- -- --|--|-- -- -- -- -- -+
v | v
| +------------------------+ +----------------------+ |
| | | |
| +--| Compressor | | Decompressor |<-+ |
| | dispatcher and an instance a decompressor is invoked. Once the | | dispatcher has received the (decompressed) application data it
forwards the message to the application.

- One or more compressors: a distinct compressor is invoked for each
remote endpoint with which the local application wishes to
communicate. A compressor receives an (uncompressed) application
message from the compressor dispatcher, compresses the
message, and returns a SigComp message to the compressor
dispatcher. During the compression process the compressor may
invoke the state handler to restore previous state or save new
state. Each compressor chooses a certain algorithm to encode the
data, (e.g. [DEFLATE]).

- One or more decompressors: since SigComp can run over an unsecure
transport layer, a distinct decompressor must be invoked on a
per-message basis. A decompressor receives a SigComp message from
the decompressor dispatcher, decompresses the message, and returns
the (decompressed) application message to the decompressor
dispatcher. During the decompression process, the decompressor may
invoke the state handler to restore previous state or save new
state.

- State handler: this entity contains enough logic to store and
retrieve states. State is information that is stored between
SigComp messages: this data can be saved either by a compressor, a
decompressor or an application. For security purposes the state

Price, Hannu, et al. [Page 6]

INTERNET-DRAFT SigComp March 1, 2002

handler must always ask the application to grant permission for new
states to be saved. State creation and retrieval are further
described in Chapter 6.

+---------------------------------------------+
| | | Application |
| | | |
+---------------------------------------------+ | | ^
Message & | Endpoint | | Decompressed
endpoint
| identity +------------------------+ +----------------------+ |
| message
identity | ^ ^ ^ | |
| | |
+-- -- -- -- --|-- -- -- -- -- -- --|-- -- -- |- -- -- -- -- + | |
| | | v v | | +--------------+ +--------------+ +--------------+ |
SigComp |
| | +--------------+ +---------------+ | |
| SigComp
message | Compressor | | State | | Decompressor +-------+ | message
<-------| dispatcher v | | handler
| | dispatcher |<------- | Compressor 1 |<----->|State 1| | +--------------+ |
| | | | |
+--------------+ +--------------+ +--------------+ | ^ ^ ^ ^ ^ ^ ^ ^ +-------+ | | | | |
| | +--------------+ | | | Decompressor | |
| | | | State handler |<-->| | | |
| | +--------------+ | | | (UDVM) | |

Price, Hannu, et al. [Page 5]

INTERNET-DRAFT Signaling Compression 2002-05-06

| | v | | | | +-------+ | v | |
+--------------+ | |
| +->| Compressor 2 |<----->|State 2| | +--------------+ |
| Compressor 1 | | | | | |Decompressor 1| | +-------+ | |<----+ | | +---->|
| +--------------+ +---------------+ SigComp layer |
| (Encoder) | | | | (UDVM) | |
| | | | | |
| +--------------+ | | +--------------+ |
| | | |
| v | | v |
+--------------+ | | +--------------+
| | Compressor 2 | | | |Decompressor 2| |
| |<-------+ +------->| |
| | (Encoder) | | (UDVM) | |
| | | |
| +--------------+ +--------------+ |

| SigComp layer |
+--
+-| -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- --|-+
| |
| SigComp SigComp |
| message message |
v |
+-------------------------------------------------------------------+
| |
| Transport layer |
| |
+-------------------------------------------------------------------+

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

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

Price, Hannu, et al. [Page 6]

INTERNET-DRAFT Signaling Compression 2002-05-06

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.

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 that does not occur in UTF-8
encoded text messages [RFC-2279], so for applications which use this
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

Price, Hannu, et al. [Page 7]

INTERNET-DRAFT Signaling Compression 2002-05-06

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

+---------------------+ +---------------------+
| +-----------------+ | | +-----------------+ |
-->| Compressor |------------------------>| UDVM |<->
| | sending to B | | SigComp message | | | |2
| +-----------------+ | requesting feedback | +-----------------+ |
| ^ 1,9 | | 3 | |

Price, Hannu, et al. [Page 8]

INTERNET-DRAFT Signaling Compression 2002-05-06

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

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.

Price, Hannu, et al. [Page 9]

INTERNET-DRAFT Signaling Compression 2002-05-06

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.

3.3.1. Memory size and UDVM cycles

The decompression_memory_size parameter specifies the amount of
memory available to decompress one SigComp message. 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.

Price, Hannu, et al. [Page 10]

INTERNET-DRAFT Signaling Compression 2002-05-06

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:

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

Price, Hannu, et al. [Page 11]

INTERNET-DRAFT Signaling Compression 2002-05-06

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.

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

Price, Hannu, et al. [Page 12]

INTERNET-DRAFT Signaling Compression 2002-05-06

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

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.

Price, Hannu, et al. [Page 13]

INTERNET-DRAFT Signaling Compression 2002-05-06

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.

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, this alternative 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

Price, Hannu, et al. [Page 7] 14]

INTERNET-DRAFT Signaling Compression 2002-05-06

application before the SigComp March 1, 2002

Note that it message is possible for SigComp terminated, e.g., by
keeping the UDVM active while expecting the application to decompress messages from
multiple endpoints at different physical locations
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 network, as stream-based transport, the architecture is designed to prevent dispatcher delimits messages by
parsing the compressed data from stream for instances of 0xFF and taking
the following actions:

Occurs in data stream: Action:

0xFF 00 one endpoint
interfering 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 from a different endpoint. A consequence of
this design choice is accompanying the decompressed message can be
trusted sufficiently that it is difficult for a malicious user to
disrupt can be used when sending SigComp operation by inserting false compressed

Price, Hannu, et al. [Page 15]

INTERNET-DRAFT Signaling Compression 2002-05-06

messages on that relate to the transport layer.

Each decompressor in compressor's equivalent for the architecture of Figure 1
compartment.

The dispatcher passes the compartment identifier to the UDVM, where
it is an instance of used as per the Universal Decompressor Virtual Machine (UDVM). Figure 2 gives END-MESSAGE instruction (see Section 9.4.9).

The application uses a
more detailed view of suitable authentication mechanism to determine
whether the decompressed message belongs to a UDVM, including all of legitimate compartment
or not. If the interfaces between application fails to authenticate the UDVM and its environment.

+----------------+ +----------------+
| | Request compressed data | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide compressed data | |
| | | Dispatcher |
| | | |
| | Output decompressed data | |
| |-------------------------------->| |
| | | |
| | +----------------+
| UDVM |
| | +----------------+
| | Request state information | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide state information | |
| | | State |
| | | Handler |
| | Make message with
sufficient confidence to allow state creation request | |
| |-------------------------------->| |
| | Forward announcement | |
| | | |
+----------------+ +----------------+

Figure 2: Interfaces between to be saved or feedback data to
be trusted, it supplies a "no valid compartment" error to the UDVM
dispatcher and its environment

Note the UDVM is terminated without creating any state or
forwarding any feedback data.

5. SigComp compressor

An important feature of SigComp is that decompression functionality
is provided by a Universal Decompressor Virtual Machine (UDVM). This
means that for simplicity, the UDVM indicates when it requires
additional compressor can choose any algorithm to generate
compressed data or state information using an explicit
instruction. It then pauses SigComp messages, and waits then upload bytecode for the information
corresponding decompression algorithm to be
supplied before continuing with the next instruction. This prevents the arrival UDVM as part of more data from interfering the
SigComp message.

To help with the operation implementation and testing of a SigComp endpoint,
further Internet Drafts and RFCs may be published to describe
particular compression algorithms.

The overall requirement placed on the
UDVM (e.g. by accidentally overwriting UDVM memory that compressor is currently
in use).

Price, Hannu, et al. [Page 8]

INTERNET-DRAFT that of
transparency, i.e. the compressor MUST NOT send bytecode which causes
the UDVM to incorrectly decompress a given SigComp March 1, 2002

3.1. Requirements message.

The following more specific requirements are also placed on application

From an application perspective the SigComp layer appears as a new
transport, with similar behavior to
compressor (they can be considered particular instances of the original transport used
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
carry uncompressed data (for example SigComp/UDP behaves similarly ensure that successful
decompression has occurred. A UDVM instruction is provided for CRC
verification; also, another instruction can be used to
native UDP). 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 wishes message to mix SigComp messages with other types of
data (e.g. uncompressed data, or exactly one SigComp data for a different
application) on message.

Price, Hannu, et al. [Page 16]

INTERNET-DRAFT Signaling Compression 2002-05-06

4. If the same 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 must
distinguish between
so that accidental or malicious damage to one SigComp message does
not affect the different types decompression of data. This means that a
new port will need subsequent messages.

Additionally, if the state handler passes some requested feedback to
the compressor then it SHOULD be reserved or discovered for returned in the next SigComp
messages destined for a particular application. For example SIP uses
port 5060 for TCP and port 5061 for TLS/TCP, so it could similarly
reserve another port for SigComp/TCP.

In message
generated by the interests of security, a new interface is required to compressor (unless the
signaling application state handler passes some
newer requested feedback before the older feedback has been sent, in order to leverage
which case the authentication
functions built older feedback is deleted).

If present, the requested feedback item SHOULD be copied unmodified
into the application itself. When returned_feedback_item field provided in the application
receives a decompressed message it determines SigComp
message. Note that there is no need to transmit any requested
feedback item more than once.

The compressor SHOULD also upload the identity of local SigComp parameters to the
remote endpoint, unless the
sending endpoint and supplies this information has indicated that it does not
wish to the state handler.

3.2. Application-defined receive these parameters

When an application invokes SigComp, a number 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
provided by the application
uploaded to control the maximum size of compressed
messages, the UDVM memory size etc. The local and at the remote applications
that wish to communicate endpoint as described in
Section 9.4.9.

5.1. Ensuring successful decompression

A compressor MUST initially agree on a common set of
values for these parameters.

Note be certain that the majority all of application-defined parameters are set the data needed to
fixed values for
decompress a particular signaling application. However,
endpoints implementing SigComp will typically have a wide range of
capabilities; each offering a different amount of working memory,
processing power and so on. In order message is available at the receiving endpoint.
One way to support ensure this wide variation is to send all of the needed information in endpoint capabilities,
every SigComp includes a mechanism message (including bytecode to decompress the message).
However the compression ratio for modifying this method will be relatively low.

To obtain the following application-defined parameters on best overall compression ratio the fly:

UDVM_version
UDVM_memory_size
cycles_per_bit
cycles_per_message
Initial compressor must
request the creation of new state items at the remote endpoint. The SigComp announcement mechanism is described further
information saved in Section
6.3.

The advantage of building the announcement mechanism into these state items can then be accessed by later
SigComp is
that it avoids messages, avoiding the need for any form of negotiation to be performed
by upload the application itself. Instead, 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 sufficient to initialize guaranteed. For an unreliable transport
however, the compressor must provide a suitable mechanism itself (see
[EXTENDED] for further details).

Price, Hannu, et al. [Page 9] 17]

INTERNET-DRAFT SigComp March 1, 2002

all of Signaling Compression 2002-05-06

The compressor must also ensure that the application-defined parameters state item it wishes to fixed values and modify
them later using SigComp itself.

Each application-defined parameter is described below.

Note that unless otherwise indicated, all
access has not been rejected due to a lack of the parameters state memory. This can
be
stored as 2-byte integers.

UDVM_version

The UDVM_version parameter specifies accomplished by checking the level of functionality
available at state_memory_size parameter using the UDVM.
SigComp feedback mechanism (see Section 9.4.9 for further details).

5.2. Compression failure

The basic version of the UDVM (Version 0)
is defined compressor SHOULD make every effort to successfully compress an
application message, but in certain cases this document.

maximum_expansion_size

The maximum_expansion_size parameter prevents might not be possible
(particularly if resources are scarce at the generation of
excessively large SigComp messages. receiving endpoint). In
this case a "compression failure" is called.

If set to 0 a compression failure occurs then the parameter
is ignored by SigComp; for any other value then if an uncompressed
message is k bytes long, compressor informs the corresponding SigComp message must be
dispatcher and takes no larger than (k + maximum_expansion_size). Note that any value
other than 0 bans the creation of standalone SigComp messages (i.e.
messages that do not contain a compressed application message).

maximum_compressed_size further action. The maximum_compressed_size parameter limits the size of one
compressed message. SigComp rejects any message larger than dispatcher MUST report
this failure to the
specified value.

maximum_uncompressed_size

The maximum_uncompressed_size parameter limits application so that it can try other methods to
deliver the size of one
uncompressed message. SigComp rejects any message larger than the
specified value.

minimum_hash_size

The minimum_hash_size parameter specifies

6. State handling and feedback

This chapter defines the minimum size behavior of the SigComp state identifier when creating new handler. The
function of the state information. This value
needs to be sufficiently large handler is to prevent malicious users 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
guessing
a security perspective.

6.1. Creating and accessing state identifier by brute force.

UDVM_memory_size

The UDVM_memory_size parameter specifies

To provide security against the total number malicious insertion or modification
of SigComp messages, a separate instance of
bytes in the UDVM memory.

cycles_per_bit

The cycles_per_bit parameter specifies is invoked to
decompress each message. This ensures that damaged SigComp messages
do not prevent the number successful decompression of "CPU cycles"

Price, Hannu, et al. [Page 10]

INTERNET-DRAFT SigComp March 1, 2002 subsequent valid
messages.

Note however that the overall compression ratio is often
significantly higher if messages can be used compressed relative to decompress a single bit of data. One CPU cycle
typically corresponds the
information contained in previous messages. For this reason it is
possible to create state items for access when a single UDVM instruction, although some
of the high-level instructions may require additional cycles.

cycles_per_message

The cycles_per_message parameter specifies later message is
being decompressed. Both the number creation and access of additional
CPU cycles made available at state are
designed to be secure against malicious tampering with the start of a compressed message.
These cycles
data. The UDVM can be useful when decompressing algorithms that
upload additional data on only create a per-message basis, for example state item when a new
set of Huffman codes as with [DEFLATE].

The total maximum number of "CPU cycles" available for each
compressed complete message is specified by
has been successfully decompressed and the following formula:

maximum_cycles = message_size * cycles_per_bit + cycles_per_message

maximum_state_size

The maximum_state_size parameter specifies application has returned a
compartment identifier under which the maximum amount of state information that can be saved saved.

State access cannot be protected by a local endpoint, for each
remote endpoint with which it communicates. Note that relying on the amount application alone,
since the authentication mechanism may require information from the
decompressed message (which of course is not available until after
the state information has been accessed). Instead, SigComp protects state access

Price, Hannu, et al. [Page 18]

INTERNET-DRAFT Signaling Compression 2002-05-06

by creating a state identifier that is expressed as a multiple of hash over the parameter
UDVM_memory_size, because item of state
to be retrieved. This state_identifier must be supplied to retrieve
an item of state generally
reflects from the contents of 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 memory.

Initial (see Chapter 7); additional
state items can be retrieved using the STATE-ACCESS instruction. The application
UDVM can store useful information in also request the form creation of state.
This predefined state is used to offer a range of well-known
decompression algorithms to new state item by using the compressor, which
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 choose store state up to
avoid uploading bytecode 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 new algorithm if it supports one list of the well-known algorithms. Each item state items created by a particular
compartment and ensures that no compartment exceeds its allocated
state_memory_size. For the purpose of initial calculation each state can be made
mandatory for every item is
considered to cost (state_length + 64) bytes.

Each instance of the application, or it UDVM can be made
optional (in which case support for pass up to four state creation requests
to the relevant state will need handler, as well as up to
be advertised before four state free requests (the
latter are requests to free the memory taken by a state can be used).

4. SigComp message flow

This chapter describes item in a
certain compartment). When the SigComp message flow and state handler receives a state
creation request from the operation of UDVM it takes the compressor and decompressor dispatcher.

4.1. Message exchange following steps:

1. The local SigComp layer may send compressed data to state handler MUST reject all state creation requests that are
not accompanied by a remote SigComp
layer, and valid compartment identifier, or if the local SigComp layer may also receive compressed data.
compartment is allocated 0 bytes of state memory. Note however that compression in one direction if a
state creation request fails due to lack of state memory then it
does not necessarily
imply compression in the reverse direction. Furthermore, even in the
case mean that there are two unidirectional compressed flows between two

Price, Hannu, et al. [Page 11]

INTERNET-DRAFT SigComp March 1, 2002 the corresponding SigComp layers, there message is no need to use damaged;
compressors will often make state creation requests in the same compression
algorithm at both compressors.

4.2. first
SigComp message format

In every of a compartment, before they have discovered the
state_memory_size using the SigComp message 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 few (state_memory_size - 64) bytes are interpreted from the

Price, Hannu, et al. [Page 19]

INTERNET-DRAFT Signaling Compression 2002-05-06

state_value. It sets the state_length to (state_memory_size - 64),
and recalculates the state_identifier as a defined in Section 9.4.9.

3. If the state identifier creation request contains a state_identifier that accesses some previously stored state
information.

This
already exists then the state information includes all of handler checks whether the data needed requested
state item is identical to decompress the SigComp message: including established state item and counts
the decompression algorithm 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
be applied occur is vanishingly small).

4. If the state creation request exceeds the state memory allocated
to the remainder compartment, sufficient items of state created by the message, as well as any additional
information that same
compartmennt are freed until enough memory is required (e.g. one or more previously received
messages if dynamic compression available to
accommodate the new state. When a state item is in use).

The format freed it is
removed from the list of states created by the compartment and the
memory cost of the basic SigComp message 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 given in Figure 4:

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | length |
+---+---+---+---+---+---+---+---+
| |
: state_identifier (n-bytes) :
| |
+---+---+---+---+---+---+---+---+
| |
: Remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+

Figure 4: Basic SigComp message not longer required by any compartment.

5. The length field order in which the existing state items are freed is a 3-bit value (MSBs before LSBs) that indicates
determined by the length of state_retention_priority, which is set when the
state identifier. items are created. The actual size n 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
identifier item created first in the compartment is calculated as follows:

n = minimum_hash_size + length - 1 also
the first to be freed.

The state identifier state_retention_priority is then extracted from the SigComp message and
then executed always stored on a per-compartment
basis as defined by part of the STATE-EXECUTE instruction list of Chapter
9.

If state items created by each compartment.
In particular the length value is set 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 0 any particular compartment. However, if
they are created on a per-compartment basis then no they must not
interfere with the state is accessed; instead created at the entire SigComp message request of the remote
endpoint. The special state_retention_priority of 65535 is reserved
for locally available state items to ensure that this is copied into the case.

The UDVM memory beginning
at Address 6, and then executed starting from Address 6.

All other addresses in may also explicitly request the UDVM memory are initialized state handler to 0.

Decompression failure occurs if free a
specific state item in a compartment. In this case the SigComp message is too short to
contain state handler
deletes the expected state identifier, or if item from the list of state items created by the
compartment (as before the state item itself must not be physically
deleted unless the requested state does handler determines that it is not exist. See Section 8.2 for further details. longer
required by any compartment).

Price, Hannu, et al. [Page 12] 20]

INTERNET-DRAFT SigComp March 1, 2002

4.3. Interfaces to and from the compressor dispatcher

When the application provides a message to be compressed, it MUST
also provide an "endpoint identity" that distinguishes the endpoint
from other endpoints.

The exact format of the endpoint identity is unimportant, provided
that distinct endpoints have distinct endpoint identities. Signaling Compression 2002-05-06

The SigComp layer contains one compressor for each remote endpoint
with which the local application is communicating; the dispatcher
forwards each new application message to the appropriate compressor
(invoking a new compressor if a new endpoint identity is
encountered).

Note that the application MUST should indicate to the compressor dispatcher state handler when it no longer wishes
to communicate with close a particular endpoint, compartment, so that the resources taken by the
corresponding compressor state can be reclaimed.

4.4. Interfaces

6.3. Feedback data

The SigComp feedback mechanism allows feedback data to be received by
a UDVM and from forwarded via the decompressor dispatcher

To ensure that state handler to the correct compressor.

Since this feedback data is retained between SigComp can run over an unsecure transport layer, messages, it is
considered to be part of the
decompressor dispatcher invokes overall state and can only be forwarded
if accompanied by a new decompressor for each new
SigComp message. Resources for valid compartment identifier. If this is the decompressor are released as soon
as case
then the message is decompressed.

Upon state handler forwards the arrival of a SigComp message feedback data to the decompressor dispatcher
invokes an instance of compressor
responsible for sending messages that pertain to the UDVM and loads it with peer compartment
of the indicated state
as per Section 4.2. The specified compartment.

7. SigComp message is then decompressed by format

This chapter describes the UDVM,
returned to format of the decompressor dispatcher, SigComp message and passed on how the
message is used to initialize the
receiving application. UDVM memory.

Note that when the UDVM SigComp message is invoked it does not receive any compressed
data by default, but copied into the UDVM memory as
soon as it arrives; instead requests new the UDVM indicates when it requires
compressed data explicitly using a specific instruction. Therefore, the dispatcher is responsible for
buffering each SigComp message It then pauses and passing
waits for the data 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
it the UDVM is requested. If invoked,
the size of the UDVM requests additional compressed data that memory depends on whether the transport used to
provide the SigComp message is not yet available 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 pauses and waits until enough data has
been received by is passed to the dispatcher.

Uncompressed data UDVM.
So if the message is also outputted by n bytes long then the UDVM using memory size is set to
(decompression_memory_size - n), up to a specific
instruction. Note that the UDVM has no awareness maximum of whether 65536 bytes.

If the
underlying transport is message-based or stream-based, and so it
always outputs uncompressed data as stream-based however then a stream. It fixed-size input
buffer is required to accommodate the
responsibility stream, independently of the dispatcher
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 provide decompress the uncompressed message
to the application in the expected form (i.e. as a stream (e.g. one or as more previously
received messages, a set dictionary of distinct, bounded messages). common SIP phrases etc.). This
information can either be uploaded as part of the SigComp message or

Price, Hannu, et al. [Page 13] 21]

INTERNET-DRAFT Signaling Compression 2002-05-06

retrieved from an item of state.

A SigComp March 1, 2002

For message takes one of two forms depending on whether it
accesses a stream-based transport, the dispatcher delimits messages by
parsing state item at the compressed data stream for instances receiving endpoint. The two variants of 0xFF and taking
the following actions:

Occurs in data stream: Meaning:

0xFF 00 one 0xFF byte
a SigComp message are given in the data stream
0xFF 01 same, but the next byte is quoted (could
be another 0xFF) Figure 3.

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 :
0xFF 7F same, but the next 127 bytes are quoted
0xFF 80 to 0xFF FE reserved
0xFF FF : returned feedback item :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | code_len |
: partial state identifier : +---+---+---+---+---+---+---+---+
| | | code_len | destination |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: remaining SigComp message boundary

The reserved characters are useful for byte stuffing (if a
compression algorithm generates compressed data containing the
character 0xFF then it should be replaced by the character 0xFF00 to
avoid accidentally inserting : : uploaded UDVM bytecode :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+

Figure 3: Format of a SigComp message delimiter into

Decompression failure occurs if the compressed
data stream).

5. SigComp compressor

An important feature of SigComp message is that if two endpoints cannot agree
on a common algorithm with which too short to send and receive data, it is
possible for
contain the compressor to upload bytecode expected fields (see Section 8.7 for further details).

The fields except for its own choice of
algorithm to the decompressor. In particular this means that it is
not necessary to force all compressors "remaining SigComp message" are referred to use
as the same default
algorithm; instead each implementer has "SigComp header" (note that this may include the freedom to pick one uploaded UDVM
bytecode).

7.1. Returned feedback item

For both variants of the predefined algorithms or to upload their own if needed.

The overall requirement placed on SigComp message, the compressor T-bit is that of
transparency, i.e. the compressor MUST NOT send bytecode which cause
the UDVM set to incorrectly decompress 1
whenever the SigComp message contains a given message. returned feedback item. The following more specific requirements are also placed on the
compressor (they can be considered particular instances
format of the
transparency requirement):

* It returned feedback item is RECOMMENDED illustrated in Figure 4.

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 :

Price, Hannu, et al. [Page 22]

INTERNET-DRAFT Signaling Compression 2002-05-06

| |
+---+---+---+---+---+---+---+---+

Figure 4: Format of returned feedback item

Note that the compressor supply a CRC over returned feedback length specifies the size of the
returned feedback field (from 0 to 127 bytes). So the total size of
the
uncompressed message returned feedback item lies between 1 and 128 bytes.

The returned feedback item is not copied to ensure that successful decompression has
occurred. A the UDVM instruction memory; instead
it is provided to verify this CRC.

* If buffered until the transport UDVM has successfully decompressed the
SigComp message. It is message-based then forwarded to the compressor MUST
preserve state handler with the boundaries between messages.

* If
rest of the transport is stream-based but feedback data (see Section 9.4.9 for further details).

7.2. Accessing stored state

The len field of the application defines its
own internal SigComp message boundaries, then determines which fields follow
the compressor SHOULD
preserve returned feedback item. If the boundaries between messages by using len field is non-zero then the "end-of-
message" character 0xFFFF reserved by SigComp.

Price, Hannu, et al. [Page 14]

INTERNET-DRAFT
SigComp March 1, 2002

* The compressor MUST NOT exceed message contains a state identifier to access a state item at
the maximum_compressed_size and
MUST ensure that 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 message can be decompressed using no more
than identifier if the resources available sender believes that this
is sufficient to match a unique state item at the remote decompressor. receiving endpoint.

The reason for preserving len field encodes the message boundaries over a stream-based
transport 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 that damage 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.
Decompression failure also occurs if exactly one compressed message does not affect state item is
matched but the decompression state item contains a minimum_access_length greater
than the length of subsequent messages. Moreover, the application
typically vetoes partial state creation requests on a per-message basis.

5.1. Supplying bytecode to identifier. This prevents
especially sensitive state items from being accessed maliciously by
brute force guessing of the UDVM

A compressor MUST be certain that compressed data can be decompressed
before state_identifier.

If a state item is successfully accessed then the data state_value byte
string is to be sent, i.e. copied into the UDVM instructions for
decompression MUST be available memory beginning at the remote decompressor. Several
options exist for ensuring that this bytecode is available:

1. Each SigComp message sent from the compressor contains the
necessary state_address.

The first 32 bytes of UDVM instructions for decompression.

2. By setting up a reliable connection, such memory are then initialized to special
values as a TCP connection,
between a compressor and its remote decompressor the illustrated in Figure 5.

Price, Hannu, et al. [Page 23]

INTERNET-DRAFT Signaling Compression 2002-05-06

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
instructions can be transferred and saved as state.

3. If there memory

The first five 2-byte words are predefined UDVM codes for well-known algorithms, a
compressor only needs initialized to send the state identifier of contain some values
that UDVM
decompression algorithm code might be useful to its remote decompressor. The
decompressor the UDVM bytecode (Useful Values). Note that
these values are for information only and can then populate be overwritten when
executing the UDVM locally.

In order bytecode without any effect on the endpoint. The
MSBs of each 2-byte word are stored preceding the LSBs.

Addresses 0 to save delay for "time-critical" sessions, 5 indicate the UDVM
instructions should be uploaded prior resources available to any initiation of "time-
critical" sessions.

5.2. Compression failure the receiving
endpoint. The compressor SHOULD make every effort to successfully compress an
application message, but UDVM memory size is expressed in certain cases this might not be possible
(particularly if a low maximum_compressed_size has been bytes modulo 2^16, so
in particular it is set by to 0 if the
application). In this case a "compression failure" UDVM memory size is called.
Reasons for compression failure include 65536 bytes.
The cycles_per_bit is expressed as 2-byte integer taking the following:

* A compressed value
16, 32, 64 or uncompressed message exceeds the maximum size
defined by the application.

* 128. The maximum_compressed_size SigComp_version is exceeded for expressed as a certain message.

* Insufficient resources 2-byte value
as per Section 3.3.2.

Addresses 6 to 9 are available at initialized to the compressor or at length of the
remote decompressor.

If a compression failure occurs when compressing partial state
identifier, followed by the state_length from the retrieved state
item. Both are expressed as 2-byte values.

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 message 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
compressor informs 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 and takes no further action. The until requested by the UDVM.

Price, Hannu, et al. [Page 15] 24]

INTERNET-DRAFT SigComp March 1, 2002

dispatcher MUST report this failure Signaling Compression 2002-05-06

(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 application. The
application may then try UDVM bytecode is free to use these locations for any other methods
purpose a memory location might be used for; it just has to deliver be aware
they are not necessarily initialized to zero.)

7.3. Uploading UDVM bytecode

If the message.

6. State handling and state announcement

This chapter defines len field is set to 0 then the behavior of bytecode needed to decompress
the SigComp state handler. message is supplied as part of the message itself. The
function
12-bit code_len field specifies the size of the state handler is uploaded UDVM
bytecode (from 0 to retain information between
successive SigComp messages; it is 4095 bytes inclusive); eight most significant
bits are in the only SigComp entity 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
capable of this function, and so it
copied. The destination field is of particular importance from
a security perspective.

6.1. Storing and retrieving state

To provide security against 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 malicious insertion or modification
of encoding 0000 is reserved for future SigComp messages, the versions,
and causes a decompression failure in Version 0x01.

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 is reset after decompressing
each message. This ensures that damaged
address specified by the destination field. As above, the remaining
SigComp messages do not
prevent message is held by the successful decompression decompressor dispatcher until needed
by the UDVM.

8. Overview of subsequent valid messages.

Note however that the overall compression ratio UDVM

Decompression functionality for SigComp is often
significantly higher if messages can be compressed relative to provided by a "Universal
Decompressor Virtual Machine" (UDVM). The UDVM is a virtual machine
much like the
information stored in previous messages. For this reason Java Virtual Machine but with a key difference: it is
possible to create "state" information
designed solely for access when a later
message is being decompressed.

Both the creation and access purpose of state are designed to be secure
against malicious tampering with running decompression algorithms.

The motivation for creating the compressed data. State can only
be created UDVM is to provide unlimited
flexibility when choosing how to compress a complete message has been successfully
decompressed, and the state handler MUST NOT save state without
permission from the application.

Upon receiving a decompressed message, the given application may supply the
state handler with the identity
message. Rather than picking one of a small number of pre-negotiated
algorithms, the sending endpoint. Supplying
this identity grants permission for compressor implementer has the state handler freedom to do the
following:

* An item select an

Price, Hannu, et al. [Page 25]

INTERNET-DRAFT Signaling Compression 2002-05-06

algorithm of state can be saved using the memory reserved for their choice. The compressed data is then combined with
a set of UDVM instructions that allow the
specified endpoint.

* Announcement information can be taken into account
when sending SigComp messages original data to be
extracted, and the specified endpoint.

This result is especially useful if the application has an authentication
mechanism that can be applied to determine whether outputted as a SigComp message. Since
the decompressed
data UDVM is legitimate.

Also note that state 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 deleted when it is accessed. So even if a
malicious user manages add significant extra
processing or memory requirements compared to access state information, subsequent
messages running a fixed pre-
programmed decompression algorithm.

Figure 6 gives a detailed view of the interfaces between the UDVM and
its environment.

+----------------+ +----------------+
| | Request compressed relative to this data | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide compressed data | |
| | | |
| | Output decompressed data | Decompressor |
| |-------------------------------->| dispatcher |
| | | |
| | Indicate end of message | |
| |-------------------------------->| |
| |<--------------------------------| |
| UDVM | Provide compartment identifier | |
| | +----------------+
| |
| | +----------------+
| | Request state can still be successfully
decompressed. Instead, the information | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide state information | State |
| | | handler is responsible for deleting

Price, Hannu, et al. [Page 16]

Figure 6: Interfaces between the UDVM and its environment

Note that once the UDVM has been initialized, additional compressed
data and state will no longer be
needed.

Each item of state stores information are only provided at the following information:

Name: Type of data:

state_identifier 16-byte value
state start 2-byte value
state_instruction 2-byte value
state length 2-byte value
state_value String request of bytes

The state_identifier must be supplied to retrieve an item a
specific UDVM instruction.

This chapter describes the basic features of state
from the state handler. State can be accessed using UDVM including the
UDVM
instructions STATE-REFERENCE and STATE-EXECUTE, registers and can be created
using the END-MESSAGE instruction. format of UDVM bytecode.

8.1. UDVM registers

Price, Hannu, et al. [Page 26]

INTERNET-DRAFT Signaling Compression 2002-05-06

The state_value is a byte string that contains the actual value that
is copied from/to UDVM registers are 2-byte words in the UDVM memory. The state_length specifies memory that have
special tasks, for example specifying the
number location of bytes contained within state_value, the stack used
by the CALL and state_start gives RETURN instructions.

The UDVM registers are illustrated in Figure 7.

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 memory address to which registers

The MSBs of each register are always stored before the state_value is copied when it is
accessed.

Finally, state_instruction specifies LSBs. So, for
example, the memory address MSBs of byte_copy_left are stored at Address 64 whilst
the next
UDVM instruction to execute when state is accessed. LSBs are stored at Address 65.

The kind use of information which is included in the state_value each UDVM register is up to
a particular compressor and the uploaded instructions defined in the remote
UDVM. However a compressor MUST NOT use a state following sections.

(Note that is not known to
be established the UDVM registers start at Address 64, that is 32 bytes
after the remote decompressor.

6.2. Saving and deleting states

The state handler area reserved for each endpoint Useful Values. The intention is expected to offer memory to
store UDVM-created state. Every remote endpoint that wishes to
communicate with the local endpoint expects to be able to store a
fixed amount of state;
gap, i.e., the number of bytes area between Address 32 and Address 63, will often be
used as scratch-pad memory that it can store is given
by the formula UDVM_memory_size * maximum_state_size.

Note that each item of state costs (state_length + 22) bytes guaranteed to
store. be zero at UDVM
startup and is efficiently addressible in operand types reference ($)
and multitype (%).)

8.2. Requesting additional compressed data

The state handler keeps track of which endpoint created each item of
state; when a particular endpoint exceeds its allocated memory limit
then sufficient items of state created by decompressor dispatcher stores the same endpoint are
deleted (oldest state first) until enough memory is available to
accommodate compressed data from the new state.

Price, Hannu, et al. [Page 17]

INTERNET-DRAFT
SigComp March 1, 2002

The application MUST indicate to the state handler when message before it no longer
wishes to communicate with a particular endpoint, so that the
resources taken is requested by the corresponding state can be reclaimed.

6.3. Announcement

The announcement information UDVM via one of the
INPUT instructions. When the UDVM bytecode is used to modify first executed the value of certain
application-defined parameters. Since these parameter values are
saved between
dispatcher contains the remaining SigComp messages, they are considered to be part of message after the
overall state and hence are supplied from header
has been used to initialize the UDVM to as per Chapter 7.

Note that the state
handler.

The following list INPUT-BITS and INPUT-HUFFMAN instructions retrieve a
stream of parameters is passed to individual compressed bits from the state handler using dispatcher. To provide
bitwise compatibility with various well-known compression algorithms,
the appropriate UDVM instruction (namely input_bit_order register can modify the END-MESSAGE
instruction):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDVM_version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDVM_memory_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_1 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_n :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: reserved :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Announcement information order in which individual
bits are passed within a byte.

The input_bit_order register contains the following three flags:

Price, Hannu, et al. [Page 18] 27]

INTERNET-DRAFT SigComp March 1, 2002

If Signaling Compression 2002-05-06

0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |F|H|P| 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The P-bit controls the application does not return a valid endpoint identifier then order in which bits are passed from the announcement information is automatically discarded by
dispatcher to the state
handler. Otherwise 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 compressor responsible for
sending messages 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 given endpoint.

The reserved field allows INPUT instructions for additional items 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 data a byte (what used to be added to
the announcement information in future.

Note that the length field specifies LSBs if P = 0, or, the total length of
MSBs, if P = 1). If an INPUT instruction is encountered and the
announcement information including P-
bit has changed since the reserved field. As usual, MSBs
are stored preceding LSBs.

The remaining items of data are explained in greater detail below:

6.3.1. UDVM version

The next 2 bytes last INPUT instruction, any fraction of a
byte still held by the announcement information specify whether only dispatcher MUST be discarded (even if the basic version of
INPUT instruction requests zero bits). The first bit passed to the UDVM
INPUT instruction is available, or whether taken from the subsequent byte.

When an upgraded
version INPUT instruction requests n bits of compressed data, it
interprets the UDVM is available offering additional instructions
etc. received bits as an integer between 0 and 2^n - 1. The basic version of
F-bit and the UDVM is Version 0, which is H-bit specify whether the version
described bits in this document. Upgraded versions MUST be backwards-
compatible with the basic version these integers are
considered to arrive in the following sense:

* If some UDVM bytecode reaches the END-MESSAGE MSB to LSB order (bit set to 0) or DECOMPRESSION-
FAILURE instructions when running on Version 0 of in LSB to
MSB order (bit set to 1).

If the UDVM, then F-bit is set to 0, the upgraded version MUST run INPUT-BITS instruction interprets the bytecode in an identical
manner.

This condition ensures that all bytecode that
received bits as arriving MSBs first, and if it is valid for Version 0
of the UDVM will continue set to be valid for upgraded versions of 1 it
interprets the
UDVM. However, bytecode that is invalid on Version 0 of bits as arriving LSBs first. The H-bit performs the UDVM
(i.e. bytecode that produces a decompression failure
same function for the INPUT-HUFFMAN instruction. Note that it is not
manually triggered) may become valid on upgraded versions.

The simplest way
possible to upgrade the UDVM set these two bits to different values in a backwards-compatible manner
is order to add additional UDVM use

Price, Hannu, et al. [Page 28]

INTERNET-DRAFT Signaling Compression 2002-05-06

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, as this will not affect unlike the
operation of existing UDVM bytecode.

6.3.2. Memory size and CPU cycles

The next 6 bytes of data specify new values discard rule for the application-
defined parameters UDVM_memory_size, cycles_per_bit P-bit described
above.)

Decompression failure occurs if an INPUT-BITS or an INPUT-HUFFMAN
instruction is encountered and
cycles_per_message.

Note that this data can only be used to increase the amount input_bit_order register does not
lie between 0 and 7 inclusive.

8.3. UDVM stack

Certain UDVM instructions make use of
resources available a stack of 2-byte words stored
at the remote UDVM. If memory address specified by the data specifies a
parameter value that 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 smaller than the value already possessed by an abbreviation for the state handler, contents of
the parameter keeps its original value (i.e. stack_location register, i.e., the
announcement data 2-byte word at locations 70
and 71. The notation stack_fill is an abbreviation for this parameter the 2-byte
word at stack_location and stack_location+1. Similarly, the notation
stack[n] is simply ignored).

Price, Hannu, et al. [Page 19]

INTERNET-DRAFT SigComp March 1, 2002

In particular, only allowing an abbreviation for the parameter values to increase means
that 2-byte word at
stack_location+2*n+2 and stack_location+2*n+3. (As always, the announcement mechanism
arithmetic is robust against message loss or
reordering. modulo 2^16.)

The parameters can only be restored to their original values if reset
or renegotiated stack is used by the application.

6.3.3. State identifiers

The list of state identifiers indicates that CALL, RETURN, PUSH and POP instructions.

"Pushing" a value on the sending endpoint
supports one or more optional mechanisms (including well-known
decompression algorithms, dictionaries of common SIP phrases,
feedback mechanisms etc.).

The integer n specifies stack is an abbreviation for copying the number of state identifiers
value to follow.
The field id_length_j specifies the length in bytes of id_value_j,
where acceptable stack[stack_fill] and then increasing stack_fill by 1. CALL
and PUSH push values for id_length_j range from 1 to 16 inclusive.
If on the stack.

"Popping" a value outside this range is received then the subsequent state
identifiers are ignored by from the state handler.

Each id_value_j indicates support stack is an abbreviation for one optional mechanism at the
sending endpoint. The optional mechanisms themselves, decreasing
stack_fill by 1, and their
corresponding state identifiers, are beyond the scope of this
document.

7. Overview of then using the UDVM value stored in
stack[stack_fill]. Decompression functionality for SigComp is provided by a "Universal
Decompressor Virtual Machine" (UDVM). The UDVM failure occurs if stack_fill is a virtual machine
much like
zero at the Java Virtual Machine but with commencement of a key difference: it is
designed solely for popping operation. POP and RETURN pop
values from the purpose stack.

For both of running decompression algorithms.

The motivation for creating these abstract operations, the UDVM is to provide unlimited
flexibility when choosing how to compress a given item of data.
Rather than picking one first takes note of a small number
the current value of pre-negotiated
compression algorithms, stack_location and uses this value for both sub-
operations (accessing the implementer has stack and manipulating stack_fill), i.e.
overwriting stack_location in the freedom to select an
algorithm course of their choice. The compressed data the operation is then combined with
a set

Price, Hannu, et al. [Page 29]

INTERNET-DRAFT Signaling Compression 2002-05-06

inconsequential for the operation.

8.4. Byte copying

A number of UDVM instructions that allow the original data require a string of bytes to be
extracted, copied
to and from areas of the result is outputted as UDVM bytecode.

Since memory. This section defines how the UDVM
byte copying operation should be performed.

The string of bytes is optimized specifically for running decompression
algorithms, the code size copied in ascending order of memory address,
respecting the bounds set by byte_copy_left and byte_copy_right. More
precisely, if a typical algorithm byte is small (often sub
100 bytes). Moreover copied from/to Address m then the UDVM approach does not add significant extra
processing or memory requirements compared to running 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 fixed pre-
programmed decompression algorithm.

This chapter describes some basic features of the UDVM, including byte is copied from/to an address
beyond the
well-known variables and instruction operands.

Price, Hannu, et al. [Page 20]

INTERNET-DRAFT SigComp March 1, 2002

Recall UDVM memory.

Note that the amount of memory available to the UDVM string of bytes is specified
by copied one byte at a time. In
particular, some of the application-defined parameter UDVM_memory_size. Any attempt later bytes to
read memory addresses beyond the overall memory size MUST cause a
decompression failure (see Section 8.2).

7.1. Well-known variables

The first few variables in be copied may themselves have
been written into the UDVM memory have special tasks, for
example specifying the location of the stack used by the CALL and
RETURN instructions. Each of these well-known variables byte copying operation
currently being performed.

Equally, it is possible for a 2-byte
integer.

The following list gives byte copying operation to overwrite the name of each well-known variable and
instruction that invoked the
memory address at which byte copy. If this occurs then the variable can byte
copying operation MUST be found:

Name: Starting completed as if the original instruction
were still in place in the UDVM memory address: (this also applies if
byte_copy_left 0 or byte_copy_right 2
stack_location 4

The MSBs of each variable are always stored before the LSBs. So, for
example, the MSBs of stack_location are stored at Address 4 whilst
the LSBs are stored at Address 5.

The use of each well-known variable overwritten).

Byte copying is described in used by the following
sections of the document.

7.2. 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. 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, Hannu, et al. [Page 30]

INTERNET-DRAFT Signaling Compression 2002-05-06

To reduce the code size of a typical UDVM program, bytecode, each operand for a UDVM
instruction is compressed using variable-length encoding. The aim is
to store more common operand values using fewer bits bytes than rarely
occurring values.

Three

Four different types of operand are available: the literal, the
reference
reference, the multitype and the address. Chapter 9 gives a complete
list of UDVM instructions and the multitype. The operand types that follow each UDVM
instruction are specified in Chapter 9.
instruction.

The UDVM bytecode for each operand type is illustrated in Figure 7 8 to
Figure 9, 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).

Price, Hannu, et al. [Page 21]

INTERNET-DRAFT SigComp March 1, 2002

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 case is cases are
denoted by memory[X] where X is the address and memory[X] is the 2-
byte
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 7: 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.

Note that reference operands can always take values from 0 to 65535
inclusive, as they reference 2-byte values.

Bytecode: Operand value: Range:

0nnnnnnn memory[2 * N] 0 - 65535

Price, Hannu, et al. [Page 31]

INTERNET-DRAFT Signaling Compression 2002-05-06

10nnnnnn nnnnnnnn memory[2 * N] 0 - 65535
11000000 nnnnnnnn nnnnnnnn memory[N] 0 - 65535

Figure 8: 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

Price, Hannu, et al. [Page 22]

INTERNET-DRAFT SigComp March 1, 2002
110nnnnn nnnnnnnn memory[N] 0 - 65535
10000000 nnnnnnnn nnnnnnnn N 0 - 65535
10000001 nnnnnnnn nnnnnnnn memory[N] 0 - 65535

Figure 9: 10: Bytecode for a multitype (%) operand

7.3. Byte copying

A number

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

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 instructions require encounters a string of bytes JUMP instruction). If the next instruction

Price, Hannu, et al. [Page 32]

INTERNET-DRAFT Signaling Compression 2002-05-06

to be copied 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 and from areas
each message. The number of the available UDVM memory. This section defines how cycles is initialized to
1000 plus the
byte copying operation should be performed.

In general, number of bits in the string 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 bytes available UDVM cycles is copied
decreased by the amount specified in ascending order Chapter 9. Additionally, if the
UDVM successfully requests n bits of
memory address. 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 byte compressed message given to the UDVM is copied from/to Address n corrupted (either
accidentally or maliciously) then the
next byte is copied from/to Address n + 1. As usual, if UDVM may terminate with a byte
decompression failure.

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 that the number of remaining UDVM
cycles.

4. The UDVM attempts to read from an or write to a memory address beyond the overall

Price, Hannu, et al. [Page 33]

INTERNET-DRAFT Signaling Compression 2002-05-06

its memory size then
decompression failure occurs.

Note however that if a byte size.

5. An unknown instruction is copied from/to the memory address
specified in byte_copy_right, the byte copy operation continues encountered.

6. An unknown operand is encountered.

7. An instruction is encountered that cannot be processed
successfully by
copying the next byte from/to the memory address specified in
byte_copy_left. This 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 useful for setting up triggered using the
DECOMPRESSION-FAILURE instruction.

If a "circular buffer"
within decompression failure occurs when decompressing a message then
the UDVM memory.

Note that informs the string of bytes dispatcher and takes no further action. It is copied on a purely byte-by-byte
basis. In particular, some
the responsibility of the later bytes dispatcher to be copied may
themselves have 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 written into outputted but
not yet passed to the application.

9. UDVM instruction set

The UDVM memory by the byte copying
operation currently being performed.

Equally, it is possible for a byte copying operation understands 33 instructions, chosen to overwrite support the
instruction that called
widest possible range of compression algorithms with the byte copy. If this occurs then minimum
possible overhead.

Figure 11 lists the byte
copying operation MUST be completed as if different instructions and the original bytecode values
used to encode the instructions. The cost of each instruction
were still in place in the UDVM memory (this
cycles is also applies if
byte_copy_left or byte_copy_right are overwritten).

8. Decompressing a SigComp message

This chapter lists the steps involved given:

Instruction: Bytecode value: Cost in the decompression of a
single SigComp message.

8.1. Invoking the UDVM

Whenever the dispatcher receives a message to be decompressed, it
invokes a new instance of the UDVM. The UDVM_memory_size is
initialized using the 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))
SORT-DESCENDING 12 1 + k * ceiling(log2(k))

Price, Hannu, et al. [Page 34]

INTERNET-DRAFT Signaling Compression 2002-05-06

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 + offset
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 application-defined parameter.
The following steps are then taken:

1.) The number bytecode values

Each UDVM instruction costs a minimum of remaining CPU 1 UDVM cycle. Certain
instructions may cost additional cycles is set equal to depending on the
application-defined parameter cycles_per_message.

Price, Hannu, et al. [Page 23]

INTERNET-DRAFT SigComp March 1, 2002

Notes:

The amount values of compressed data available to the UDVM is exactly one
compressed message. If the transport is stream-based then SigComp
uses
the reserved byte string 0xFFFF to delimit instruction operands.

Note that for the compressed
messages: SORT instructions, the dispatcher takes formula ceiling(log2(k))
calculates the data between a pair of neighboring
reserved byte strings to be a single compressed message. smallest value n such that k <= 2^n.

The reserved
byte string itself is not considered to be part UDVM instruction set offers a mix of the compressed
message. low-level and high-level
instructions. The compressed data is not provided to the UDVM by default. Instead,
the UDVM requests compressed data using the INPUT high-level instructions
(useful when running over a stream-based transport since there is no
need to wait for the entire compressed message before decompression can begin).

The dispatcher MUST NOT make more than one compressed message
available to a given instance all be emulated using
combinations of the UDVM. In particular, the
dispatcher MUST NOT concatenate two messages to form low-level instructions, but given a single
compressed message. This choice it is because compressed messages are typically
padded with trailing zero bits so that they are
generally preferable to use a whole single instruction rather than a large
number of
bytes long. Concatenating two messages would cause these padding bits general-purpose instructions. The resulting bytecode will
be more compact (leading to a higher overall compression ratio) and
decompression will typically be incorrectly interpreted as compressed data.

2.) Next, faster because the instructions contained within implementation of
the UDVM memory high-level instructions can be more easily optimized.

All instructions are
executed beginning at encoded as a single byte to indicate the address specified
instruction type, followed by 0 or more bytes containing the state as per
Section 4.2.

Notes: operands
required by the instruction. The instructions are executed consecutively unless otherwise
indicated (for instruction specifies which of the
four operand types of Section 8.5 is used in each case. For example when
the UDVM encounters a JUMP instruction).

If ADD instruction is followed by two operands:

Price, Hannu, et al. [Page 35]

INTERNET-DRAFT Signaling Compression 2002-05-06

ADD ($operand_1, %operand_2)

When converted into bytecode the next number of bytes required by the ADD
instruction to be executed lies outside depends on the available value of each operand, and whether the
multitype operand contains the operand value itself or a memory then decompression failure occurs (see Section 8.2).

3.)
address where the actual value of the operand can be found.

Each time instruction is explained in more detail below.

Whenever the description of an instruction uses the expression "and
then", the intended semantics is executed 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)

After the number of available
CPU cycles operation is decreased by the amount specified in Chapter 9.
Additionally, if the UDVM requests n bits of compressed data (using
one of the INPUT instructions) then complete, the number value of available CPU
cycles is increased by n * cycles_per_bit.

Notes:

This means that the total number of CPU cycles available for
processing a compressed message first operand is given by
overwritten with the formula:

maximum_cycles = cycles_per_message + message_size * cycles_per_bit

The reason result. (Note that since this total operand is not allocated to the UDVM when a
reference, it is
invoked 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 UDVM can begin to decompress a message 2-byte values encoded by the operands, and that has
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)

Price, Hannu, et al. [Page 24] 36]

INTERNET-DRAFT SigComp March 1, 2002

only been partially received. So Signaling Compression 2002-05-06

SUBTRACT ($operand_1, %operand_2)
MULTIPLY ($operand_1, %operand_2)
DIVIDE ($operand_1, %operand_2)
REMAINDER ($operand_1, %operand_2)

After the total message size may not be
known when operation is complete, the UDVM value of the first operand is initialized.

4.)
overwritten with the result.

The UDVM stops executing instructions when it encounters an
END-MESSAGE precise definition of each instruction or if decompression 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.

Notes: occurs if a DIVIDE or REMAINDER instruction
encounters an operand_2 that is zero.

9.1.3. Sorting

The UDVM passes uncompressed data to 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 dispatcher using starting memory address of the OUTPUT
instruction. The OUTPUT instruction can be used block
of data to output a partially
decompressed message; it be sorted.

The block of data itself is divided into n lists each containing k
2-byte words. The SORT-ASCENDING instruction applies a dispatcher decision whether certain
permutation to use the
data immediately or whether to buffer and wait until lists, such that the entire
message has been decompressed. first list is sorted into
ascending order (treating each 2-byte word as an unsigned integer).
The UDVM passes state creation requests to the state handler using
the END-MESSAGE instruction. This means that it same permutation is only possible applied to
make a state creation request once all n lists, so lists other than
the message has been decompressed,
which is necessary since first will not necessarily be sorted into order.

In the application typically determines case that two words have the
validity of these requests based on same value, the contents original ordering
of the decompressed
message.

8.2. Decompression failure

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

Reasons for decompression failure include the following:

* A compressed or uncompressed message exceeds the maximum size
defined by the application.

* The UDVM exceeds preserved.

For example, the available CPU cycles for decompressing first list might contain a
message.

* The UDVM attempts set of integers to read a memory address beyond the overall
memory size.

* An unknown instruction type is encountered.

* An unknown operand type is encountered.

* An instruction is encountered that cannot be processed
successfully by
sorted whilst the UDVM (for example a RETURN instruction when
no CALL instruction has previously been encountered).

* The UDVM attempts second list might be used to access non-existent state.

* A manual decompression failure is triggered using keep track of where
the
DECOMPRESSION-FAILURE instruction. integers appear in the sorted list:

Before sorting After sorting

List 1 List 2 List 1 List 2

Price, Hannu, et al. [Page 25] 37]

INTERNET-DRAFT SigComp March 1, 2002

If a decompression failure occurs when decompressing Signaling Compression 2002-05-06

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 message then 20-byte SHA-1 hash [PUB-180-1]
over the specified area of UDVM informs memory.

SHA-1 (%position, %length, %destination)

The position and length operands specify the dispatcher starting memory address
and takes no further action. It is the responsibility length of the dispatcher 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 decide how 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 cope with set up the
decompression failure. In general UDVM memory, and to
copy byte strings from one memory location to another.

9.2.1. LOAD

The LOAD instruction sets a dispatcher SHOULD discard 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
compressed message and any decompressed data that has been outputted.

9. UDVM instruction set memory.

9.2.2. MULTILOAD

The MULTILOAD instruction sets a contiguous block of 2-byte words in
the UDVM currently understands 30 instructions, chosen memory to support specified values.

MULTILOAD (%address, #n, %value_0, ..., %value_n-1)

The first operand specifies the
widest possible range starting address of compression algorithms with the minimum
possible overhead.

Figure 10 lists contiguous
2-byte words, whilst the different instructions and operands value_0 through to value_n-1

Price, Hannu, et al. [Page 38]

INTERNET-DRAFT Signaling Compression 2002-05-06

specify the bytecode values
used to store load into these words (in the instructions at same order as
they appear in the UDVM. The cost instruction).

Decompression failure occurs if the set of each
instruction in CPU cycles is also given:

Instruction: Bytecode value: Cost in CPU cycles:

DECOMPRESSION-FAILURE 0 1
AND 1 1
OR 2 1
NOT 3 1
ADD 4 1
SUBTRACT 5 1
MULTIPLY 6 1
DIVIDE 7 1
SORT-ASCENDING 8 1 + k * ceiling(log2(k))
SORT-DESCENDING 9 1 + k * ceiling(log2(k))
MD5 10 1 + length
LOAD 11 1
MULTILOAD 12 1 + n
COPY 13 1 + length
COPY-LITERAL 14 1 + length
COPY-OFFSET 15 1 + length + offset
JUMP 16 1
COMPARE 17 1
CALL 18 1
RETURN 19 1
SWITCH 20 1 + n
CRC 21 1 + length
END-MESSAGE 22 1 + state length
OUTPUT 23 1 + output_length
NBO 24 1
INPUT-BYTECODE 25 1 + length
INPUT-FIXED 26 1
INPUT-HUFFMAN 27 1 + n
STATE-REFERENCE 28 1 + state_length
STATE-EXECUTE 29 1 + state length

Figure 10: UDVM 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 corresponding bytecode values

Price, Hannu, et al. [Page 26]

INTERNET-DRAFT SigComp March 1, 2002

Each write to the UDVM stack
(as defined in Section 8.3).

PUSH (%value)
POP (%address)

The PUSH instruction costs pushes the value specified by its operand on the
stack.

The POP instruction pops a minimum 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 1 CPU cycle. Certain high-
level instructions may cost additional cycles depending on the value is inconsequential
for the stack operation itself, which happens beforehand.)

See Section 8.3 for possible error conditions.

9.2.4. COPY

The COPY instruction is used to copy a string of bytes from one part
of the instruction operands. UDVM memory to another.

COPY (%position, %length, %destination)

The only exception when calculating position operand specifies the memory address of the first byte
in the string to be copied, and the length operand specifies the
number of CPU cycles bytes to be copied.

The destination operand gives the address to which the first byte in
the string will be copied.

Byte copying is that performed as per the rules of Section 8.4.

9.2.5. COPY-LITERAL

A modified version of the STATE-EXECUTE COPY instruction takes (1 + state_length) cycles even
though it does not have is given below:

Price, Hannu, et al. [Page 39]

INTERNET-DRAFT Signaling Compression 2002-05-06

COPY-LITERAL (%position, %length, $destination)

The COPY-LITERAL instruction behaves as a state_length operand; instead COPY instruction except
that after copying is completed, the value of the destination operand
is replaced by the value address to which the next byte of
state length data would be
copied. More precisely it is provided replaced by the state handler value n, derived as part per
Section 8.4 with m set to the destination address of the state
being accessed.

All instructions are stored as a single last byte to indicate
be copied, if any.

9.2.6. COPY-OFFSET

A further version of the COPY-LITERAL instruction type, followed by 0 or more bytes containing the operands
required by the instruction. is given below:

COPY-OFFSET (%offset, %length, $destination)

The COPY-OFFSET instruction specifies which behaves as a COPY-LITERAL instruction
except that an offset operand is given instead of a position operand.

To derive the
three operand types value of Section 7.2 is used in each case. For example, the ADD instruction is followed by two operands as shown below:

ADD ($operand_1, %operand_2)

When converted into bytecode position operand, starting at the number of bytes required memory
address specified by destination, the ADD
instruction depends on the size UDVM counts backwards a total
of each operand value, and whether offset memory addresses.

If the second (multitype) operand contains memory address specified in byte_copy_left is reached, the operand value itself or a
next memory address where is taken to be (byte_copy_right - 1) modulo 2^16.

The COPY-OFFSET instruction then behaves as a COPY-LITERAL
instruction, taking the actual value of the position operand can to be found.

The instruction set available for the UDVM offers a mix of low-level
and high-level instructions. The high-level instructions can all be
emulated using last
memory address reached in the low-level instructions provided, but given a
choice it is generally preferable to use a single instruction rather
than a large number of general-purpose instructions. above step.

9.2.7. MEMSET

The resulting
bytecode will be more compact (leading MEMSET instruction initializes an area of UDVM memory to a higher overall
compression ratio) and decompression will typically be faster because
the implementation
specified sequence of the compression-specific instructions can be
optimized for the UDVM.

Each values. The format of a MEMSET instruction is explained in more detail below:

9.1. Mathematical instructions
as follows:

MEMSET (%address, %length, %start_value, %offset)

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

9.1.1. Bit manipulation values used by the MEMSET instruction is specified by
the following formula:

Seq[n] := (start_value + n * offset) modulo 256

The AND, OR values Seq[0] to Seq[length - 1] inclusive are each interpreted
as a single byte, and NOT instructions provide simple bit manipulation on
2-byte words.

AND ($operand_1, %operand_2)
OR ($operand_1, %operand_2)
NOT ($operand_1)

After then concatenated to form a byte string where
the operation is complete, first byte has value Seq[0], the second byte has value of Seq[1] and
so on up to the first operand last byte which has value Seq[length - 1].

The string is
overwritten with then byte copied into the UDVM memory beginning at the result. Note that since this operand is a

Price, Hannu, et al. [Page 27] 40]

INTERNET-DRAFT SigComp March 1, 2002

reference, the Signaling Compression 2002-05-06

memory address specified by the operand is always
overwritten and not the as an operand itself.

9.1.2. Arithmetic

The ADD, SUBTRACT, MULTIPLY and DIVIDE 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)

After the operation is complete, to the first operand is overwritten
with MEMSET instruction,
obeying the result.

Note rules of Section 8.4. (Note that in all cases the arithmetic operation is performed modulo
2^16. So for example, subtracting 1 from 0 gives byte string may
overwrite the result 65535.

For MEMSET instruction or its operands; as explained in
section 8.5, the SUBTRACT MEMSET instruction must be executed as if the second operand is subtracted from
original operands were still in place in the first. Similarly, for UDVM memory.)

9.3. Program flow instructions

The following instructions alter the DIVIDE flow of UDVM code. Each
instruction the first operand is
divided by the second operand. 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 second operand does
not divide exactly into value of the first address operand then lies
beyond the remainder is
ignored.

9.1.3. Sorting overall UDVM memory size.

9.3.2. COMPARE

The SORT-ASCENDING COMPARE instruction compares two operands and SORT-DESCENDING instructions sort lists then jumps to one
of 2-
byte words.

SORT-ASCENDING (%start, %n, %k)
SORT-DESCENDING (%start, %n, %k)

The start operand specifies the starting three specified memory address of addresses depending on the block
of data to be sorted.
The block of data itself is divided into n lists each containing k
words. The SORT-ASCENDING result.

COMPARE (%value_1, %value_2, @address_1, @address_2, @address_3)

If value_1 < value_2 then the UDVM continues instruction applies a certain permutation execution at
the memory address specified by address 1. If value_1 = value_2 then
it jumps to the lists, such that address specified by address_2. If value_1 > value_2
then it jumps to the first list is sorted into ascending order
(treating each data word as an integer). address specified by address_3.

9.3.3. CALL and RETURN

The same permutation is
applied to all n lists, so lists other than CALL and RETURN instructions provide support for compression
algorithms with a nested structure.

CALL (@address)
RETURN

Both instructions use the first will not
necessarily be sorted into order.

For example, UDVM stack of Section 8.3. When the first list might contain UDVM
reaches a set of integers to be
sorted, whilst CALL instruction, it finds the second list might be used to keep track memory address of the
integers:

Before sorting After sorting

List 1 List 2 List 1 List 2

8 1 1 2
instruction immediately following the CALL instruction and pushes

Price, Hannu, et al. [Page 28] 41]

INTERNET-DRAFT SigComp March 1, 2002

1 2 1 3
1 3 3 4
3 4 8 1

In Signaling Compression 2002-05-06

this 2-byte value on the case of two words of data with stack, ready for later retrieval. It then
continues instruction execution at the same value, memory address specified by
the original
ordering of address operand.

When the list is preserved. 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 SORT-DESCENDING SWITCH instruction behaves as above, except that performs a conditional jump based on the
first list value
of one of its operands.

SWITCH (#n, %j, @address_0, @address_1, ... , @address_n-1)

When a SWITCH instruction is sorted into descending order.

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

9.3.5. CRC

The MD5 CRC instruction calculates an MD5 hash over 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 specified area 2-byte
Frame Check Sequence (FCS) of
UDVM memory.

MD5 (%position, %length, %destination) PPP [RFC-1662].

The position and length operands define the string of bytes over
which the MD5 hash CRC is calculated. evaluated. Byte copying rules are enforced as per
Section 7.3.

The destination operand gives the starting address 8.4.

Note that since a CRC calculation is always performed over a
bitstream, for interoperability it is necessary to which define the
resulting 16-byte hash will be copied.

9.2. Memory management instructions

The following instructions order
in which bits are used to manipulate supplied within each individual byte. In this case
the UDVM memory.
Bytes can be copied from one area of memory to another, and areas MSBs of
memory can be write-protected to make it easier for UDVM code to the byte MUST always be
compiled.

9.2.1. LOAD

The LOAD instruction sets a 2-byte variable supplied to a certain specified
value. The format of a LOAD instruction is as follows:

LOAD (%address, %value) the CRC calculation
before the LSBs.

The first value operand specifies contains the starting address expected integer value of the 2-byte
variable, whilst
CRC. If the second operand specifies calculated CRC matches the expected value to be loaded
into this variable. As usual, MSBs are stored before LSBs in then the UDVM
memory.

9.2.2. MULTILOAD

The MULTILOAD instruction sets a contiguous block of 2-byte variables
continues at the following instruction. Otherwise the UDVM jumps to specified values.

MULTILOAD (%address, #n, %value_0, ..., %value_n-1)
The first operand specifies
the starting memory address of the contiguous
variables, whilst specified by the operands value_0 through to value_n-1 specify address operand.

Price, Hannu, et al. [Page 29] 42]

INTERNET-DRAFT Signaling Compression 2002-05-06

9.4. I/O instructions

The following instructions allow the UDVM to interface with its
environment. Note that in the overall SigComp March 1, 2002 architecture all of
these interfaces pass to the values decompressor dispatcher or to load into these variables (in the same order as they
appear in 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).

9.2.3. COPY

This instruction has no operands.

9.4.2. INPUT-BYTES

The COPY INPUT-BYTES instruction is used to copy requests a string certain number of bytes from one part of
compressed data from the UDVM memory to another.

COPY (%position, %length, %destination) decompressor dispatcher.

INPUT-BYTES (%length, %destination, @address)

The position operand specifies the memory address of the first byte
in the string to be copied, and the length operand specifies indicates the requested number of bytes to be copied.

The of
compressed data, and the destination operand gives specifies the starting
memory address to which the first byte in
the string will they should be copied.

Note that byte Byte copying is
performed as per the rules of Section 7.3.

9.2.4. COPY-LITERAL

A modified version 8.4.

If the instruction requests data that lies beyond the end of the COPY
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 given below:

COPY-LITERAL (%position, %length, $destination) 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.

Price, Hannu, et al. [Page 43]

INTERNET-DRAFT Signaling Compression 2002-05-06

The COPY-LITERAL instruction behaves as a COPY instruction except
that after copying, the destination operand is replaced with specifies the memory address immediately following the address to which the final
byte was
compressed data should be copied. If Note that the final byte was copied requested bits are
interpreted as a 2-byte integer ranging from 0 to the memory address
specified 2^length - 1, as
explained in byte_copy_right, Section 8.1.

If the destination operand instruction requests data that lies beyond the end of the
SigComp message, no data is set returned. Instead the UDVM moves program
execution to the
memory address specified in byte_copy_left.

9.2.5. COPY-OFFSET

A further version by the address operand.

9.4.4. INPUT-HUFFMAN

The INPUT-HUFFMAN instruction requests a variable number of bits of
compressed data from the COPY-LITERAL decompressor dispatcher. The instruction
initially requests a small number of bits and compares the result
against a certain criterion; if the criterion is given below:

COPY-OFFSET (%offset, %length, $destination) not met then
additional bits are requested until the criterion is achieved.

The COPY-OFFSET INPUT-HUFFMAN instruction behaves is followed by three mandatory operands
plus n additional sets of operands. Every additional set contains
four operands as a COPY-LITERAL instruction
except shown below:

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 offset operand
integer k from 0 to 2^bits_j - 1, as explained in Section 8.1.

3. Set H := H * 2^bits_j + k.

4. If data is given instead requested that lies beyond the end of a position operand.

To derive a suitable position operand, starting at the memory address
specified by destination, SigComp
message, terminate the UDVM counts backwards a total of offset
memory addresses. If INPUT-HUFFMAN instruction and move program
execution to the memory address specified in byte_copy_left
is reached, by the next memory address is taken to be byte_copy_right.

The COPY-OFFSET instruction operand.

5. If (H < lower_bound_j) or (H > upper_bound_j) then behaves as a COPY-LITERAL
instruction, taking the position operand set j := j + 1.
Then go back to be the last memory
address reached Step 2, unless j > n in which case decompression
failure occurs.

6. Copy (H + uncompressed_j - lower_bound_j) modulo 2^16 to the above step.

Price, Hannu, et al. [Page 30] 44]

INTERNET-DRAFT SigComp March 1, 2002

9.3. Program flow instructions Signaling Compression 2002-05-06

memory address specified by the destination operand.

9.4.5. STATE-ACCESS

The following instructions alter 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 flow location of UDVM code. Each
instruction jumps the partial state identifier used to one of a number of memory addresses based on a
certain specified criterion. Note that all of retrieve
the instructions give state information. This identifier has the memory addresses same function as the
partial state identifier transmitted in the form 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
more than one state item matches the partial identifier, or if
partial_identifier_length is less than the minimum_access_length of deltas relative to
the memory
address matched state item. Otherwise, a state item is returned from the
state handler.

If any of the instruction. The actual memory address operands state_address, state_instruction or
state_length is calculated
as follows:

memory_address = (memory_address_of_instruction + delta) modulo 2^16

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 set to 0 then its value is taken from the specified memory
address.

JUMP (%delta) returned
item of state instead.

Note that if when calculating the address (specified as a delta number of UDVM cycles the STATE-ACCESS
instruction costs (1 + state_length) cycles. The value of
state_length MUST be taken from the address returned item of state in the JUMP instruction) lies beyond
case that the overall UDVM memory size then
decompression failure occurs.

9.3.2. COMPARE state_length operand is set to 0.

The COMPARE instruction compares two state_begin and state_length operands define the starting byte
and then jumps to one number of three specified memory addresses depending on bytes to copy from the result.

COMPARE (%operand_1, %operand_2, %delta_1, %delta_2, %delta_3)

If operand_1 < operand_2 then state_value contained in the UDVM continues instruction
execution at
returned item of state. Decompression failure occurs if bytes are
copied from beyond the (relative) memory address specified by delta 1. If
operand_1 = operand_2 then it jumps to end of the address specified by
delta_2. If operand_1 > operand_2 then it jumps state_value. Note that
decompression failure will always occur if the state_length operand
is set to 0 but the address
specified by delta_3.

9.3.3. CALL and RETURN state_begin operand is non-zero.

The CALL and RETURN instructions provide support for compression
algorithms with state_address operand contains a nested structure.

CALL (%delta)

RETURN UDVM memory address. The CALL and RETURN instructions make use
requested portion of a stack the state_value is byte copied to this memory
address using the rules of 2-byte
variables stored 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 well-known
variable stack_location. The stack contains the next instruction following variables: the STATE-ACCESS
instruction. Note that the latter case only occurs if both the

Price, Hannu, et al. [Page 31] 45]

INTERNET-DRAFT SigComp March 1, 2002

Name: Starting memory address:

stack_free stack_location
stack[0] stack_location + 2
stack[1] stack_location + 4
stack[2] stack_location + 6
: :

The MSBs of these variables are stored before the LSBs in Signaling Compression 2002-05-06

state_instruction operand and the UDVM
memory.

When state_instruction value from the UDVM reaches a CALL instruction, it finds
requested state are set to 0.

9.4.6. STATE-CREATE

The STATE-CREATE instruction requests the memory address creation of a state item at
the instruction immediately following receiving endpoint.

STATE-CREATE (%state_length, %state_address, %state_instruction,
%minimum_access_length, %state_retention_priority)

Note that the CALL instruction and
copies this 2-byte value into stack[stack_free] ready for later
retrieval. It then increases stack_free new state item cannot be created until a valid
compartment identifier has been returned by 1 and continues the application.
Consequently, when a STATE-CREATE instruction execution at is encountered the (relative) memory address specified by UDVM
simply buffers the operand.

When five supplied operands until the UDVM reaches a RETURN instruction it decreases stack_free by
1, and then continues END-MESSAGE
instruction execution is reached. The steps taken at the byte position
stored this point are described
in stack[stack_free].

If Section 9.4.9.

Decompression failure must occur if more than four state creation
requests are made before the variable stack_free END-MESSAGE instruction is ever increased beyond 65535 or
decreased below 0 then a bad compressed message has been received and
decompression failure occurs (see Section 8.2). encountered.
Decompression failure also occurs if one of the above instructions is
encountered 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 value of stack_location is smaller than 6 (this
prevents receiving endpoint that the stack from overwriting
sender no longer wishes to use a particular state item.

STATE-FREE (%partial_identifier_start, %partial_identifier_length)

Note that the well-known variables).

9.3.4. SWITCH

The SWITCH STATE-FREE instruction performs does not automatically delete a conditional jump based on
state item, but instead reclaims the value
of one of its operands.

SWITCH (#n, %j, %delta_0, %delta_1, ... , %delta_n-1)

When memory taken by the state item
within a SWITCH 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 reads
simply buffers the value of
j. It then continues two supplied operands until the END-MESSAGE
instruction execution is reached. The steps taken at this point are described
in Section 9.4.9.

Decompression failure must occur if more than 4 state free requests
are made before the (relative) address
specified by delta j.

If j specifies a value of n or more, a bad compressed message has
been received and decompression END-MESSAGE instruction is encountered.
Decompression failure occurs.

9.3.5. CRC also occurs if partial_identifier_length does
not lie between 6 and 20 inclusive.

9.4.8. OUTPUT

The CRC OUTPUT instruction verifies a string of bytes using a 2-byte CRC.

CRC (%value, %position, %length, %delta) provides successfully decompressed data to the

Price, Hannu, et al. [Page 32] 46]

INTERNET-DRAFT SigComp March 1, 2002

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

Important note: Since a CRC calculation is always performed over a
bitstream, for interoperability it is necessary to Signaling Compression 2002-05-06

dispatcher.

OUTPUT (%output_start, %output_length)

The operands define the order
in which bits are supplied within each individual byte. In this case
the MSBs starting memory address and length of the
byte MUST string to be supplied provided to the CRC calculation before dispatcher. Note that the LSBs.

The value operand contains OUTPUT
instruction can be used to output a partially decompressed message;
each time the expected integer value of instruction is encountered it provides a new byte
string that the 2-byte
CRC. If dispatcher appends to the calculated CRC matches end of any bytes previously
passed to the expected value then dispatcher via the OUTPUT instruction.

The string of data is byte copied from the UDVM
continues memory obeying the
rules of Section 8.4.

Decompression failure occurs if the cumulative number of bytes
provided to the dispatcher exceeds 65536 bytes.

Since there is technically a difference between outputting a 0-byte
decompressed message, and not outputting a decompressed message at
all, the following instruction. Otherwise OUTPUT instruction needs to distinguish between the two
cases. Thus, if the UDVM jumps 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 (relative) memory address specified by delta.

9.4. I/O instructions dispatcher, then it is
considered to have outputted a 0-byte decompressed message.

9.4.9. END-MESSAGE

The following instructions allow END-MESSAGE instruction successfully terminates the UDVM and
forwards the state creation and state free requests to interface the state
handler together with its
environment. Note that in 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 overall SigComp architecture all of
these interfaces pass to END-MESSAGE instruction is encountered, the decompressor
dispatcher or indicates to the state
handler.

9.4.1. END-MESSAGE application that a complete message has
been decompressed. The END-MESSAGE instruction successfully terminates application may return a compartment
identifier, which the UDVM and
passes state information forwards to the state handler.

END-MESSAGE (%hash_length, %state_start, %state_length,
%state_instruction, %announcement_location)

Note that handler together
with the state creation and state free requests and any supplied
feedback data.

The actual uncompressed decompressed message is outputted separately using the
OUTPUT instruction; this conserves memory at the UDVM because there
is no need to buffer an entire uncompressed decompressed message before it can be
passed to the dispatcher.

Note that if the announcement_location operand is set to 0 then no
announcement information is provided, otherwise it points to the
starting memory address of the announcement information as per
Section 6.3.

Price, Hannu, et al. [Page 47]

INTERNET-DRAFT Signaling Compression 2002-05-06

The END-MESSAGE instruction requests the creation of state using the
operands state start and may pass up to four state length, which together denote a byte
string state_value. Provided that the application gives permission,
state_value is byte copied from the UDVM memory (obeying the rules of
Section 7.3) creation
requests and stored together with a 16-byte up to four state identifier that
can be used free requests to access the state by a later compressed message.

Price, Hannu, et al. [Page 33]

INTERNET-DRAFT SigComp March 1, 2002

To provide security against malicious access, handler. The
requests are passed to the identifier for any
item of state created by handler in the UDVM same order as they
are made; in particular it is derived from the [MD5] hash of possible for the state_value to be stored. The state identifier is constructed by
taking the 16-byte [MD5] hash creation
requests and replacing all but the first
hash_length most significant bytes with zeroes. Note that if
hash_length is 16 then the unmodified [MD5] hash is the state
identifier. Decompression failure occurs if hash_length is less than
the application-defined parameter minimum_hash_size or greater than
16.

If a state identifier already exists (hash collision occurs), the
decompressor should check whether the requested state is identical state free requests to be interleaved.

The state creation requests are made by the established state, and count STATE-CREATE instruction.
Note however that the END-MESSAGE can make one state creation request as
successful if this is
itself using the case. 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 is unsuccessful. The existing
state MUST NOT be replaced with of its own
(however decompression failure does not occur and the requested state to be saved. This
is to avoid creation
requests made by the situation where a compressed message cannot be
decompressed because STATE-CREATE instruction are still valid).

Note that there is a needed item maximum limit of four state has been replaced
(possibly by a malicious sender).

9.4.2. DECOMPRESSION-FAILURE

The DECOMPRESSION-FAILURE instruction triggers a manual creation requests
per instance of the UDVM. Therefore, decompression
failure. This is useful failure occurs if
the UDVM program discovers that it cannot
successfully decompress the message (e.g. by using the CRC
instruction).

This instruction has no operands.

9.4.3. OUTPUT

The OUTPUT END-MESSAGE instruction provides successfully decompressed data to the
dispatcher.

OUTPUT (%output_start, %output_length)

The operands define the starting memory address makes a state creation request and length four
instances of the
byte string to be provided to the dispatcher. Note that the OUTPUT STATE-CREATE instruction can be used to output have already been
encountered.

When creating a partially decompressed message;
each time the instruction is encountered state item it appends a byte string is necessary to give the end of the data previously passed to state_length,
state address, state_instruction and minimum_access_length; these are
supplied as operands in the dispatcher via STATE-CREATE instruction (or the
OUTPUT instruction. 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 data is byte copied state_length bytes from the UDVM
memory obeying beginning at state_address (obeying the rules of Section 7.3.

Decompression failure occurs if 8.4).
This is the cumulative number of bytes
provided to state_value.

The UDVM then calculates a 20-byte SHA-1 hash [PUB-180-1] over the dispatcher exceeds
byte string formed by concatenating the application-defined parameter
maximum_uncompressed_size.

Price, Hannu, et al. [Page 34]

INTERNET-DRAFT SigComp March 1, 2002

Since there is technically a difference between outputting a 0-byte
decompressed message, 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 outputting a decompressed message at
all, part of the OUTPUT instruction needs to distinguish between state item itself,
but instead determines the two
cases. Thus, if order in which state will be deleted when
the UDVM terminates before encountering compartment exceeds its allocated state memory. The
state_retention_priority is supplied as an OUTPUT operand in the STATE-
CREATE or END-MESSAGE instruction it and is considered not passed to have outputted 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 decompressed
message. partial state
identifier from the UDVM memory. If it encounters one no state item matching the

Price, Hannu, et al. [Page 48]

INTERNET-DRAFT Signaling Compression 2002-05-06

partial state identifier can be found or if more OUTPUT instructions, each of
which provides 0 bytes of data to than one state item
in the dispatcher, compartment matches the partial state identifier then it the
state free request is
considered ignored (this does not cause decompression
failure to have outputted a 0-byte decompressed message.

9.4.4. NBO

The NBO instruction modifies occur). Otherwise, the order in which compressed bits are
passed to state handler frees the UDVM. matched
state item as specified in Section 6.2.

As well as forwarding the INPUT-FIXED state creation and INPUT-HUFFMAN instructions read individual
bits from within a byte, to avoid ambiguity it is necessary state free requests, the
END-MESSAGE instruction may also pass feedback data to define the order in which these bits are read. The default operation state
handler. Feedback data is used to
read inform the MSBs before receiving endpoint about
the LSBs, but if capabilities of the NBO instruction is
encountered then sending endpoint, which can help to improve
the LSBs are read before overall compression ratio and to reduce the MSBs. Both cases working memory
requirements of the endpoints.

Two types of feedback data are
illustrated below:

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

Default operation After NBO instruction available: requested feedback and
returned feedback. The NBO instruction format of the requested feedback data is given
in Figure 12. As outlined in Section 3.2, the requested feedback data
can only be used before bitwise compressed data
is passed to influence the UDVM. Therefore, contents of the returned feedback data
in the reverse direction.

The returned feedback data is itself subdivided into a decompression failure occurs if
it returned
feedback item and a list of returned SigComp parameters. The returned
feedback item is encountered after an INPUT-FIXED or an INPUT-HUFFMAN
instruction has been used.

9.4.5. INPUT-BYTECODE of sufficient importance to warrant its own field in
the SigComp header as described in Section 7.1. The INPUT-BYTECODE instruction requests a certain number returned SigComp
parameters are illustrated in Figure 13.

Note that the formats of bytes Figure 12 and Figure 13 are only for local
presentation of
compressed the feedback data from on the dispatcher.

INPUT-BYTECODE (%length, %destination, %delta)

The length operand indicates interface between the requested number of bytes of
compressed data, UDVM
and state handler. The formats do not mandate any bits on the destination operand specifies wire;
the starting
memory address to which they should be copied. Byte copying compressor can transmit the data in any form provided that it is
performed as per
loaded into the rules of Section 7.3.

If UDVM memory at the instruction requests data correct addresses.

Moreover, the responsibility for ensuring that feedback data arrives
successfully over an unreliable transport lies beyond with the end 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
compressed message, requested_feedback_location operand is set to 0 then no data
feedback request is returned. Instead made; otherwise it points to the UDVM moves 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
| |

Price, Hannu, et al. [Page 35] 49]

INTERNET-DRAFT SigComp March 1, 2002

program execution to the memory address specified by the formula
(memory_address_of_INPUT-BYTECODE_instruction + delta) modulo 2^16.

The INPUT-BYTECODE instruction can only be used before bitwise
compressed Signaling Compression 2002-05-06

+---+---+---+---+---+---+---+---+

Figure 12: Format of requested feedback data is passed to the UDVM. Therefore, a decompression
failure occurs if it is encountered after an INPUT-FIXED or an INPUT-
HUFFMAN instruction has been used.

9.4.6. INPUT-FIXED

The INPUT-FIXED instruction requests a certain number of reserved bits may be used in future versions of
compressed data from SigComp, and are
set to 0 in Version 0x01. Non-zero values should be ignored by the dispatcher.

INPUT-FIXED (%length, %destination, %delta)
receiving endpoint.

The length operand Q-bit indicates the requested number of bits. If this
operand does not lie between 1 and 16 inclusive then whether a decompression
failure occurs. requested feedback item is present or
not. The destination operand specifies compressor can set the memory address requested feedback item to an
arbitrary value, which the
compressed data should will then be copied. Note that transmitted unmodified in the requested bits are
interpreted
reverse direction as a 2-byte integer ranging from 0 to 2^length - 1. Under
default operation the MSBs of this integer are provided first, but if
an NBO instruction has been executed then the LSBs are provided
first.

If the instruction requests data that lies beyond the end returned feedback item. See Chapter 5 for
further details of how the
compressed message, no data requested feedback item is returned. Instead

The format of the UDVM moves
program execution requested feedback item is identical to the memory address specified by the formula
(memory_address_of_INPUT-FIXED_instruction + delta) modulo 2^16.

9.4.7. INPUT-HUFFMAN

The INPUT-HUFFMAN instruction requests a variable number of bits format
of
compressed data from the dispatcher. returned feedback item illustrated in Figure 4.

The instruction initially
requests a small number of bits and compares compressor sets the result against a
certain criterion; S-bit to 1 if the criterion is it does not met then additional bits
are requested until wish (or no longer
wishes) to save state information at 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:

INPUT-HUFFMAN (%destination, %delta, #n, %bits_1, %lower_bound_1,
%upper_bound_1, %uncompressed_1, ... , %bits_n, %lower_bound_n,
%upper_bound_n, %uncompressed_n)

Note receiving endpoint and also
does not wish to access state information that it has previously
saved. Consequently, if n = 0 then the INPUT-HUFFMAN instruction S-bit is ignored by
the UDVM. If bits_1 = 0 or (bits_1 + ... + bits_n) > 16 set to 1 then
decompression failure occurs.

Price, Hannu, et al. [Page 36]

INTERNET-DRAFT SigComp March 1, 2002

In all other cases, the behavior of receiving
endpoint can reclaim the INPUT-HUFFMAN instruction is
defined below:

1.) Set j = 1.

2.) Request an additional bits_j compressed bits. Interpret state memory allocated to the
total (bits_1 + ... + bits_j) bits of compressed data requested so
far as an integer H, with remote
compressor and set the first bit to be supplied as state_memory_size for the MSB compartment to 0.

The compressor may change its mind and switch the last bit S-bit back to be supplied as 0 in
a later message. However, the LSB (note that this receiving endpoint is always under no
obligation to use the
case, independently of whether original state_memory_size for the NBO instruction has been used).

3.) If data is requested that lies beyond compartment;
it may choose to allocate less memory to the end 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 compressed
message, terminate locally available state items
offered by the INPUT-HUFFMAN instruction and move program
execution 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 address specified 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 formula
(memory_address_of_INPUT-HUFFMAN_instruction + delta) modulo 2^16.

4.) receiving
endpoint unless they are subsequently re-announced.

If (H < lower_bound_j) or (H > upper_bound_j) then the returned_parameters_location operand is set j = j +
1. Then go back to Step 2, unless j > n in which case decompression
failure occurs.

5.) Copy (H + uncompressed_j - lower_bound_j) modulo 2^16 0 then no
SigComp parameters are returned; otherwise it points to the starting
memory address specified by of the destination operand.

9.4.8. STATE-REFERENCE

The STATE-REFERENCE instruction retrieves some previously stored
state information.

STATE-REFERENCE (%id_start, %id_length, %state_start, %state_length,
%state_destination) returned parameters as shown in Figure 13.

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+

Price, Hannu, et al. [Page 50]

INTERNET-DRAFT Signaling Compression 2002-05-06

| 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 id_start first byte encodes the SigComp parameters cycles_per_bit,
decompression_memory_size and id_length operands specify state_memory_size as per Section 3.3.1.
The byte can be set to 0 if the location of three parameters are not included in
the state
identifier used feedback data. (This may be useful to retrieve save bits in the state information. The state
identifier is always 16 bytes long;
compressed message, if id_length is less than 16 then
the remaining least significant bytes of the identifier are padded
with zeroes.

Decompression failure occurs if id_length remote endpoint is greater than 16.
Decompression failure also occurs if no state information matching
the state identifier can be found.

Note that when accessing state already satisfied all
necessary information that has been previously
created by the UDVM, reached the state identifier is always taken from an
[MD5] hash of endpoint receiving the state to be retrieved. However this is not
necessarily
message.)

The second byte encodes the case for application-defined state SigComp_version as per Section
3.2.

The state_start and state_length operands define 3.3.2.
Similar to the starting first byte, the second byte
and number of bytes can be set to copy from 0 if the state_value contained
parameter is not included in the
identified item feedback data.

The remaining bytes encode a list of state. If more partial state is requested than is actually identifiers for
the locally available then decompression failure occurs.

Price, Hannu, et al. [Page 37]

INTERNET-DRAFT SigComp March 1, 2002

The state_destination operand contains a UDVM memory address. The
requested state is byte copied to this memory address using items offered by the rules
of Section 7.3.

9.4.9. STATE-EXECUTE

The STATE-EXECUTE instruction retrieves and runs some previously
stored sending endpoint.
Each state information.

STATE-EXECUTE (%id_start, %id_length)

The id_start and id_length operands function item is encoded as per a 1-byte length field, followed by a
partial state identifier containing as many bytes as indicated in the STATE-
REFERENCE instruction.

STATE-EXECUTE is similar
length field. The sender can choose to STATE-REQUEST except that send as few as 6 bytes if it does not
require the amount of state being requested or the proposed
destination
believes that this is sufficient for the state receiver to be specified explicitly. Instead, it
simply puts the state_value back into the UDVM memory using the
operands state_start and state_length contained as part of the determine which
state
information. item is being offered.

The entire state_value (all state length bytes list of it) state identifiers is terminated by a byte copied
into in the memory address specified by state start. The UDVM then jumps
to position
where the (absolute) memory address specified by state_instruction.

Note that state start, state next length and state_instruction are all
stored together with state_value as part of an item 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 state
information. data after the final length field.

10. Security considerations

Price, Hannu, et al. [Page 51]

INTERNET-DRAFT Signaling Compression 2002-05-06

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 protocols, application, as it always can be circumvented by
not using compression. More specifically, the high-level security
goals can be described as:

-- do

1. Do not worsen security of existing application protocol

-- do

2. Do not create any new security issues

-- do

3. Do not hinder deployment of application security

Price, Hannu, et al. [Page 38]

INTERNET-DRAFT SigComp March 1, 2002

10.2. Security risks and mitigations mitigation

This subsection section identifies the potential security risks associated with the overall SigComp architecture,
SigComp, and details the proposed
solution for explains how each risk.

** risk is minimized by the scheme.

10.2.1. Confidentiality risks

***

- Attacking SigComp by snooping into state of other users users:

State can only be is accessed using by supplying a state identifier, which is a
(prefix of a)
cryptographic hash of the state being referenced. This implies that
the referencing packet message already needs knowledge about the state. To
enforce this, a reference length state item cannot be accessed without supplying a
minimum of 72 48 bits is defined. 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 state
referenced,
referenced state, so no new vulnerability results.

The application

An endpoint needs to handle state identifiers with the same care it
would handle the state itself.

10.2.2. Integrity risks

The SigComp approach assumes that there is appropriate integrity
protection below and/or above the SigComp layer. However, the The state
establishment creation
mechanism provides some additional potential to compromise the
integrity of the messages (which, however, messages; however this would most likely be
detectable at the application layer).

*** layer.

Price, Hannu, et al. [Page 52]

INTERNET-DRAFT Signaling Compression 2002-05-06

- Attacking SigComp by faking state or making unauthorized changes to state
state:

State cannot be destroyed or changed 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 add new state. 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 (avoid (avoiding DoS vulnerabilities)

***

- Use of SigComp as a tool in a DoS attack to another target 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 packet message is then handed to the application; the utility
as a reflection amplifier is therefore limited by the utility of the
application.
application for this purpose.

However, it must be noted that SigComp can be used to generate larger
packets
messages as input to the application than have to be sent from the

Price, Hannu, et al. [Page 39]

INTERNET-DRAFT SigComp March 1, 2002
malicious sender; this therefore can send smaller packets 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.
***

- Attacking SigComp as the DoS target by filling it with state 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 adding making use of feedback at the application level
that indicates whether the state requested was actually installed -- This -
this allows a system under attack to gracefully degrade by no longer
installing compressor system under attack to gracefully degrade by no longer
installing compressor state that is not matched by application state.

Price, Hannu, et al. [Page 53]

INTERNET-DRAFT Signaling Compression 2002-05-06

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 matched 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 application state.

*** using TLS in
appropriate configurations).

- Attacking the UDVM by faking state or making unauthorized changes
to state

(See "Integrity risks" above.)

*** state:

This is covered in Section 10.2.2.

- Attacking the UDVM by sending it looping code code:

The application sets an upper limit to the number of "CPU "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 CPU UDVM cycles are offered by the UDVM.
However, this would be true for any decompressor that can receive
packets from anywhere. over an unsecured transport.

11. IANA considerations

The

SigComp solution currently requires two identifiers a 1-byte name space, the SigComp_version, to be
assigned
created by IANA: the UDVM_version and the state identifier. IANA. Upgraded versions of the UDVM will contain SigComp must be backwards-
compatible with version 0x01, described in this document. Adding
additional UDVM instructions and assigning values to
improve the performance of the overall SigComp solution; new
UDVM_version parameters will be needed in reserved
UDVM memory addresses are two possible upgrades for which this is the
case.

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

Price, Hannu, et al. [Page 40]

INTERNET-DRAFT SigComp March 1, 2002

Abigail Surtees (abigail.surtees@roke.co.uk)
Mark A West (mark.a.west@roke.co.uk)
Lawrence Conroy (lwc@roke.co.uk)

Price, Hannu, et al. [Page 54]

INTERNET-DRAFT Signaling Compression 2002-05-06

Christian Schmidt (christian.schmidt@icn.siemens.de)
Max Riegel (maximilian.riegel@icn.siemens.de)
Lars-Erik Jonsson (lars-erik.jonsson@epl.ericsson.se)
Stefan Forsgren (stefan.forsgren@epl.ericsson.se)
Krister Svanbro (krister.svanbro@epl.ericsson.se)
Miguel Garcia (miguel.a.garcia@ericsson.com)
Christopher Clanton (christopher.clanton@nokia.com)
Khiem Le (khiem.le@nokia.com)
Ka Cheong Leung (kacheong.leung@nokia.com)
Robert Sugar

for valuable input and review.

13. Authors' addresses

Richard Price Tel: +44 1794 833681
Email: richard.price@roke.co.uk

Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom

Hans Hannu Tel: +46 920 20 21 84
Email: hans.hannu@epl.ericsson.se

Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden

Carsten Bormann Tel: +49 421 218 7024
Email: cabo@tzi.org

Universitaet Bremen TZI
Postfach 330440
D-28334 Bremen, Germany

Jan Christoffersson Tel: +46 920 20 28 40
Email: jan.christoffersson@epl.ericsson.se

Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden

Price, Hannu, et al. [Page 41]

INTERNET-DRAFT SigComp March 1, 2002

Zhigang Liu Tel: +1 972 894-5935

Price, Hannu, et al. [Page 55]

INTERNET-DRAFT Signaling Compression 2002-05-06

Email: zhigang.liu@nokia.com

Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA

Jonathan Rosenberg
Email: jdrosen@dynamicsoft.com

dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936

14. References

[SIP] "SIP: Session Initiation Protocol", Handley

14.1. Normative References

[RFC-1662] "PPP in HDLC-like Framing", Simpson et al, Internet
Engineering Task Force, July 1994

[RFC-2119] "Key words for use in RFCs to Indicate Requirement
Levels", Scott Bradner, Internet Engineering Task Force,
March 1997

[PUB-180-1] "FIPS PUB 180-1: Secure Hash Standard", NIST, April 1995

14.2. Informative References

[RFC-1951] "DEFLATE Compressed Data Format Specification version
1.3", P. Deutsch, RFC 2543, 1951, Internet Engineering Task
Force, March 1999

[RTSP] May 1996

[RFC-2026] "The Internet Standards Process - Revision 3", Scott
Bradner, Internet Engineering Task Force, October 1996

[RFC-2279] "UTF-8, a transformation format of ISO 10646", F.
Yergeau, Internet Engineering Task Force, January 1998

[RFC-2326] "Real Time Streaming Protocol (RTSP)", H. Schulzrinne, A.
Rao and R. Lanphier, , RFC 2326, April 1998

[HTTP] "HyperText Transfer Protocol, HTTP/1.1", R. Fielding et
al.",

[RFC-2434] "Guidelines for Writing an IANA Considerations Section in
RFCs", H. Alvestrand and T. Narten, RFC 2616, June 1999

[SIPsrv] 2434, Internet
Engineering Task Force, October 1998

Price, Hannu, et al. [Page 56]

INTERNET-DRAFT Signaling Compression 2002-05-06

[RFC-2543] "SIP: Locating SIP Servers", J. Rosenberg, H.
Schulzrinne, draft-ietf-sip-srv-04.txt, January 2002,
work in progress

[DEFLATE] "DEFLATE Compressed Data Format Specification version
1.3", P. Deutsch, Session Initiation Protocol", Handley et al, RFC 1951,
2543, Internet Engineering Task Force, May 1996

[SCTP] March 1999

[RFC-2960] "Stream Control Transmission Protocol", Stewart et al, RFC
2960, Internet Engineering Task Force, October 2000

[MD5] "The MD5 Message-Digest Algorithm", R. Rivest, RFC 1321,
Internet Engineering Task Force, April 1992

[RFC-1662] "PPP in HDLC-like Framing", Simpson

[EXTENDED] "SigComp - Extended Operations", Hannu et al, Internet
Engineering Task Force, July 1994

[RFC-2026] "The Internet Standards Process - Revision 3", Scott
Bradner, Internet Engineering Task Force, October 1996

[RFC-2119] "Key words for use in RFCs to Indicate Requirement
Levels", Scott Bradner, Internet Engineering Task Force,
March 1997

Price, Hannu, et al. [Page 42]

INTERNET-DRAFT SigComp March 1, May 2002

Appendix A. Document history

- October 19, 2001, version 00

First version. The draft describes the current ideas, from people
involved in the ROHC WG, of how to perform compression of
application signaling messages.

- October 31, 2001, version 01

Second version. Additional section, 5.2.1, which describes when a
message identifier can be reused.

- November 21, 2001, version 02

Third version. Section 6 has been moved to a separate draft. The
third version describes a modular solution, providing flexibility
for implementers to decide which functions they want to integrate.

- January 28, 2002, version 03

Fourth version. SigComp version 02 is divided into this draft, a UDVM
draft and an extended operation mechanisms draft.
Compressor/decompressor (UDVM) state approach has been introduced for
security reasons.

- February 14, 2002, version 04

Fifth version. Describes the complete base SigComp solution including
the UDVM.

- March 1, 2002, version 05

Sixth version. Comments from several authors and contributors have
been taken into account. Announcement mechanism has been updated.

This Internet-Draft expires in September November 2002.

Price, Hannu, et al. [Page 43] 57]

----