WDIFF

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

Network Working Group H. Hannu (Editor), Ericsson
INTERNET-DRAFT Z. Liu, Nokia
Expires: April 2002 R. Price, Siemens/Roke Manor
J. Rosenberg, Dynamicsoft J. Christoffersson, Ericsson
Expires: May 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

October 31,

November 21, 2001

Signaling Compression (SigComp)
draft-ietf-rohc-sigcomp-01.txt
draft-ietf-rohc-sigcomp-02.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, Liu, Price, Rosenberg, et al. [Page 1]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

Abstract

The Session Initiation Protocol (SIP), along with many other IP
protocols used for multimedia communications, such as RTSP, are
textual protocols engineered for bandwidth rich links. With the
planned usage of these protocols in wireless handsets as part of 2.5G
and 3G wireless, cellular networks, the large size of these their messages is and the
chatty nature of the protocols are problematic.

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

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.

TABLE OF CONTENTS

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

Table of contents

1. Introduction..................................................3
2. Terminology...................................................3
3. High-level description........................................3 description of SigComp.............................4
4. The SigComp Components............................................6 protocol..........................................5
5. Protocol Component............................................6

6. Compression Framework Component...............................12 Component...............................9
6. Capability exchange...........................................13
7. Security considerations.......................................21 considerations.......................................14
8. IANA considerations...........................................21 considerations...........................................14
9. Authors addresses.............................................22 Authors' addresses............................................14
10. Intellectual Property Right Considerations....................22 Considerations....................16
11. References....................................................22 References....................................................16

Hannu, Liu, Price, Rosenberg, et al. [Page 2]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

1. Introduction

The Session Initiation Protocol (SIP) [SIP], along with many other IP
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 wireless, 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
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
merit in investigating improvements in ways to reduce message sizes.

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

From the view of external users, SigComp fulfills is only to provide
compression service. What you get is the requirements stated in [REQ] service of the underlying
transport + compression. Nothing more. Nothing less.

SigComp consists of a compression component and a protocol component.
The protocol component should not be "extracted" out of the contents
of this document for other purpose.

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

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

The SigComp decompressor used by SigComp maintains a byte buffer containing buffer, which
depending on the implementation choice, contain any previously
received text strings that might be useful for future compression.

Token

A token is an instruction transmitted from the compressor to the
decompressor.

3. High-level description

SigComp is useful for compression of ASCII-based application
signaling protocol messages. Compression and decompression is
performed at two points, e-net and e-ms, see Figure 1. The compressor
uses the context to compress a message to a SigComp message. The

Hannu, Liu, Price, Rosenberg, et al. [Page 3]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

reverse process is done at the decompressor.

Context

The context of SigComp is defined as the information necessary information to perform
compression and decompression. The correct context to use is
identified by the IP Source and Destination addresses addresses.

3. High-level description of the IP header. By using this
identification method there SigComp

Compression and decompression is performed at two communicating end-
points, A and B, see Figure 1. When a message is no need to add an explicit be compressed the
compressing entity looks up the IP source and destination addresses
and identifies the correct context
identifier in to use. If no context exists, one
is created. Depending on the implementation of the SigComp message.
To improve
compressing entity the compression efficiency, protocol might add a header to the output of
the compressor. The final SigComp uses previous messages
in message is then passed on to
underlying layers for transport to the compression/decompression process decompressing entity.

Upon the arrival of later message. To be
robust against a SigComp message the SigComp decompressing
entity will, if no context inconsistency in this process, exists create one. If the SigComp has an
internal acknowledgement scheme. message
carries 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 SigComp message as input to the
decompressor. After a correct decompression the uncompressed message
will be passed on to the receiver.

original +------------------+ SigComp +--------------------+
| +--------------+ | | +----------------+ |
| | Context | | | | Context | |
| +--------------+ | | +----------------+ |
| | | | | | | |
original | | | | compressed | | | |
message | +----------+ | | message | +------------+ | |
------------+>|Compressor|-)
------------+>|Compressor|-- - + - - - - - -+>|Decompressor|-)---+-> -+>|Decompressor|-----+->
| +----------+ +-----|----+ | | +----|-------+ | +------------+
| +---|---+ | | +---|---+ |
| |Context| | | |Context| |
decompressed
| +---+---+ | | compressed +---+---+ |
| +---+---+ | | +---+---+ |
| |Context| | | |Context| |
decompressed | +---|---+ | SigComp | +---|---+ |
message | +--------------+ +-----|--------+ | message | +----------------+ +----|-----------+ |
<------------+-| Decompressor |<+- - - - - - +-| Compressor |<+--
| +--------------+ | | +----------------+ |
+------------------+ +--------------------+
E-ms E-net
A B

Figure 1. SigComp High-level view.

Although Figure 1. implies that the context

Note: There is shared between
compressor and decompressor located in the same entity, this must not
necessarily be the case. SigComp no need for one uncompressed message to correspond to
exactly one compressed message. Two or more compressed messages can
be applied in an environment
where shared context is not possible or unwanted, with just one
change: The context is identified by the IP-source and IP-destination
address pair. Thus, if the IP-source and IP-destination addresses
would switch, it will generate sent to reconstruct a new context.
However, it single uncompressed message, which is recommended useful
for segmenting compressed messages that SigComp is used with shared context
because of are larger than the increase in compression ratio this gives.

