WDIFF

draft-ietf-rohc-sigcomp-02.txt --> draft-ietf-rohc-sigcomp-03.txt

Network Working Group H. Hannu (Editor), Ericsson
INTERNET-DRAFT J. Christoffersson, Ericsson
Expires: May July 2002 C. Clanton, Nokia
S. Forsgren. Ericsson
K. Le, Nokia
K. Leung, Nokia
Z. Liu, Nokia
R. Price, Siemens/Roke Manor
J. Rosenberg, Dynamicsoft
K. Svanbro, Ericsson

November 21, 2001
January 28, 2002

Signaling Compression (SigComp)
draft-ietf-rohc-sigcomp-02.txt
<draft-ietf-rohc-sigcomp-03.txt>

Status of this memo

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

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

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

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

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

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

Hannu, et al. [Page 1]

INTERNET-DRAFT SigComp November 21 , 2001

Abstract

The Session Initiation Protocol (SIP), along with many other
protocols used

This document defines one out of two parts for multimedia communications, such as RTSP, are
textual protocols engineered a basic solution for bandwidth rich links. With the
planned usage of these protocols in wireless handsets
compressing messages generated by protocols, such as part of 2.5G SIP, called
SigComp. The architecture and 3G cellular networks, the large size pre-requisites of their messages and SigComp is outlined,
along with the
chatty nature format of the protocols are problematic.

This document provides a modular, robust and efficient message
compression scheme, suitable for compression of ASCII based
protocols' messages. SigComp message.

Hannu, et al. [Page 1]

INTERNET-DRAFT SigComp January 28 , 2002

0. Document History

- October 19, 2001, version 00

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

- October 31, 2001, version 01

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

- November 21, 2001, version 02

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

- January 28, 2002, version 03

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

Table of contents

1. Introduction..................................................3
2. Terminology...................................................3
3. High-level description of SigComp.............................4
4. The SigComp protocol..........................................5 Architecture......................................5
4. Applicability of SigComp......................................6
5. SigComp operation.............................................6
5.1. Pre-requisites..............................................6
5.2. Compression Framework Component...............................9 states..........................................7
5.3. Saving and deleting states..................................7
6. Capability exchange...........................................13 SigComp message...............................................8
7. Security considerations.......................................14 Capability exchange...........................................8
8. IANA considerations...........................................14 Security considerations......................................10
9. Authors' addresses............................................14 IANA considerations..........................................10
10. Intellectual Property Right Considerations....................16 Acknowledgements.............................................10
11. References....................................................16 AuthorsÆ addresses...........................................10
12. References...................................................12

Hannu, et al. [Page 2]

INTERNET-DRAFT SigComp November 21 January 28 , 2001 2002

1. Introduction

The Session Initiation Protocol (SIP) [SIP], along with many other
application protocols used for multimedia communications, such as
RTSP [RTSP], are textual protocols engineered for bandwidth rich
links. As a result, these messages have not been optimized for
message size. Typical SIP messages are from a few hundred bytes to as
high as 2000. To date, this has not been a significant problem.
With the planned usage of these protocols in wireless handsets as
part of 2.5G and 3G cellular networks, the large size of these
messages is problematic. The problem is not bandwidth efficiency (the
media stream still consumes the majority of the bandwidth), but
rather latency. With low-rate IP connectivity, store-and-forward store-and-
forward delays are significant. For CDMA2000, for example, the basic channel
will support only 9.6 kbps. At this rate, transmission of each byte
requires 0.8ms. A 500 byte SIP message requires nearly half a second
to transmit. Taking into account retransmits, and
the multiplicity of messages that are required in some flows, call
setup and feature invocation are adversely affected. Therefore, we
believe there is a merit in investigating ways to reduce reducing these message sizes.

This document defines SigComp, a modular, robust and efficient
message compression scheme, even when the transport path between the
compressor and decompressor is unreliable, i.e. prone to errors,
losses and misordering.

From the view of external users, SigComp is only to provide
compression service. What you get is the The service provided is that of the underlying
transport + plus compression. Nothing more. Nothing less.

SigComp consists of a compression component

This document outline the architecture and a protocol component.
The protocol component should not be "extracted" out pre-requisites of SigComp,
along with the contents format of this document for other purpose. the SigComp message.

This document does not specify a negotiation or capability exchange
mechanism. The application that would like to apply applies SigComp should also negotiate
the usage of SigComp. SigComp including capability exchange.

Compression/decompression algorithms functionality for SigComp is
provided by [UDVM].

2. Terminology

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

Byte buffer

Universal Decompressor Virtual Machine (UDVM)

The decompressor virtual machine described in [UDVM]. The UDVM is used by for
decompression of SigComp maintains messages. The UDVM is capable of
interoperating with a byte buffer, which
depending on the implementation choice, contain any previously
received text strings that might be useful wide range of compression algorithms.

Decompressor

The decompressor invokes the UDVM. It is responsible for future compression. supplying
the UDVM with compressed data and make decompressed data available
for the application.

Hannu, et al. [Page 3]

INTERNET-DRAFT SigComp November 21 January 28 , 2001

Context

The context of SigComp is the necessary information 2002

Encoder

Encodes data according to perform
compression and decompression. a (compression) algorithm into UDVM
readable code. The correct context to use is
identified encoded data can be decoded by the IP Source and Destination addresses.

3. High-level description of SigComp

Compression and decompression is performed at two communicating end-
points, A and B, see Figure 1. When a message is to be compressed UDVM provided
with the
compressing entity looks up needed instructions.

Compressor

The compressor invokes the IP source and destination addresses encoder, and identifies keeps track of states that
can be used for compression. Responsible for supplying UDVM
instructions to the correct context peer decompressor in order for compressed
data to use. If no context exists, one
is created. Depending on be decompressed.

State

Data saved either by a compressor or a decompressor. The data
reflects the implementation contents of the SigComp
compressing entity the protocol might add a header UDVM memory.

State index

Reference to a state saved either by a compressor or a
decompressor.

Application

Invokes the output of
the compressor. The final SigComp compressor and decompressor.

SigComp message is then passed on to
underlying layers for transport to the decompressing entity.

Upon the arrival

In case of a SigComp message the SigComp decompressing
entity will, if no context exists create one. If the oriented transport mechanism, such as UDP, a
SigComp message
carries corresponds to exactly one (UDP) packet. For a header it removes the header and takes the appropriate
actions (which depends on the implementation of the decompressing
entity), then it gives the remaining
stream oriented transport, such as TCP, each SigComp message is
separated by a 0xFFFF delimiter, see [UDVM].

Application data (message)

Data, also referred to as input message, which is to be
compressed by the
decompressor. After a correct decompression compressor. When delivered from the uncompressed message
will be decompressor
the data has passed on to through the receiver.

original +------------------+ decompression process and is
referred to as decompressed data or decompressed message.

Hannu, et al. [Page 4]

INTERNET-DRAFT SigComp January 28 , 2002

3. The SigComp Architecture

Compression and decompression is performed at two communicating end-
points, see Figure 1.

+--------------------+ +--------------------+
message
| +----------+ Compressor 1 | message | +------------+ Decompressor 1 |
------------+>|Compressor|-- - + - - - - - -+>|Decompressor|-----+->
| +-----|----+ +---------+ | | +---------+ | +----|-------+
| | +---|---+ Encoder | | +---|---+ | | |Context| UDVM | | |Context|
| +---------+ | +---+---+ | +---------+ | +---+---+
+--------------------+ +--------------------+
^ App. ^ | ^ | +---+---+ App. ^
| data | +---+---+ | | |Context| v data |
+----|-------------|-+ +-|-------------|----+
| |Context| |
decompressed | +---|---+ | SigComp | +---|---+ | | |
| | Application v | message | +-----|--------+ | Application | |
| v +---------->----------+ v |
| +-------+ | | +-------+ |
| | State | | Data transport | | State | |
| +-------+ | | +-------+ |
| ^ +----------<----------+ ^ |
| | | | SigComp | ^ | |
| | | | message | +----|-----------+ |
<------------+-| | |
+----|-------------|-+ +-|-------------|----+
| App. ^ | | | App. |
v data | v | v data v
+--------------------+ +--------------------+
| Decompressor |<+- - - - - - +-| 2 | | Compressor |<+-- 2 |
| +---------+ | | +---------+ |
| | UDVM | | | +--------------+ | Encoder | +----------------+ |
+------------------+
| +---------+ | | +---------+ |
+--------------------+ +--------------------+
A B