3.1. Context data

The Context MTU of SigComp is defined as the information necessary to
perform compression and decompression. The context at compressor and
the corresponding decompressor must be kept consistent. The context
is built up by the parts described in
the following subsections. transport protocol, see [ALG].

Hannu, Liu, Price, Rosenberg, et al. [Page 4]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

3.1.1. Static Context Data

4. The context SigComp protocol

The main task of the SigComp protocol is populated with static information to use in provide feedback from the compression/decompression process, i.e. static context data.
decompressor to its peer compressor. The
static amount of feedback
information comes from knowing what protocols are and how the compressor react to be
compressed. Information such as protocol-specific header field names,
Methods, Status codes etc. the feedback are typical static context data. It does
not change over time, is relevant for all users choices
of SigComp, and can
be applied the implementation. An implementation may also choose not to all sessions. Thus,
implement any feedback mechanisms.

For the purpose of feedback, SigComp has a set of headers, as defined
in Section 4.1. The use of headers is established at least the static context data
can capability
exchange phase, see Section 6. The acknowledgment procedure in
Section 4.2 together with the headers MAY be applied when compressing messages.

3.1.2. User specific Context Data

To further increase used by a decompressing
entity to provide knowledge to the compression efficiency compressing entity about what
SigComp messages it has received. This would allow the
possibility compressor to pre-populate the context with information useful
use previously sent messages in the compression process. This type of information process, even when
the underlying transport protocol is regarded as user
specific context data as it unreliable, see Section 5.

4.1. The SigComp headers

The SigComp headers consist of the following fields:

Message IDentification (MID) number

The MID number is not defined within SigComp.
Information about commonly used connections, such as SIP URLs to keep track of sent and
appliction settings (speech codecs, etc) are typical examples received
messages, and is useful for detecting message loss and/or
misordering.

CRC-verification of user
specific context data.

Note: How pre-population messages (CRC-M)

This CRC is performed calculated over the uncompressed message, e.g. the SIP
INVITE message, and is yet used to verify the correctness of a
decompressed SigComp message.

Acknowledgement

A SigComp acknowledgement can either be determined.

3.1.3. Dynamic Context Data

Messages associated with protocols such as SIP tend to have similar
characteristics carried within a session. Therefore SigComp makes use of
messages
message (Piggybacked) or be sent from/to by itself (Standalone).

Note: It is assumed that the total length of a user. To be able to decompress SigComp
messages correctly, information in previous messages must not be used
in message is
provided by the compression process until underlying transport layer. Since the message(s) has been
acknowledged. This part length of the context
header part is referred to as self-contained the dynamic
context data part.

3.1.4. Cross session Context

The messages also have similar characteristics between sessions. The
idea is to take advantage length of this with Cross session context.
Basically this means that the context is kept between sessions, e.g.
between two SIP INVITES.

Note: How to utilize Cross Session Context is yet to compressed
information can be determined.

3.1.5. Keeping Context

TBW. 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, Liu, Price, Rosenberg, et al. [Page 5]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

4. SigComp Components

The SigComp compression scheme is divided into two components,
Protocol and Compression framework component. Basically,

4.1.1. Normal header formats

These are the protocol
component sees normal header formats to that use. Format 1 SHOULD be used
when there has been no gap in the contexts are consistent even for a certain
amount received MID numbers up to the
generation of message loss and misordering and also make it possible to
use previously sent and this SigComp message. To acknowledge received message SigComp
messages after a gap in the
compression/decompression of later messages. The compression
framework component defines the structure of the part of the context
that is received MID numbers, Format 2 MUST be
used in the compression/decompression process and what

Format 1

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MID | Cumulative ACK|
+---+---+---+---+---+---+---+---+
| CRC-M |
+---+---+---+---+---+---+---+---+
/ Compressed information /
/ according to update the context with.
Figure Section 5 /
+---+---+---+---+---+---+---+---+

Format 2 depicts which parts of the SigComp message that relates to
which component.

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

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| SigComp Header 1 1 1 0 | * Protocol Component
+-----------------+ MID |
+---+---+---+---+---+---+---+---+
| CRC-M |
+---+---+---+---+---+---+---+---+
| AC | RMID (1) |
+---+---+---+---+---+---+---+---+
| RMID (2) | RMID (3) |
+---+---+---+---+---+---+---+---+
: Compressed : * Compression framework Component
/ /
: :
+---+---+---+---+---+---+---+---+
| information RMID (C-1) |
+-----------------+

Figure 2. SigComp 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.

5. Protocol Component

This chapter describes However, there is the protocol component 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 SigComp. this field. The protocol component include functions, such as value of this field MUST NOT be
set to a value so that non-received SigComp message messages are
acknowledged. A received acknowledgement scheme and context verification function.
The four main task that with higher value than
the protocol component performs are:

1) Process a message maximum MID MUST be ignored and sending it compressed, MUST NOT be considered as a an
acknowledgement for SigComp message.
2) Receiving messages.

CRC-M

TBW

RMID

Received MID of a SigComp message and pass it on uncompressed.
3) Acknowledge message, which is being acknowledged.

Number of received SigComp messages.
4) Receiving acknowledgements for SigComp messages.

The sections in this chapter describes functions that message being acknowledged (RMID),
which are needed for included in the SigComp protocol component List. If AC is an even number the last
RMID, RMID(C), is only padding, in order to perform its tasks.

5.1. SigComp header

To achieve robustness and keep track 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 sent and received messages, a
header this format is added yet to the compressed message. be determined.
(Decompressing failure etc.)

4.2. Acknowledgement procedure

The SigComp header consist
of acknowledgement procedure is dependent on the following fields:

* Message IDentification (MID) number: The MID number information carried
in the SigComp headers. It is used to keep
track of sent and RECOMMENDED that all SigComp messages
are acknowledged.

Three functions are needed:

- A function that holds the received messages, and is useful for detecting
message loss and/or misordering. MID-numbers which should be
acknowledged.

Hannu, Liu, Price, Rosenberg, et al. [Page 6] 7]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

* CRC-verification of messages (CRC-M): This CRC is calculated over
the uncompressed message, e.g. the SIP INVITE message, and is used to
verify the correctness of decompressed SigComp messages.

* Acknowledgement:

- A SigComp acknowledgement can either be carried
within function that keeps a SigComp message (Piggybacked) or be mapping between sent by itself
(Standalone).

Note: It is assumed MID numbers and
acknowledged MID numbers.

- A function that the total length of a SigComp message is
provided by the lower layer. Since the length of the header part controls which MID numbers that an entity is
self-contained the length of the compressed message 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.

Formats are described in the following sub-sections.

5.1.1 Normal message formats

These are the normal formats
allowed to use. Format 1 should be used when
there has been no gap in the received MID numbers

It is up to the
generation of this SigComp message. Format 2 should be used to
acknowledge received SigComp messages when there has been a gap in
the received MID numbers.

Format 1:

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

Format 2:

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ realize these functions

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

A B
| 1 1 1 0 |
Step (0) |<----------- MID 1B ----------|
|
+---+---+---+---+---+---+---+---+
| CRC-M |
+---+---+---+---+---+---+---+---+
| AC | RMID
Step (1) |-------- MID 1A, ACK 1B ---->|
|
+---+---+---+---+---+---+---+---+ | RMID
Step (2) |<--------MID 2B, ACK 1A ------|
| RMID (3) |
+---+---+---+---+---+---+---+---+
: :

Hannu, Liu, Price, Rosenberg, et al. [Page 7]

INTERNET-DRAFT

Figure 3. Example of the acknowledgement procedure.

Step (0): A SigComp October 31 , 2001

/ /
: :
+---+---+---+---+---+---+---+---+
| RMID (C-1) | RMID (C) |
+---+---+---+---+---+---+---+---+
/ Compressed message /
/ according to section 6 /
+---+---+---+---+---+---+---+---+

* MID: "0000" to "1101". The with Message IDentification (MID) IDenitifcation number 1 is
commonly increased with one for each
sent message. However, there is
the exception when the next MID from B to A, denoted MID 1B in Figure 3. MID 1B MUST be assigned
acknowledged by A until A is not "free", see
section X.

* Cumulative ACK: Acknowledges all SigComp messages confident that B knows that MID 1B is
received.

Step (1): Entity A acknowledges MID 1B with SigComp message MID number
equal 1A. A
mapping between MID 1A and MID 1B is stored at A. Note that MID 1A do
not have to or less than 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 value of this field. mapping
to find out which SigComp message(s) from B was acknowledged by MID
1A. The value mapping is removed and MID 1B MUST NOT be acknowledged
anymore.

4.2.1. Reuse of this
field must not Message IDentification numbers

This section describe when a MID can be set reused to a value so that non-received SigComp
messages are acknowledged. A received acknowledgement avoid
misinterpretations in case of wraparound of MID numbers combined with higher
value than the maximum
message loss and/or misordering.

A MID must number MUST NOT be ignored reused until the SigComp message with that
particular MID number has been acknowledged and not stopped being
acknowledged, or that the message can be regarded as
acknowledgement for SigComp messages.

* CRC-M: TBD

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

RMID: Received MID of a SigComp message, which are being
acknowledged.

5.1.2 Extended message formats

Format 3: Reserved.

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.

5.2. Acknowledgement procedure

There is one basic rule for the acknowledgement procedure: lost.

Hannu, Liu, Price, Rosenberg, et al. [Page 8]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

"All SigComp messages should be acknowledged".

Two functions are needed:
1) A mapping function between sending MID numbers and acknowledged
MID numbers, called MAPP-Function.

2) A function that keeps track of when a received SigComp MID number
is not to be acknowledged anymore, called TRACK-Function.

Figure 4, is up to the implementation to realize a continuation of the two functions.

The acknowledgement procedure is best described using an example, see example given in Figure 3. There is one purpose with the procedure:
"Make The
Figure depicts an example when it possible is allowed to use information in previous messages in the
compression and decompression process of future messages".

e-A e-B
| |
Step (0) |<----------- reuse a MID 1B ----------| number
that has been acknowledged and stopped being acknowledged.

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

Figure 3. Example 4. Continuation of the acknowledgement procedure.

Step (0): A SigComp message with Message IDenitifcation number 1 is
sent from e-B to e-A, denoted MID 1B in Figure 3.

Step (3): When Entity B receives an acknowledgement for MID 1B must be
acknowledged by e-A until e-A is positive that e-B 2B it
knows that MID 1B
is received.