Figure 1. SigComp High-level view.

Note: There

The different components in the SigComp architecture are described
below.

The application is no need responsible for one uncompressed message to correspond to
exactly one compressed message. Two or more compressed messages can
be sent to reconstruct a single uncompressed message, which invoking the SigComp compressor
and decompressor, and establish the applicability of SigComp between
two communicating end points.

The compressor is useful responsible for segmenting compressed messages that are larger than providing its peer decompressor
with the MTU UDVM instructions for decompression of messages. For the transport protocol, see [ALG].
actual compression it invokes the encoder. The compressor also keeps
track of available states, that may contain useful information for
the compression process.
The decompressor contains the UDVM, and is responsible for providing
it with input.

Hannu, et al. [Page 4] 5]

INTERNET-DRAFT SigComp November 21 January 28 , 2001

4. The SigComp protocol

The main task of the SigComp protocol 2002

A state is to provide feedback from the
decompressor to its peer compressor. The amount of feedback
information and how the data saved either by a compressor react to or a decompressor. The
data reflects the feedback are choices contents of the implementation. An implementation a UDVM memory. The saved state may also choose not to
implement any feedback mechanisms.

For the purpose of feedback, SigComp has be
used for decompression/compression between a set of headers, as defined compressor and its peer
decompressor, e.g. compressor 1 and decompressor 1 in Section 4.1. Figure 1. The use of headers
same state information is established at the capability
exchange phase, see Section 6. The acknowledgment procedure in
Section 4.2 together with the headers MAY be used by a decompressing
entity to provide knowledge both for compression and
decompression. In order to retrieve a certain state its reference
must be given, denoted state index.
State parameters and retrieval of states are further described in
[UDVM].

4. Applicability of SigComp

The application is responsible for establishing the compressing entity about what applicability of
SigComp messages it has received. between the communicating end points.

This would allow involves finding out the compressor transport (e.g. UDP or TCP) and port to
use previously sent messages for SigComp messages.

[Editors note: This should be further described in draft XXXX]

The parameters for the compression process, even when UDVM operation should be exchanged/negotiated
together with the underlying transport protocol is unreliable, see parameters in Section 7.

[Editors note: This should be further described in draft XXXX]

4.1. The SigComp headers operation

The SigComp headers consist of application provides the following fields:

Message IDentification (MID) number compressor with data to be compressed.
The MID number data is used to keep track of sent and received
messages, and compressed by the encoder in such away that the peer
decompressor with the UDVM can decompress the data correctly if the
compressed data is useful for detecting not tampered with during the transportation.

When a message loss and/or
misordering.

CRC-verification of messages (CRC-M)

This CRC is calculated over to be compressed the uncompressed message, e.g. compressor identifies the SIP
INVITE message, and
state to use. If no state exists, one is created. An indication of
the used state MUST be sent along with the compressed message to verify the correctness of a
decompressed SigComp message.

Acknowledgement

A SigComp acknowledgement can either be carried within a
peer decompressor. The SigComp message (Piggybacked) or be sent by itself (Standalone).

Note: It is assumed that then passed on to
underlying layers for transport to the total length peer decompressor.
Upon the arrival of a SigComp message is
provided by the underlying transport layer. Since decompressor will load the length of
UDVM with the
header part indicated state. The message is self-contained then decompressed by
the length of the compressed
information can be derived by subtracting the header length from the
total SigComp message length. The compressed information length could
be zero in the case of a Standalone acknowledgement.
Header formats are described in the following sub-sections.

Hannu, et al. [Page 5]

INTERNET-DRAFT SigComp November 21 , 2001

4.1.1. Normal header formats

These are the normal header formats to use. Format 1 SHOULD be used
when there has been no gap in the received MID numbers up to the
generation of this SigComp message. To acknowledge received SigComp
messages after a gap in the received MID numbers, Format 2 MUST be
used

Format 1

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MID | Cumulative ACK|
+---+---+---+---+---+---+---+---+
| CRC-M |
+---+---+---+---+---+---+---+---+
/ Compressed information /
/ according to Section 5 /
+---+---+---+---+---+---+---+---+