Step (1): Entity e-A acknowledges MID 1B with SigComp message MID 1A.
A the mapping between MID 1A and for MID 1B is stored removed at e-A. Note that MID
1A do not have to carry compressed information, A. Therefore it
is safe for entity B to reuse MID 1B.

A message can be a
Standalone Acknowledgement.

Step (2): Entity e-B acknowledges MID 1A and stores a mapping between
MID 2B and regarded as lost, if the SigComp entity has received
acknowledgments for higher MID 1A. When Entity e-A receives numbers than the MID 2B it uses number the
mapping entity
wishes to find out which reuse. However, as SigComp message(s) from e-B was
acknowledged by MID 1A. The mapping is then removed and MID 1B does
not have must stand against moderate
misordering according to [REQ], a MID number X MUST NOT be acknowledged anymore.

To summarize:
When an entity is to generate regarded
as lost until an acknowledgement it for message(s) with MID numbers >
(X+2) has been received.

5. Compression Framework Component

SigComp uses the TRACK-
Function to find out the MID number it should acknowledge.
Upon "Universal Decompression Algorithm" described in
[ALG] for the reception actual compression. The "universal decompressor" is
capable of interoperating with a SigComp message the header wide range of compression
algorithms. It is scanned to find
the acknowledgements and the MAPP-Function compressor which decides what information that
is used to find out stored in the
corresponding received SigComp messages that do not have to be
acknowledged anymore.

Hannu, Liu, Price, Rosenberg, et al. [Page 9]

INTERNET-DRAFT SigComp October 31 , 2001

5.2.1. Reuse dictionary of Message IDentification numbers the decompressor. The compressor also
controls how the decompressor performs the decompression.

This section describe when a MID can be reused describes various features that a SigComp implementation
may use to avoid
misinterpretations in case improve the compression efficiency. Some of wraparound these feature
requires additional entries in the byte buffer of MID numbers combined the "universal
decompressor".

5.1. Pre-population

A compressor MAY pre-populate the dictionary with
message loss and/or misordering.

Basically well-known
information (text-strings), in order to increase the compression
efficiency. This is a MID number MUST not be reused until rather simple approach with the SigComp "universal
decompressor", see [ALG].

5.2. Per-message compression

Compressing a message
using that particular MID number has been acknowledged or that the without any relation to any other message is regarded
referred to as lost.

Figure 4 is a continuation per-message compression. Per-message compression can
be used regardless of Figure 3 the reliability of the underlying transport and depicts when it is ok to
reuse a MID number that has been acknowledged.

Figure 4. Continuation

Hannu, et al. [Page 9]

INTERNET-DRAFT SigComp November 21 , 2001

the usage of Figure 3.

Step (3): When Entity e-B receives an acknowledgement for MID 2B it
knows that the mapping for MID 1B SigComp headers, as it is removed not dependent on any
previously transmitted messages. To get compression of messages at e-A. Therefore it
all, this is safe for entity e-B to reuse MID 1B.

In the case approach which all implementations of MID number reuse when the previous message using that
MID number has not been acknowledged. Then SigComp MUST
support.

Implementation support for the previous message
should be regarded as lost, if features in the following sections is
optional.

5.3. Dynamic compression

A compressing entity has received
acknowledgments for higher MID numbers than MAY choose to use previously sent messages in
the MID number compression process in an attempt to improve the entity
wishes compression
efficiency. This is referred to reuse. However, as SigComp should stand against moderate
misordering according to [REQ], a MID number X should not be regarded
as lost until an acknowledgement for message(s) with MID numbers >
(X+2) has been received.

5.2.2. Specification dynamic compression. To ensure
reliable operation of ordering constraints

Inconsistency in the compression algorithm a compressor MUST NOT
use dynamic context data compression, unless it is certain of that the message it
is about to compress can happen if be decompressed by the context decompressor. If
SigComp is shared and messages, which will update 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 context data,
are compression is
applied. Thus, a previously sent concurrently by both entities. The approach message MUST NOT be used in the
compression process until it has been acknowledged. Referring to deal with
this problem
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 specify ordering constraints the case when a compressor 'A' make
use of all update decompressed messages sent received by both entities so that the order is total and the
same at both entities, decompressor located at least for
the eligible updates. Three rules
are defined, local, causality and concurrent rule. With same SigComp entity. These decompressed messages MUST originate
from the first two
rules 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 3-way handshake, it is possible reliability of the
underlying transport.

Referring to ensure
consistency during updates Figure 3, B MAY use information in 1A to improve the
compression efficiency 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 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 description byte buffer of the rules below means;
Every message that carries information that
decompressor:

shared_start

This is used to update the
dynamic context data. start address in the byte buffer where original

Hannu, Liu, Price, Rosenberg, et al. [Page 10]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

* Local Rule: When a dynamic context data update request R' is sent
before R" at the same

messages (not compressed) from this entity, R' 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 the request
sequence numbers, which can are being
acknowledged, are to be inferred from placed into the sequence numbers byte buffer of
those SigComp messages containing these requests.

* Causality rule: When the
decompressor. By setting shared_start = 0, a SigComp compressor can
avoid that any acknowledged message containing a dynamic
context data update request R' piggybacks with acknowledgements, R' is scheduled written to perform an update after all the updates corresponding byte buffer.