Format 2

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | MID |
+---+---+---+---+---+---+---+---+
| CRC-M |
+---+---+---+---+---+---+---+---+
| AC | RMID (1) |
+---+---+---+---+---+---+---+---+
| RMID (2) | RMID (3) |
+---+---+---+---+---+---+---+---+
: :
/ /
: :
+---+---+---+---+---+---+---+---+
| RMID (C-1) | RMID (C) |
+---+---+---+---+---+---+---+---+
/ Compressed information /
/ according to Section 5 /
+---+---+---+---+---+---+---+---+

MID: "0000" to "1101".

The Message IDentification (MID) number is commonly increased with
one for each sent message. However, there is the exception when
the next MID to be assigned is not "free", see Section 4.2.1.

Hannu, et al. [Page 6]

INTERNET-DRAFT SigComp November 21 , 2001

Cumulative ACK

Acknowledges all SigComp messages with MID number equal to or less
than the value of this field. The value of this field MUST NOT be
set to a value so that non-received SigComp messages are
acknowledged. A received acknowledgement with higher value than
the maximum MID MUST be ignored and MUST NOT be considered as an
acknowledgement for SigComp messages.

CRC-M

TBW

RMID

Received MID of a SigComp message, which is being acknowledged.

Number of received SigComp message being acknowledged (RMID),
which are included in the List. If AC is an even number the last
RMID, RMID(C), is only padding, in order to get octet aligned.

4.1.2. Extended message formats

Format 3

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 | TBD |
+---+---+---+---+ +
/ TBD /
: :
/ /
+---+---+---+---+---+---+---+---+

Note: The usage of this format is yet to be determined.
(Decompressing failure etc.)

4.2. Acknowledgement procedure

The acknowledgement procedure is dependent on the information carried
in the SigComp headers. It is RECOMMENDED that all SigComp messages
are acknowledged.

Three functions are needed:

- A function that holds the received MID-numbers which should be
acknowledged.

Hannu, et al. [Page 7]

INTERNET-DRAFT SigComp November 21 , 2001

- A function that keeps a mapping between sent MID numbers and
acknowledged MID numbers.

- A function that controls which MID numbers that an entity is
allowed to use.

It is up to the implementation to realize these functions

The acknowledgement procedure is best described using an example, see
Figure 3.

A B
| |
Step (0) |<----------- MID 1B ----------|
| |
Step (1) |-------- MID 1A, ACK 1B ---->|
| |
Step (2) |<--------MID 2B, ACK 1A ------|
| |

Figure 3. Example of the acknowledgement procedure.

Step (0): A SigComp message with Message IDenitifcation number 1 is
sent from B to A, denoted MID 1B in Figure 3. MID 1B MUST be
acknowledged by A until A is confident that B knows that MID 1B is
received.

Step (1): Entity A acknowledges MID 1B with SigComp message MID 1A. A
mapping between MID 1A and MID 1B is stored at A. Note that MID 1A do
not have to carry compressed information, it can be a Standalone
Acknowledgement.

Step (2): Entity B acknowledges MID 1A and stores a mapping between
MID 2B and MID 1A. When Entity A receives MID 2B it uses the mapping
to find out which SigComp message(s) from B was acknowledged by MID
1A. The mapping is removed and MID 1B MUST NOT be acknowledged
anymore.

4.2.1. Reuse of Message IDentification numbers

This section describe when a MID can be reused to avoid
misinterpretations in case of wraparound of MID numbers combined with
message loss and/or misordering.

A MID number MUST NOT be reused until the SigComp message with that
particular MID number has been acknowledged and stopped being
acknowledged, or that the message can be regarded as lost.

Hannu, et al. [Page 8]

INTERNET-DRAFT SigComp November 21 , 2001

Figure 4, is a continuation of the example given in Figure 3. The
Figure depicts an example when it is allowed to reuse a MID number
that has been acknowledged and stopped being acknowledged.

Figure 4. Continuation of Figure 3.

Step (3): When Entity B receives an acknowledgement for MID 2B it
knows that the mapping for MID 1B is removed at A. Therefore it
is safe for entity B to reuse MID 1B.

A message can be regarded as lost, if the SigComp entity has received
acknowledgments for higher MID numbers than the MID number the entity
wishes to reuse. However, as SigComp must stand against moderate
misordering according to [REQ], a MID number X MUST NOT be regarded
as lost until an acknowledgement for message(s) with MID numbers >
(X+2) has been received.

5. Compression Framework Component

SigComp uses the "Universal Decompression Algorithm" described in
[ALG] for the actual compression. The "universal decompressor" is
capable of interoperating with a wide range of compression
algorithms. It is the compressor which decides what information that
is stored in the dictionary of the decompressor. The compressor also
controls how the decompressor performs the decompression.

This section describes various features that a SigComp implementation
may use to improve the compression efficiency. Some of these feature
requires additional entries in the byte buffer of the "universal
decompressor".

5.1. Pre-population

A compressor MAY pre-populate the dictionary with well-known
information (text-strings), in order to increase the compression
efficiency. This is a rather simple approach with the "universal
decompressor", see [ALG].

5.2. Per-message compression

Compressing a message without any relation to any other message is
referred to as per-message compression. Per-message compression can
be used regardless of the reliability of the underlying transport and

Hannu, et al. [Page 9]

INTERNET-DRAFT SigComp November 21 , 2001

the usage of the SigComp headers, as it is not dependent on any
previously transmitted messages. To get compression of messages at
all, this is the approach which all implementations of SigComp MUST
support.

Implementation support for the features in the following sections is
optional.

5.3. Dynamic compression

A compressing entity MAY choose to use previously sent messages in
the compression process in an attempt to improve the compression
efficiency. This is referred to as dynamic compression. To ensure
reliable operation of the compression algorithm a compressor MUST NOT
use dynamic compression, unless it is certain of that the message it
is about to compress can be decompressed by the decompressor. If
SigComp is used over reliable transport, such as TCP, dynamic
compression does not introduce any robustness problem. To withhold
robustness over unreliable transport, such as UDP, the SigComp
acknowledgement procedure MUST be used when dynamic compression is
applied. Thus, a previously sent message MUST NOT be used in the
compression process until it has been acknowledged. Referring to
Figure 3, B MAY use information in 1B to improve the compression
efficiency of the message corresponding to 2B.

5.4. Shared compression

Shared compression is referred to the case when a compressor 'A' make
use of decompressed messages received by the decompressor located at
the same SigComp entity. These decompressed messages MUST originate
from the corresponding SigComp entity, which decompressor is
controlled by compressor 'A'. Shared compression is OPTIONAL and its
support is established in the capability exchange.

To allow shared compression it is REQUIRED to use the SigComp
acknowledgment procedure regardless of the reliability of the
underlying transport.

Referring to Figure 3, B MAY use information in 1A to improve the
compression efficiency of the message corresponding to 2B.

For shared compression to be applicable with the "universal
decompressor" a SigComp entity supporting shared compression MUST
implement two additional entries in the byte buffer of the
decompressor:

shared_start

This is the start address in the byte buffer where original

Hannu, et al. [Page 10]

INTERNET-DRAFT SigComp November 21 , 2001

messages (not compressed) from this entity, which are being
acknowledged, are to be placed into the byte buffer of the
decompressor. By setting shared_start = 0, a compressor can
avoid that any acknowledged message is written to the byte buffer.

shared_length

This is used by the protocol part to inform the decompressor
algorithm if there was any new information, UDVM, and the length of it,
written possible passed on to the shared compression part of the byte buffer. To
avoid that same message information is processed twice, in case of
multiple acknowledges for one message, the protocol MUST set
shared_length = 0.

Figure 5. depicts a logical view of the decompressor byte buffer at a
SigComp entity which supports shared compression.

Figure 5. Logical view of the decompressor byte buffer. receiving application.

5.1. Pre-requisites

A and B are the addresses which circular_buffer and shared_start
point to. The received circular buffer will compressor MUST be between
circular_buffer and shared_start-1. When the decompressing SigComp
entity receives a SigComp message containing acknowledgements for
e.g. MID-2 and MID-3 it will copy the original messages
corresponding to MID-2 and MID-3 to the decompressor buffer at the
address specified in shared_start.

5.4.1. Specification of ordering constraints

Inconsistency in the dynamic context data can happen if the context
is shared and messages, which will update the dynamic context data,
are sent concurrently by both entities. The approach to deal with
this problem is to specify ordering constraints of all update
messages sent by both entities so that the order is total and the
same at both entities, at least for the eligible updates. Three rules
are defined; local, causality and concurrent rule. With the first two
rules and the use of the 3-way handshake, it is possible to ensure
consistency during updates of dynamic context data, but there is one
case that these do not resolve; dynamic context data updates issued
concurrently by both entities.