shared_length

This is used by the protocol part to inform the acknowledged update requests.

* Concurrent rule: The problem explained above can be eliminated by
requiring decompressor
algorithm if there was any new information, and the maintenance length of a total order relationship for a
sequence it,
written to the shared compression part of all known context update requests at each entity. This
requires the byte buffer. To
avoid that one entity same message information is the master and processed twice, in case of
multiple acknowledges for one is message, the slave.

An example showing how the scheme with the total order relationship
solves the inconsistent context update problem is shown in protocol MUST set
shared_length = 0.

Figure 5.
Suppose all 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.

A and
Entity Y (a slave entity) B are employed for subsequent
compression/decompression, the addresses which circular_buffer and all shared_start
point to. The received messages are acknowledged circular buffer will be between
circular_buffer and piggybacked in all subsequent messages sent by the receiver.
Whenever concurrent dictionary updates are happened, update requests
initiated from shared_start-1. When the master decompressing SigComp
entity are ordered first. For example, the
update requests receives a SigComp message containing acknowledgements for Messages 1, 2,
e.g. MID-2 and 3 are ordered before those for
Messages 101, 102, MID-3 it will copy the original messages
corresponding to MID-2 and 103 respectively in MID-3 to the list of decompressor buffer at the total
order relationship for a sequence of dictionary updates (TOL).
DD is a logical representation
address specified in shared_start.

5.4.1. Specification of ordering constraints

Inconsistency in the Dynamic Context Data, TSS dynamic context data can happen if the context
is shared and messages, which will update the logical representation of dynamic context data,
are sent SigComp messages and TRS concurrently by both entities. The approach to deal with
this problem is the
logical representation storage to specify ordering constraints of received SigComp messages.

Since the all update request for Message 1 is ordered before
messages sent by both entities so that for
Message 101 according to the total order relationship, the update
request for Message 101 at Entity Y is blocked until that for Message
1 becomes ready to be moved, as indicated by the reception of the
acknowledgement piggybacked with Message 3.

| |
DD = {} | | DD = {}
TSS = {1} | | TSS = {101}
TRS = {} | | TRS = {}
TOL = {1} | | TOL = {}
| [1] [101] |
|-----------\ /-----------|
| \/ |
| /\ |
|<----------/ \---------->|
| |

Hannu, Liu, Price, Rosenberg, et al. [Page 11]

INTERNET-DRAFT SigComp October 31 , 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, 2, | | TOL = {1, 101, 2}
102, 3} | |
| [3] [103] |
|-----------\ /-----------|
| \/ |
| /\ |
|<----------/ \---------->|
| |
DD = {1, 101, 2} | | DD = {1, 101}
TSS = {3} | | TSS = {102, 103}
TRS = {102, 103} | | TRS = {2, 3}
TOL = {102,3,103} | | TOL = {2, 102, 3}
| |

CD Entity X CD Entity Y

Figure 5. An Example of Proposed Scheme with Total Order Relationship
for Dynamic Context Data Updates.

6. Compression Framework Component

This chapter introduces a simple but flexible dictionary structure
for the SigComp compression scheme.

The goal with the flexible dictionary structure is to standardize a
decompressor capable of interoperating with a wide range of
compression algorithms. Consequently this chapter describes the
decompressor operation only, i.e. the actions which the decompressor
takes upon receiving a certain instruction from the compressor.

6.1. Information stored in the SigComp dictionary

An important feature of SigComp is that it offers a standard
decompressor which can interoperate with a wide range of compression
algorithms. The precise method for compression is left as an

Hannu, Liu, Price, Rosenberg, et al. [Page 12]

INTERNET-DRAFT SigComp October 31 , 2001

implementation decision, and in fact the standard decompressor can
interoperate with any of the following classes of algorithm:

* Generic text compressor (for example [DEFLATE] or a similar
algorithm)

* Protocol-aware compressor offering excellent performance for
one signaling protocol

* Hybrid compressor with similar performance to [DEFLATE] for
generic text strings and superior performance for certain
signaling protocols

The choice of which instructions to send to the decompressor are left
as a local implementation decision at the compressor. The only
requirement is that of transparency, i.e. the compressor MUST NOT
send instructions which cause the decompressor to incorrectly
decompress a given signaling message.

Note however that it is perfectly acceptable for the compressor to
send tokens which update the dictionary at the decompressor, but
which cause no decompressed message to be outputted. Indeed, this is
a useful technique for pre-populating the dictionary with well-known
text strings.

6.1.1. Structure of SigComp dictionary

The SigComp dictionary consists of a simple byte buffer designed to
hold the current uncompressed message, the current compressed
message, and any other previously received text strings that might be
useful for future compression.

The size buffer_size of the byte buffer is negotiated by an
externally defined mechanism (e.g. by the underlying SigComp protocol
used to transport the compressed messages, or alternatively by the
mechanism used to negotiate use of SigComp itself). Entries in the
byte buffer are referred to as buffer[n] where 0 =< n < buffer_size.

As all of the SigComp tokens currently use 2-byte indices into the
byte buffer, the maximum size of the buffer is 64K.

6.1.2. Important entries in the byte buffer

The first few bytes in the SigComp byte buffer are used to store some
important 2-byte integers. These integers are given the following
names:

Hannu, Liu, Price, Rosenberg, et al. [Page 13]

INTERNET-DRAFT SigComp October 31 , 2001

Position in buffer: Name:

0 - 1 first_token
2 - 3 compressed_start
4 - 5 compressed_length
6 - 7 uncompressed_start
8 - 9 uncompressed_length
10 - 11 circular_buffer
12 - 13 result_integer
14 - 15 stack_free
16 - 17 stack[0]
18 - 19 stack[1]
20 - 21 stack[2]
: :

The MSBs of the integer are always stored before the LSBs. So, for
example, the MSBs of first_token are stored in buffer[0] whilst the
LSBs are stored in buffer[1].

The use of each integer is described in the following sections of the
draft.

6.1.3. Decompressor actions upon receiving a SigComp message

When a SigComp context is initialized all entries in the byte buffer
are set to 0. Upon receiving a SigComp message, the decompressor
strips off the underlying protocol header and then performs the
following actions:

1.) The message is copied directly into the byte buffer beginning
at the byte specified in compressed_start. The length of the
compressed message in bytes (known from the underlying protocol used
to transport the compressed message) is then copied into
compressed_length.

Note that the buffer is circular, so once a byte is copied into
buffer[buffer_size - 1], the next byte is copied into
buffer[circular_buffer]. The parameter circular_buffer (see Section
3.2) can be set to prevent the first part of the buffer from being
overwritten by new compressed messages. Typically this area of the
buffer is used to hold important tokens and text strings that should
be kept from one compressed message to the next.

2.) Next, the tokens contained within the byte buffer are executed
beginning at the byte specified in first_token. The tokens are
executed consecutively unless indicated explicitly (for example when
the decompressor encounters a SWITCH token). If the byte
buffer[buffer_size - 1] is ever reached, the next byte is found in
buffer[circular_buffer].

Hannu, Liu, Price, Rosenberg, et al. [Page 14]

INTERNET-DRAFT SigComp October 31 , 2001

3.) When the decompressor reaches buffer[0], instead of executing
the token contained within buffer[0] it stops token execution and
outputs the uncompressed message. The location of the uncompressed
message is specified by uncompressed_start and uncompressed_length.

As stated before the buffer is circular, so once a byte is copied
from buffer[buffer_size - 1], the next byte is copied from
buffer[circular_buffer].
Note that the byte buffer is not reset between SigComp messages
unless explicitly requested by the underlying protocol.

Note also that if uncompressed_length is set to 0 then the
decompressor does not output an uncompressed message. This is very
useful for populating the byte buffer with well-known text strings,
before any actual decompression of signaling messages takes place.

6.1.4. Decompression failure

If the compressed messages received by the decompressor are corrupted
(either accidentally or maliciously) then one of three possibilities
might occur:

* A decompressed message is outputted that is incorrect.

* A token is encountered that cannot be processed successfully by
the decompressor (for example a RETURN token when no CALL token
has reviously been encountered).

* The decompressor never finishes decompressing a message.

To counter the first possibility the underlying protocol SHOULD
include a checksum to ensure that each message is decompressed
successfully. If the decompressed message fails the checksum then
"decompression failure" has occurred. The decompressor does not
output an uncompressed message, and ignores any future compressed
message except those which explicitly request the byte buffer to e
reinitialized.

If a token is encountered that cannot be successfully processed then
decompression failure occurs automatically.

To counter the third possibility, decompression failure SHOULD also
occur after a certain number of tokens have been processed for a
given compressed message. The maximum number of tokens to process is
currently left as an implementation decision (but might in future be
negotiated).

Hannu, Liu, Price, Rosenberg, et al. [Page 15]

INTERNET-DRAFT SigComp October 31 , 2001

6.2. Library of tokens

The SigComp decompressor currently understands seven types of token,
chosen to support the widest possible range of compression algorithms
with the minimum possible overhead.

All tokens are stored as a single byte to indicate the token type,
followed by 0 or more bytes containing the parameters required by the
token. The following token types are currently available:

COPY
ADD / SUBTRACT
LSHIFT / RSHIFT
COMPARE
SWITCH
CALL ... RETURN
HUFFMAN

Each token is explained in more detail below:

6.2.1. COPY

The COPY token instructs the decompressor to copy a string of bytes
from one part of the byte buffer to another.

A COPY token is stored in the byte buffer as 7 consecutive bytes as
described below. A simple mnemonic description of the COPY token is
also provided, which can be useful when writing example lists of
tokens to be transmitted within a compressed message.

Mnemonic description:

COPY (position, length, destination)

Exact byte description:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Position MSB | Position LSB | Length MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length LSB |Destination MSB|Destination LSB|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The meaning of the three parameters is explained below:

Position: 2-byte integer indicating the location of the first
byte in the string to be copied.

Length: 2-byte integer indicating the number of bytes to be

Hannu, Liu, Price, Rosenberg, et al. [Page 16]

INTERNET-DRAFT SigComp October 31 , 2001

copied.

Destination: 2-byte integer indicating the location to which the
first byte in the string will be copied.

Note that once a byte is copied into buffer[buffer_size - 1], the
next byte is copied into buffer[circular_buffer].

6.2.2. ADD / SUBTRACT