With an update request in the description of the rules below means;
Every message that carries information certain that is used to update the
dynamic context data.

Hannu, et al. [Page 11]

INTERNET-DRAFT SigComp November 21 , 2001

Local Rule

When a dynamic context compressed data update request R' is sent can be decompressed
before R" at the same entity, R' data is scheduled to perform an update before R" at
both entities. A sending entity schedules its own update requests
according to their sequence numbers, whereas a receiving entity
schedules these requests according to be sent, i.e. the request sequence
numbers, which can UDVM instructions for
decompression MUST be inferred from available at the sequence numbers of those peer decompressor. Some
options exists:

Hannu, et al. [Page 6]

INTERNET-DRAFT SigComp messages containing these requests.

Causality rule

When a January 28 , 2002

1. Each SigComp message containing a dynamic context data update
request R' piggybacks with acknowledgements, R' is scheduled to
perform an update after all the updates corresponding to sent from the
acknowledged update requests.

Concurrent rule

The problem explained above can be eliminated by requiring compressor contains the
maintenance of a total order relationship
necessary UDVM instructions for decompression.

2. By setting up a sequence of all
known context update requests at each entity. This requires that
one entity is reliable connection, such as a TCP connection,
between a compressor and its peer decompressor the master UDVM
instructions can be transferred, and one an initial state is the slave.

An example showing how the scheme with the total
established.

In order relationship
solves the inconsistent context update problem is shown in Figure 6.
Suppose all messages exchanged between Entity X (a master entity) and
Entity Y (a slave entity) are employed to save delay for subsequent
compression/decompression, and all received messages are acknowledged
and piggybacked in all subsequent messages "time-critical" sessions, the UDVM
instructions should be sent by prior to any initiation of "time-
critical" sessions.

5.2. Compression states

The UDVM may request the receiver.
Whenever concurrent dictionary updates are happened, update requests
initiated from decompressor to save the master entity are ordered first. For example, contents of its
memory, i.e. request that a state is created based on the
update requests for Messages 1, 2, and 3 are ordered before those for
Messages 101, 102, and 103 respectively information
in the list of UDVM memory. If a UDVM will perform such a request depends on
the total
order relationship instructions sent from its peer compressor. See [UDVM] for
details on how a request to save a sequence state is performed.

The kind of dictionary updates (TOL).
DD information, which is included in a logical representation of the Dynamic Context Data, TSS state, is up to the logical representation
implementation of sent SigComp messages the compressor and TRS is the
logical representation storage of received SigComp messages.

Since downloaded instructions to
the update request for Message 1 is ordered before peer decompressor's UDVM. However, as said in Section 5.1. a
compressor MUST not use a state that for
Message 101 according is not known to be established
at the total order relationship, the update
request peer decompressor.

5.3. Saving and deleting states

Saving states

If there already exists a state for Message 101 at Entity Y a state index, then this state
MUST not be replaced with the requested state to be saved. This is
to avoid that a compressed message cannot be decompressed because
its state has been replaced.

Deleting states

A decompressor SHOULD NOT delete a state before it is blocked until enough
confident that for Message
1 becomes ready to be moved, as indicated by the reception state is not used by a peer compressor anymore.

[Editors note: I think some rules are needed to handle deletion of the
acknowledgement piggybacked with Message 3.

| |
DD = {} | | DD = {}
TSS = {1} | | TSS = {101}
TRS = {} | | TRS = {}
TOL = {1} | | TOL = {}
| [1] [101] |
states]

Hannu, et al. [Page 12] 7]

INTERNET-DRAFT SigComp November 21 January 28 , 2001

|-----------\ /-----------|
| \/ |
| /\ |
|<----------/ \---------->|
| |
DD = {} | | DD = {}
TSS = {1, 2} | | TSS = {101, 102}
TRS = {101} | | TRS = {1}
TOL = {1, 101, 2} | | TOL = {1}
| [2] [102] |
|-----------\ /-----------|
| \/ |
| /\ |
|<----------/ \---------->|
| |
DD = {1} | | DD = {}
TSS = {2, 3} | | TSS = {101 - 103}
TRS = {101, 102} | | TRS = {1, 2}
TOL = {101, 2002

6. SigComp message

The basic SigComp message consist of compressed data, a reference to
the state the decompressor should initialize its UDVM with, and
possible also a CRC. Figure 2, shows a basic SigComp message.

A decompressor must be able to separate two SigComp messages, in case
of UDP a SigComp message corresponds exactly to one UDP packet. For
TCP each 0xFFFF delimiter, see [UDVM] is followed by a new SigComp
message.

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| i | TOL = {1, 101, 2}
102, 3} | |
| [3] [103] |
|-----------\ /-----------|
| \/ | c | /\ Reserved |
|<----------/ \---------->|
+---+---+---+---+---+---+---+---+
| |
DD = {1, 101, 2}
: state_index (n-bytes) : Present if 'i' is set
| | DD = {1, 101}
TSS = {3}
+---+---+---+---+---+---+---+---+
| | TSS = {102, 103}
TRS = {102, 103}
: CRC : Present if 'c' is set
| | TRS = {2, 3}
TOL = {102,3,103}
+---+---+---+---+---+---+---+---+
| Possible | TOL = {2, 102, 3}
: Compressed data that should :
| be given as input to the UDVM |

CD Entity X CD Entity Y
+---+---+---+---+---+---+---+---+

Figure 6. An Example 2. Basic SigComp message

The CRC is calculated over the uncompressed message.

The reserved bits are set to zero by the compressor.

In case a decompressor encounters that the Reserved bits are not all
zeros, it should remove m-bytes from the SigComp message following
the CRC according to:

m-bytes = (bit(2) + bit(3)) * n.

For the value of Proposed Scheme with Total Order Relationship
for Dynamic Context Data Updates.

6. n see Section 7.

7. Capability exchange

Before two

Applications that use SigComp entities start to send compressed messages between
them, they MUST agree on the capabilities they will
intend to use. This section
does not specify how to perform involves exchange/negotiation of the exchange, but preferably it
should be conducted at parameters
below, see also [UDVM]. Preferably the negotiation exchange of applying SigComp.

Buffer size

The available byte buffer size parameters is done
simultaneously with the negotiation of the decompressor MUST be
exchanged. applicability of SigComp.
Consider also Section 5.1.

Hannu, et al. [Page 13] 8]

INTERNET-DRAFT SigComp November 21 January 28 , 2001

SigComp headers

Only 2002

CRC

Two CRCs are available to use with SigComp.
CRC_1: C(x) = 1 + x + x^2 + x^8
CRC_2: C(x) = 1 + x^5 + x^12 + x^16
[Editors note: is it feasible (for implementation) to provide two
CRCs in the case when both SigComp entities indicate spec?]

For the use parameters below consult also [UDVM].

maximum_compressed_size

The maximum_compressed_size parameter limits the size of
headers, one
compressed message.

maximum_uncompressed_size

The maximum_uncompressed_size parameter limits the SigComp protocol MUST add a SigComp header size of one
uncompressed message.

minimum_hash_size (n-bytes)

The minimum_hash_size parameter specifies the minimum size of the
state index that can be used to reference state. This corresponds
to the
compressor output. In any other case n in n-bytes.

overall_memory_size

The overall_memory_size parameter specifies the protocol MUST NOT add total number of
bytes in the UDVM memory.

working_memory_start

The working_memory_start parameter specifies the start of the UDVM
memory area that can be modified. Memory addresses below this value
are considered read-only by the UDVM.

working_memory_end

The working_memory_end parameter specifies the end of the UDVM
memory area that can be modified. Memory addresses above this value
are considered read-only by the UDVM.

cycles_per_bit

The cycles_per_bit parameter specifies the number of "CPU cycles"
that can be used to decompress a
header.

Shared compression

If single bit of data. One CPU cycle
typically corresponds to a single UDVM instruction, although some
of the high-level instructions may require additional cycles.

Hannu, et al. [Page 9]

INTERNET-DRAFT SigComp entity supports shared compression it MAY indicate
that. However, shared compression January 28 , 2002

cycles_per_message