The ADD token instructs the decompressor to add the two 2-byte
integers at the specified locations in the byte buffer (addition
performed modulo 2^16) total and to store the result in the location of the
first integer.

ADD (index_1, index_2)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Index 1 MSB | Index 1 LSB | Index 2 MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+
| Index 2 LSB |
+-+-+-+-+-+-+-+-+

The SUBTRACT token is the
same as the ADD token except that the
second integer is subtracted from the first (subtraction performed
modulo 2^16).

SUBTRACT (index_1, index_2)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Index 1 MSB | Index 1 LSB | Index 2 MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+
| Index 2 LSB |
+-+-+-+-+-+-+-+-+

6.2.3. LSHIFT / RSHIFT

The LSHIFT token instructs the decompressor to left shift the 2-byte
integer at both entities, at least for the specified location. As always, the MSBs of the integer eligible updates. Three rules
are stored before the LSBs.

LSHIFT (index)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Index MSB | Index LSB |

Hannu, Liu, Price, Rosenberg, et al. [Page 17]

INTERNET-DRAFT SigComp October 31 , 2001

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

Note that the least significant bit of defined; local, causality and concurrent rule. With the integer becomes zero, first two
rules and the most significant bit is discarded.

The RSHIFT token performs a right shift use of the 2-byte integer at the
specified location.

RSHIFT (index)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Index MSB | Index LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.2.4. COMPARE

The COMPARE token instructs the decompressor 3-way handshake, it is possible to compare the two 2-
byte integers at the specified locations in the byte buffer.

COMPARE (index_1, index_2)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1| Index 1 MSB | Index 1 LSB | Index 2 MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+
| Index 2 LSB |
+-+-+-+-+-+-+-+-+

If the first integer referenced by the COMPARE token ensure
consistency during updates of dynamic context data, but there is less than the
second integer then the decompressor sets result_integer = 0. If one
case that these do not resolve; dynamic context data updates issued
concurrently by both
integers are equal then it sets result_integer = 1. If the first
integer is greater than entities.

With an update request in the second then description of the decompressor sets
result_integer = 2.

6.2.5. SWITCH

The SWITCH token performs a conditional jump based on rules below means;
Every message that carries information that is used to update the contents of
result_integer.

SWITCH (index_0, index_1, ... , index_n - 1)

Hannu, Liu, Price, Rosenberg, et al. [Page 18] 11]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

Local Rule

When a SWITCH token dynamic context data update request R' is sent before R" at
the same entity, R' is encountered, 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 the decompressor reads request sequence
numbers, which can be inferred from the
integer contained within result_integeer. Suppose that this integer sequence numbers of those
SigComp messages containing these requests.

Causality rule

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

Concurrent rule

The decompressor then continues token execution problem explained above can be eliminated by requiring the
maintenance of a total order relationship for a sequence of all
known context update requests at each entity. This requires that
one entity is the byte
position specified master and one is the slave.

An example showing how the scheme with the total 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 for subsequent
compression/decompression, and all received messages are acknowledged
and piggybacked in all subsequent messages sent by index j.

If result_integer specifies an index which beyond the size of receiver.
Whenever concurrent dictionary updates are happened, update requests
initiated from the
byte buffer, a bad compressed message has been received master entity are ordered first. For example, the
update requests for Messages 1, 2, and
decompression failure occurs.

6.2.6. CALL ... RETURN

The CALL 3 are ordered before those for
Messages 101, 102, and RETURN tokens provide support 103 respectively in the list of the total
order relationship for compression algorithms
with a nested structure.

CALL (index)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| Index MSB | Index LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RETURN

+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+

When the decompressor reaches sequence of dictionary updates (TOL).
DD is a CALL token, it finds the byte
position logical representation of the token immediately following Dynamic Context Data, TSS is
the CALL token logical representation of sent SigComp messages and copies
this integer into stack[stack_free] ready TRS is the
logical representation storage of received SigComp messages.

Since the update request for later retrieval. It
then increases stack_free by Message 1 and continues token execution at the
byte position specified in is ordered before that for
Message 101 according to the CALL token.

When total order relationship, the decompressor reaches a RETURN token it decreases stack_free
by 1, and then continues token execution update
request for Message 101 at the byte position
specified in stack[stack_free].

If stack_free ever becomes more than buffer_size - 1 or less than 0
then a bad compressed message has been received and decompression
failure occurs (see Section 3.4.).

6.2.7. HUFFMAN

The HUFFMAN token maps a shorthand Huffman code onto its uncompressed
equivalent.

HUFFMAN (position, bit offset, destination, n, length 0, length 1,
... , length n - 1)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 Entity Y is blocked until that for Message
1 0 0 1| Position MSB becomes ready to be moved, as indicated by the reception of the
acknowledgement piggybacked with Message 3.

| Position LSB | Bit Offset
DD = {} | | DD = {}
TSS = {1} | | TSS = {101}
TRS = {} | | TRS = {}
TOL = {1} | | TOL = {}
| [1] [101] |

Hannu, Liu, Price, Rosenberg, et al. [Page 19] 12]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Destination MSB|Destination LSB| MSB of n

|-----------\ /-----------|
| LSB of n \/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length 0 /\ | Length 1
|<----------/ \---------->|
| |
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} | ... | Length n TSS = {101 - 1 103}
TRS = {101, 102} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The meaning of the first three parameters is explained below:

Position: 2-byte integer indicating the byte location of the
Huffman code to be decompressed.

Bit Offset: 1-byte integer indicating the bit offset at which the
Huffman code begins within the byte specified above.

Destination: 2-byte integer indicating the location to which the
uncompressed value will be copied.

Following the [DEFLATE] convention a bit offset of 0 indicates the
least significant bit of a byte, whilst a bit offset of 7 indicates
the most significant bit.

For example, suppose that an 8-bit Huffman code begins at byte
position 0 and bit offset 2. In this case the 8 bits of the Huffman
code can be found in the following locations (Bit 0 is the first bit
in the Huffman code and Bit 7 is the last bit):

MSB LSB MSB LSB

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

Byte 0 Byte 1

The remaining parameters specify the actual Huffman codes and their
uncompressed equivalents. Note that the Huffman codes are downloaded TRS = {1, 2}
TOL = {101, 2, | | TOL = {1, 101, 2}
102, 3} | |
| [3] [103] |
|-----------\ /-----------|
| \/ |
| /\ |
|<----------/ \---------->|
| |
DD = {1, 101, 2} | | DD = {1, 101}
TSS = {3} | | TSS = {102, 103}
TRS = {102, 103} | | TRS = {2, 3}
TOL = {102,3,103} | | TOL = {2, 102, 3}
| |

CD Entity X CD Entity Y

Figure 6. An Example of Proposed Scheme with Total Order Relationship
for Dynamic Context Data Updates.

6. Capability exchange

Before two SigComp entities start to send compressed messages between
them, they MUST agree on the decompressor using "Canonical" Huffman as described in Section
3.2.2 of [DEFLATE]. capabilities they will use. This format is very efficient because it can section
does not specify a set of Huffman codes by sending only their lengths.

The parameter n specifies how to perform the total number of Huffman codes.
Following this parameter is exchange, but preferably it
should be conducted at the length negotiation of each Huffman code in bits,
where each code can be between 1 and 255 bits in lengths. applying SigComp.

Buffer size

The length j specifies the length available byte buffer size of the Huffman code which maps onto
the uncompressed 2-byte integer j. If length j is set to 0 then there decompressor MUST be
exchanged.

Hannu, Liu, Price, Rosenberg, et al. [Page 20] 13]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

is no Huffman code mapping onto the integer j, so it cannot be
communicated to the decompressor.

The actual Huffman codes themselves are assigned as per [DEFLATE],
using the following two rules:

* All codes of a given bit length have lexicographically
consecutive values,

SigComp headers

Only in the same order as the symbols they
represent;

* Shorter codes lexicographically precede longer codes.

As an example, suppose that case when both SigComp entities indicate the uncompressed 2-byte integers 0, 1, 2
and 3 have Huffman codes use of lengths 2, 1, 3 and 3 bits respectively.
Then the actual Huffman codes have the following values:

Uncompressed integer Code length (bits) Huffman code

0 2 10
1 1 0
2 3 110
3 3 111

When
headers, the decompressor encounters SigComp protocol MUST add a HUFFMAN token it reads the Huffman
code at the specified position and bit offset, and maps it to the
corresponding 2-byte uncompressed integer. The decompressor then
copies this uncompressed integer SigComp header to the specified destination in the
byte buffer. Finally, the decompressor updates the position and bit
offset parameters with the location of
compressor output. In any other case the next Huffman code (ready
to decompress it at protocol MUST NOT add a later stage).
header.

Shared compression

If the bit offset does a SigComp entity supports shared compression it MAY indicate
that. However, shared compression can only be used in combination
with SigComp headers. A SigComp entity is not take a value between 0 and 7 inclusive
then a bad compressed message has been received and decompression
failure occurs (see Section 6.1.4.). Decompression failure also
occurs required to use
shared compression even if a Huffman code it is encountered for which no supported by the corresponding
uncompressed integer has been defined.
entity.

CPU power

TBW

7. Security considerations

TBW

8. IANA considerations

TBW

9. 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: 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: jan.christoffersson@epl.ericsson.se

Hannu, Liu, Price, Rosenberg, et al. [Page 21] 14]

INTERNET-DRAFT SigComp October 31 November 21 , 2001

9. Authors' Addresses

Hans Hannu

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

Phone: +1 972 894-4886
Fax: +1 972 894-4589
E-mail: christopher.clanton@nokia.com

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

Phone: +46 920 20 21 84 23 39
Fax: +46 920 20 20 99
EMail: hans.hannu@ericsson.com stefan.forsgren@epl.ericsson.se

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
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
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom

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

more authors...

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

Email: jdrosen@dynamicsoft.com

Krister Svanbro
Box 920
Ericsson Erisoft AB
SE-971 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

There might be IPR concerns related

The IETF has been notified of intellectual property rights claimed in
regard to this contribution. This will
be further verified with some or all of the authors and clarified specification contained in future
versions. this
document. For more information consult the online list of claimed
rights.

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

[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),September progress),November
2001. <draft-ietf-rohc-signaling-req-assump-02.txt>

Hannu, Liu, Price, Rosenberg, et al. [Page 22]

INTERNET-DRAFT SigComp October 31 , 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 April May 2002.

Hannu, Liu, Price, Rosenberg, et al. [Page 23] 17]

----