The cycles_per_message parameter specifies the number of additional
CPU cycles made available at the start of a compressed message.
These cycles can only be used in combination useful when decompressing algorithms that
download additional data on a per-message basis, for example a new
set of Huffman codes as with SigComp headers. A SigComp entity is not required to use
shared compression even if it [DEFLATE].

The total number of "CPU cycles" available for each compressed
message is supported specified by the corresponding
entity.

CPU power

TBW

7. following formula:

total_cycles = message_size * cycles_per_bit + cycles_per_message

first_instruction

The first_instruction parameter specifies the memory address of the
first instruction to be executed when the UDVM is initialized.

8. Security considerations

TBW

[Editors note: TBW]

9. IANA considerations

TBW

9. Authors'

[Editors note: TBW]

10. Acknowledgements

[Editors note: TBW]

11. AuthorsÆ addresses

Hans Hannu, Editor
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 84
Fax: +46 920 20 20 99
EMail:
E-Mail: hans.hannu@epl.ericsson.se

Jan Christoffersson
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 28 40
Fax: +46 920 20 20 99
EMail:
E-Mail: jan.christoffersson@epl.ericsson.se

Stefan Forsgren
Phone: +46 920 20 23 39
Fax: +46 920 20 20 99
E-Mail: stefan.forsgren@epl.ericsson.se

Hannu, et al. [Page 14] 10]

INTERNET-DRAFT SigComp November 21 January 28 , 2001

Christopher Clanton
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA 2002

Krister Svanbro
Phone: +1 972 894-4886 +46 920 20 20 77
Fax: +1 972 894-4589
E-mail: christopher.clanton@nokia.com

Stefan Forsgren +46 920 20 20 99
E-Mail: krister.svanbro@epl.ericsson.se

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

Christopher Clanton
Phone: +46 920 20 23 39 +1 972 894-4886
Fax: +46 920 20 20 99
EMail: stefan.forsgren@epl.ericsson.se +1 972 894-4589
E-mail: christopher.clanton@nokia.com

Khiem Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4882
Fax: +1 972 894-4589
E-mail: khiem.le@nokia.com

Ka Cheong Leung
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374-0630
Fax: +1 972 894-4589
E-mail: kacheong.leung@nokia.com

Zhigang Liu
2-700
Mobile Networks Laboratory
Phone: +1 972 894-5935
Fax: +1 972 894-4589
E-Mail: zhigang.liu@nokia.com

Nokia Research Center
6000 Connection Drive Irving, TX 75039, USA

Phone: +1 972 894-5935
Fax: +1 972 894-4589

Hannu, et al. [Page 15]

INTERNET-DRAFT SigComp November 21 , 2001

EMail: zhigang.liu@nokia.com

Richard Price
Phone: +44 1794 833681
E-mail: richard.price@roke.co.uk

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

Phone: +44 1794 833681
Email: richard.price@roke.co.uk

Jonathan Rosenberg
E-mail: jdrosen@dynamicsoft.com

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

Email: jdrosen@dynamicsoft.com

Krister Svanbro
Box 920
Ericsson Erisoft AB
SE-971

Hannu, et al. [Page 11]

INTERNET-DRAFT SigComp January 28 Lulea, Sweden

Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
EMail: krister.svanbro@epl.ericsson.se

10. Intellectual Property Right Considerations

The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.

11. , 2002

12. References

[ALG] R. Price et. al., Universal Decompression Algorithm,
Internet Draft (work in progress), November 2001.
<draft-ietf-rohc-sigcomp-algorithm-00.txt>

[DEFLATE] "DEFLATE Compressed Data Format Specification version
1.3", RFC 1951, P. Deutsch, May 1996 1996.

[UDVM] R. Price et. al., Universal Decompressor Virtual Machine
(UDVM), Internet Draft (work in progress), January 2002.
<draft-ietf-rohc-sigcomp-udvm-00.txt>

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

Hannu, et al. [Page 16]

INTERNET-DRAFT SigComp November 21 , 2001

[REQ] H. Hannu (Editor), Signaling Compression Requirements &
Assumptions, Internet Draft (work in progress),November
2001. <draft-ietf-rohc-signaling-req-assump-03.txt>

[SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg,
SIP: Session Initiation Protocol, RFC 2543, August 2000.

This Internet-Draft expires in May July 2002.

Hannu, et al. [Page 17] 12]

----