draft-ietf-rohc-sigcomp-extended-02.txt   draft-ietf-rohc-sigcomp-extended-03.txt 
Network Working Group H. Hannu, Ericsson Network Working Group H. Hannu, Ericsson
INTERNET-DRAFT J. Christoffersson, Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson
Expires: September 2002 S. Forsgren. Ericsson Expires: November 2002 S. Forsgren
K. Leung, Nokia K. Leung
Z. Liu, Nokia Z. Liu, Nokia
R. Price, Siemens/Roke Manor R. Price, Siemens/Roke Manor
March 1, 2002 May 03, 2002
SigComp - Extended Operations SigComp - Extended Operations
<draft-ietf-rohc-sigcomp-extended-02.txt> <draft-ietf-rohc-sigcomp-extended-03.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@cdt.luth.se. directed to its mailing list, rohc@ietf.org.
Abstract Abstract
This document defines extended operation mechanisms, such as explicit This document describes mechanisms to be used with Signaling
acknowledgements and shared compression, for [SIGCOMP]. When these Compression (SigComp), RFC XXX, that significantly improve the
extended mechanisms are applied an increase of the compression compression efficiency compared to using per-message compression. The
efficiency is expected. mechanisms, such as explicit acknowledgements and shared compression
are defined and explained in this document.
Table of contents Table of contents
1. Introduction..................................................2 1. Introduction....................................................2
2. Terminology...................................................2 2. Terminology.....................................................2
3. Architectural view of feedback................................4 3. Architectural View of Feedback..................................4
4. State reference model.........................................5 4. State Reference Model...........................................4
5. Extended operation mechanisms.................................6 5. Extended Mechanisms.............................................6
6. Implications on SigComp.......................................9 6. Implications on SigComp........................................11
7. Security considerations......................................13 7. Security Considerations........................................15
8. IANA considerations..........................................13 8. IANA Considerations............................................15
9. Acknowledgements.............................................14 9. Acknowledgements...............................................15
10. Authors' addresses...........................................14 10. Authors' Addresses.............................................15
11. Intellectual Property Right Considerations...................15 11. Intellectual Property Right Considerations.....................16
12. References...................................................15 12. References.....................................................16
Appendix A. Document history.....................................15
1. Introduction 1. Introduction
This document defines extended operation mechanisms, such as explicit This document describes how to implement mechanisms with [SIGCOMP] to
acknowledgements and shared compression, for [SIGCOMP]. These significantly improve the compression efficiency compared to per-
mechanisms are expected to improve the compression efficiency, messages compression.
compared to the case when one of the communicating implementations
only supports the basic SigComp.
For better understanding of this draft the reader should consult One such mechanism is to use previously sent messages in the SigComp
[SIGCOMP]. compression process, referred to as dynamic compression. In order to
utilize information from previously sent messages, it is necessary
for a compressor to gain knowledge about the reception of these
messages. For a reliable transport, such as TCP, this is guaranteed.
For an unreliable transport however, the SigComp protocol can be used
to provide such a functionality itself. That functionality is
described in this document and is referred to as explicit
acknowledgements.
Another mechanism that will improve the compression efficiency of
SigComp, especially when SigComp is applied to protocols that are of
request/response type, is shared compression. This involves using
received messages in the SigComp compression process. In particular
the compression of the first few messages will gain from shared
compression. Shared compression is described in this document.
For better understanding of this draft the reader should be familiar
with the concept of [SIGCOMP].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The reader should consult [SIGCOMP] for definitions of terminology,
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this since this draft uses the same terminology. Further terminology is
document are to be interpreted as described in [RFC-2119]. defined below.
Universal Decompressor Virtual Machine (UDVM) Compressor
The virtual machine described in [SIGCOMP]. The UDVM is used for Entity that encodes application messages using a certain
decompression of SigComp messages. compression algorithm and keeps track of state that can be used
for compression. The compressor is responsible for ensuring that
the messages it generates can be decompressed by the remote UDVM.
Decompressor Decompressor
The decompressor is responsible for converting a SigComp message The decompressor is responsible for converting a SigComp message
into uncompressed data. Decompression functionality is provided by into uncompressed data. Decompression functionality is provided by
the UDVM. the UDVM.
Compressor
The compressor invokes an encoder, and keeps track of states that
can be used for compression. It is responsible for supplying UDVM
bytecode to the remote decompressor in order for compressed data to
be decompressed.
Explicit acknowledgements
Is defined as the case where an acknowledgement for a state is
explicitly sent from a decompressor to its remote compressor. The
acknowledgment can either be sent standalone or piggybacked with a
SigComp message.
Shared compression
Compression relative to messages received by the local associated
decompressor prior to the current compressed message.
Dynamic compression Dynamic compression
Compression relative to messages sent prior to the current Compression relative to messages sent prior to the current
compressed message. compressed message.
Encoder Explicit acknowledgement
Encodes data according to a (compression) algorithm into UDVM Acknowledgement for a state that is explicitly sent from a
bytecode. The encoded data can be decoded by a UDVM. decompressor to its remote compressor. The acknowledgement should
be piggybacked onto a SigComp message in order not to create
additional security risks.
Application Shared compression
For the purpose of this document, an application is a text-based Compression relative to messages received by the local endpoint
protocol software that: invokes the SigComp compressor and prior to the current compressed message.
decompressor.
State Shared state
Data saved for retrieval by later SigComp messages. An item of A state used for shared compression consists only of an
state typically reflects the contents of the UDVM memory after uncompressed message. This makes the state independent of
decompressing a message, but state can also be created by the compression algorithm.
compressor or by the application.
State identifier State identifier
Reference used to access an item of state previously created by the Reference used to access a previously created item of state.
compressor, the decompressor or the application.
- state_identifier
This is a reference to a state, which a compressor uses for
compression.
- shared_identifier
This is a reference to a state, which consist only of an
uncompressed message. This kind of state is necessary for
efficient utilization of shared compression, as remote
compressors might use different compression algorithms.
- acked_identifier
This is a reference to a state, which is saved and acknowledged
by a decompressor.
SigComp message
May contain a compressed application message in the form of UDVM - shared_state_id
bytecode. In case of a message-based transport, such as UDP, a
SigComp message corresponds to exactly one (UDP) datagram. For a
stream-based transport, such as TCP, each SigComp message is
separated by a 0xFFFF delimiter.
Application message State identifier of a shared state.
An uncompressed message, as provided from or to the application, - acked_state_id
which is to be compressed by the compressor. When delivered from
the decompressor the data has passed through the decompression
process and is referred to as decompressed data.
3. Architectural view of feedback State identifier of a state that is acknowledged as
successfully saved by the decompressor.
A SigComp endpoint may provide capability announcement information to 3. Architectural View of Feedback
its remote SigComp endpoint using the UDVM instruction END-MESSAGE.
That particular functionality of SigComp is used in this document to
provide support for extended operation mechanisms described in this
document, e.g. shared compression and explicit acknowledgements.
The capability announcement functionality of SigComp can be viewed as SigComp has a request/response mechanism to provide feedback between
a particular type of feedback, which an endpoint provides to its endpoints, see Figure 1. This particular functionality of SigComp is
remote endpoint, see Figure 1. used in this document to provide support for the mechanisms described
in this document.
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Endpoint 1 | | Endpoint 2 | | Endpoint 1 | | Endpoint 2 |
| +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ |
| | Compressor 1 | | | |Decompressor 2| | | | Compressor 1 | | | |Decompressor 2| |
| | [------------+--+--------------+--+--] * | | | | [------------+--+--------------+--+--] * | |
| +-|-------^----+ | | +--|---|-------+ | | +-|-------^----+ | | +--|---|-------+ |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| +-|-------|----+ | | +--v---|-------+ | | +-|-------|----+ | | +--v---|-------+ |
| | * [----+--+--------------+--+------] | | | | * [----+--+--------------+--+------] | |
| |Decompressor 1| | | | Compressor 2 | | | |Decompressor 1| | | | Compressor 2 | |
| +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 1. Architectural view Figure 1. Architectural view
This functionality of SigComp is extended in this document to make it
possible for a SigComp endpoint to confirm which states that have
been established to its remote SigComp endpoint during the SigComp
session. The established state confirmations are referred to as
acknowledgments. Depending on the established states this particular
type of feedback may be used to increase the compression efficiency.
The following Sections describes how the mechanism for providing the The feedback functionality of SigComp is used in this document to
capability announcement information is used for providing support for provide a mechanism for a SigComp endpoint to confirm which states
some of the extended SigComp mechanisms described in this document. have been established by its remote SigComp endpoint during the
Section 4 starts by describing the State reference model of SigComp. lifetime of a SigComp compartment. The established state
Section 5 continues with a general description of SigComp extended confirmations are referred to as acknowledgments. Depending on the
operation mechanisms, and Section 6 describes the implications on established states this particular type of feedback may or may not be
basic SigComp for some of the extended mechanisms. used to increase the compression efficiency.
4. State reference model The following sections describe how the SigComp functionality of
providing feedback information is used to support the mechanisms
described in this document. Section 4 describes the state reference
model of SigComp. Section 5 continues with a general description of
the mechanisms and Section 6 describes the implications of some of
the mechanisms on basic SigComp.
A UDVM may want to save the status of its memory and this status is 4. State Reference Model
A UDVM may want to save the status of its memory, and this status is
referred to as a state. As explained in [SIGCOMP] a state save referred to as a state. As explained in [SIGCOMP] a state save
request may or may not be granted. For later reference to a saved request may or may not be granted by the application. For later
state, e.g. if the UDVM is to be loaded with this state, a reference reference to a saved state, e.g. if the UDVM is to be loaded with
is needed to locate the specific state. This reference is called this state, a reference is needed to locate the specific state. This
state identifier. reference is called a state identifier.
4.1. Overview of state reference with dynamic compression 4.1. Overview of State Reference with Dynamic Compression
When compressor 1 compresses a message m it uses the information When compressor 1 compresses a message m it uses the information
corresponding to a UDVM state that its remote decompressor 2 has corresponding to a SigComp state that its remote decompressor 2 has
established and acknowledged. If compressor 1 would like to be able established and acknowledged. If compressor 1 wishes to use the new
to use the new state for compression of later messages it must save state for compression of later messages it must save the new state.
the new state. The new state contains information from the former The new state contains information from the former state and from m.
state and m. When an acknowledgement is received for this new state, When an acknowledgement is received for this new state, compressor 1
compressor 1 can utilize the new state in the compression process. can utilize the new state in the compression process. Below is an
Below is an overview of the model. overview of the model together with an example of a message flow.
Saved state(s) Saved state(s)
Compressor: The state is anticipated for compression of later A state which is expected to be used for compression/decompression
messages, and is therefore saved. of later messages.
Decompressor: The decompressor saves the state if it will
acknowledge it. An acknowledged state may be used for
compression.
Acked state(s) Acked state(s)
The compressor can only use a state(s) that the remote decompressor An acked state is a saved state for which the compressor has
has saved and acknowledged. received an acknowledgement, i.e. the state has been established at
the remote decompressor. The compressor must only use states that
are established at the remote decompressor, otherwise a
decompression failure will occur. For this reason, acknowledgements
are necessary, at least for unreliable transport.
Compressor 1 Decompressor 2 Compressor 1 Decompressor 2
+---+ +---+ +---+ +---+
| C | | D | | C | | D |
+---+ +---+ +---+ +---+
Saved Acked | | Saved Saved Acked | | Saved
State(s) State(s) | | State(s) State(s) State(s) | | State(s)
-----------------------+------------+------------------ -----------------------+------------+------------------
s0 s0 | | s0 s0 s0 | | s0
skipping to change at page 6, line 30 skipping to change at page 6, line 5
| | | |
s0-s2 s0,s1 | | s0-s2 s0,s1 | |
s3=s1+m3 | --m3(s1)-->| s0,s1 s3=s1+m3 | --m3(s1)-->| s0,s1
| | | |
| | | |
| <--ack(s3) | s0,s1,s3=s1+m3 | <--ack(s3) | s0,s1,s3=s1+m3
s0-s3 s0,s1,s3 | | s0-s3 s0,s1,s3 | |
Figure 2. Example of message flow. Figure 2. Example of message flow.
5. Extended operation mechanisms 5. Extended Mechanisms
The following subsections give a general description for the extended The following subsections give a general description of the extended
operation mechanisms and features, such as explicit acknowledgements mechanisms.
and shared compression.
5.1. Explicit acknowledgement scheme 5.1. Explicit Acknowledgement Scheme
For a compressor to be able to utilize a certain state it must know For a compressor to be able to utilize a certain state it must know
that the remote decompressor has access to this state. that the remote decompressor has access to this state.
In the case where compressed messages can be lost or misordered on In the case where compressed messages can be lost or misordered on
the path between compressor and decompressor, some sort of the path between compressor and decompressor, an acknowledgement
acknowledgement must be used by a decompressor to notify the remote scheme must be used to notify the remote compressor that a certain
compressor that a certain state has been established. This is also state has been established.
needed in SigComp because the UDVM memory is reset after each
compressed message due to security risks, and also as a request to
save a state may not be granted.
A SigComp message will along with the compressed message carry a Explicit acknowledgements can be initiated either by UDVM-code
reference to which state that was used for compression of the uploaded to the decompressor by the remote compressor or by the
message. This reference is the state_identifier, as described in endpoint where the states have been established. These two cases will
Section 2. be explained in more detail in the following two sections.
Together with state_identifier the SigComp message may also carry an 5.1.1. Remote Compressor Initiated Acknowledgements
acknowledgement, which would be the acked_identifier, see Section 2.
The acknowledgement can be either standalone or piggybacked. For
security reasons as explained in SigComp it is RECOMMENDED that this
particular feedback is piggybacked and not sent standalone.
5.2. Shared Compression This is the case when e.g. compressor 1 has uploaded UDVM bytecode to
decompressor 2. The UDVM bytecode will use the requested feedback
field in the announcement information and the returned feedback field
in the SigComp header to obtain knowledge about established states at
endpoint 2.
To allow for shared compression a compressing endpoint MUST save the Consider Figure 3. An event flow for successful use of remote
uncompressed version of the compressed message as a state. The compressor initiated acknowledgements can be as follows:
reference to this uncompressed version is the shared_identifier, as
described in Section 2. It must also indicate to its remote
decompressor that this compressed message's uncompressed version was
saved as a state at the compressor. If a compressing endpoint
indicates that a shared compression state was saved, its local
decompressor MUST be able to retrieve that particular state.
The retrieval of this particular state is done according to the state
retrieval instructions of the UDVM.
5.3. Maintaining state data across session (1): Compressor 1 saves e.g. state(A).
(2): The UDVM bytecode to initiate a state save for state(A) is
either carried in the compressed message, or can be retrieved by
decompressor 2 from a state already saved at endpoint 2.
(3): As compressor 1 is the initiator of this acknowledgement it can
use an arbitrary identifier to be returned to indicate that
state(A) has been established. The identifier needs to consist
of enough bits to avoid acknowledgement of wrong state. To avoid
padding of the feedback items and for simplicity a minimum of 1
octet should be used for the identifier. The identifier is
placed at the location of the requested_feedback_item [SigComp].
The END-MESSAGE instruction is used to indicate the location of
the requested_feedback_item to the state handler.
(4): The requested feedback data is now called returned feedback data
as it is placed into the SigComp message at compressor 2.
(5): The returned feedback item is carried in the SigComp message
according to Figure 4: see Section 6.1 and [SIGCOMP].
(6): The returned feedback item is handled according to: Section 7
of [SIGCOMP]
+--------------+ (2) +--------------+
| Compressor 1 |--------------------------->|Decompressor 2|
+------^-------+ +-------^------+
| (1) (3) |
+---v---+ +---v---+
|State | |State |
|handler| |handler|
+---^---+ +---^---+
| (6) (4) |
+------v-------+ (5) +-------v------+
|Decompressor 1|<---------------------------| Compressor 2 |
+--------------+ +--------------+
Figure 3. Simplified SigComp endpoints
Usually, signaling protocols (e.g. SIP) have the concept of sessions. 5.1.2. Local Endpoint Initiated Acknowledgements
However, from the compression point of view, the messages sent by the
same source contain redundancies beyond session boundary.
Consequently, it is natural to maintain the state data from the same
source across sessions so that high performance can be achieved and
maintained with the overhead amortized over a much longer period of
time than a session.
5.4. Use of user-specific dictionary When explicit acknowledgements are provided by an endpoint, the
SigComp message will also carry acknowledgements, so-called
acked_state_id: see Section 2.
Consider Figure 3, an event flow for successful use of explicit
endpoint initiated acknowledgements can be as follows:
The concept of user-specific dictionary is based on the following (1): Compressor 1 saves e.g. state(A).
observation that for protocols such as SIP, a given user/device (2): The UDVM bytecode to initiate a state save for state(A) is
combination will produce some messages containing fields that are either carried in the compressed message, or can be retrieved by
always populated with the same data. decompressor 2 from a state already saved at endpoint 2.
(3): A save state request for state(A) is passed to the state handler
using the END-MESSAGE instruction. The application may then
grant the state handler permission to save state(A): see
[SIGCOMP].
(4): Endpoint 2 decides to acknowledge state(A) to endpoint 1. The
state identifier (acked_state_id) for state(A) is placed in
the SigComp message sent from compressor 2 to decompressor 1.
(5): The UDVM bytecode to initiate (pass) the explicit
acknowledgement to endpoint 1 is either carried in the
compressed message, or can be retrieved by decompressor 1 from a
state already saved at endpoint 1.
(6): The acked_state_id for state(A) is passed to the state handler
by placing the acked_state_id at the location of the
"returned SigComp parameters" [SIGCOMP], which location is given
to the state handler using the END-MESSAGE instruction.
Take SIP as an example, capabilities of the SIP endpoints Note: When the requested feedback length is non-zero endpoint
are communicated during session initiation, and do not tend to change initiated acknowledgements should not be used, due to possible waste
unless the device's capabilities change. Similarly, user-specific of bandwidth. When deciding to implement this mechanism one should
information such as a user's URL, a user's name, and a user's e-mail consider whether this is worth the effort as all SigComp
address likely won't change on frequent basis, and will appear implementations will support the feedback mechanism and thus have the
regularly in SIP signaling exchanges involving a specific user. possibility to implement the mechanism of Section 5.1.1.
Therefore, a SigComp compressor could start uploading the user- 5.2. Shared Compression
specific dictionary, as part of the initial state, to the
decompressor even before any signaling messages are generated from a
particular application . This enables the immediate
compression/decompression once the messages start to flow.
5.5. Checkpoint state and rollback mechanism To make use of shared compression a compressing endpoint saves the
uncompressed version of the compressed message as a state (shared
state). As described in Chapter 2 the references to a shared state is
referred to as shared_state_id. The shared state's parameters
state_address and state_instruction must be set to zero. The
state_retention_priority must be set to 65535, and the other state
parameters are set accordingly to [SIGCOMP]. This is because
different compression algorithms may be used to compress application
messages traveling in different directions.
The shared state is also created on a per-compartment basis, i.e. the
shared state is stored in the same memory as the states created by
the particular remote compressor. The choice of how to divide the
state memory between "ordinary" states and shared states is an
implementation decision at the compressor. Note that new shared state
items must not be created unless the compressor has made enough state
memory available (as decompression failure could occur if the shared
state pushed existing state out of the state memory buffer).
The following mechanisms can be used to recover from decompression A compressing endpoint must also indicate to the remote compressor
failure due to a reference to a non-exist state (i.e. not established that the shared state is available, but only if the local
at all or has been deleted by the decompressor) or a corrupted state: decompressor can retrieve the shared state. The retrieval of the
shared state is done accordingly to the state retrieval instruction
of the UDVM.
1) When a compressor sends a compressed message that will create new Consider Figure 3. An event flow for successful use of shared
decompression state on the decompressor side, it can set a CHK_PT bit compression can be as follows:
in the message to indicate that the newly created state will be a
checkpoint state. A checkpoint state means that the decompressor
SHOULD NOT delete it until it is explicitly instructed -- by the
compressor -- to do so. In addition, the checkpoint state MUST be
explicitly acknowledged by the receiving decompressor to the sending
compressor.
2) When a decompressor encounters a decompression failure as (1): Compressor 1 saves e.g. state(M), which is the uncompressed
described above, it can send a rollback message to its remote version of the current application message to be compressed and
compressor indicating such a failure. In addition, the rollback sent.
message may carry a list of state IDs of those checkpoint states that (2): The UDVM bytecode to indicate the presence of state(M) at
are currently maintained by the decompressor. This is useful in the endpoint 1 is either carried in the compressed message, or can
case when the decompressor has to delete even checkpoint states due be retrieved by decompressor 2 from a state already saved at
to limited memory. When receiving such a rollback message, the endpoint 2.
compressor MUST NOT use any state to compress subsequent messages (3): The SHA-1 instruction is used at endpoint 2 to calculate the
other than those explicitly listed in the rollback message or if the shared_state_id for state(M). The indication is passed to the
list is empty, than those checkpoint states it stores locally and state handler, by placing the shared identifier at the location
have been acknowledged. of the "returned SigComp parameters" [SIGCOMP]. The location of
the "returned SigComp parameters" is given to the state handler
using the END-MESSAGE instruction.
(4): If endpoint 2 uses shared compression, it compares the state
identifier values in the "returned SigComp parameters"
information with the value it has calculated for the current
decompressed message received from endpoint 1. If there is a
match then endpoint 2 uses the shared state together with the
state it would normally use if shared compression is not
supported to compress the next message.
5.6. Implicit deletion when creating a new state (5): The UDVM bytecode that will use the shared state (state(M)) in
the decompression process at decompressor 1 is either carried
in the compressed message, or can be retrieved by decompressor 1
from a state already saved at endpoint 1.
To achieve the maximum compression efficiency, a compressor may want 5.3. Maintaining State Data Across Application Sessions
to delete part (e.g. dictionary part) of byte buffer to make room for
the new content. This is especially important when implementing
SigComp with limited memory (as in the case of a mobile terminal).
With the implicit deletion, some part(s) of the byte buffer are Usually, signaling protocols (e.g. SIP) employ the concept of
chosen to be deleted according to a well defined algorithm that is sessions. However, from the compression point of view, the messages
known and applied in the same way at both compressor and sent by the same source contain redundancies beyond the session
decompressor. As input into the algorithm, one provides the total boundary. Consequently, it is natural to maintain the state data from
size to be deleted (e.g. number of bytes), and the algorithm the same source across sessions so that high performance can be
specifies which part(s) are to be deleted. The freed room can then achieved and maintained, with the overhead amortized over a much
allow new content to be added to the byte buffer. Since the same longer period of time than one application session.
algorithm is applied at both SigComp entities, there is no need to
explicitly signal which part(s) have been deleted. In particular,
when the allocated memory has been filled up, each SigComp entity,
when it wants to add items of combined size S, will implicitly delete
part(s) of combined size S. Since there is no need for signaling,
the scheme is more efficient (lower signaling overhead) and more
robust (less prone to errors or losses affecting the signaling
information).
For example, the implicit deletion may be applied to the entire Maintaining states across application sessions can be achieved
writable UDVM memory defined by working_memory_start and simply by making the lifetime of a compartment longer than the
working_memory_end or only some parts of the writable UDVM memory. In time duration of a single application session. Note that the
the latter case, it is assumed that the peer SigComp entities agree states here are referring to those stored on a per-compartment
on which parts the operation is applied to and the total size of basis, not the locally available states that are stored on a global
those parts. basis (i.e. not compartment specific).
6. Implications on SigComp 5.4. Use of User-Specific Dictionary
The extended operations will have implication on the SigComp messages The concept of the user-specific dictionary is based on the
sent between the compressor and the remote decompressor. It will also observation that for protocols such as SIP, a given user/device
have implications on how to interpret the interface between the UDVM combination will produce some messages containing fields that are
and its local decompressor functionalities. always populated with the same data.
Note that an implementation that does not make use of explicit Take SIP as an example. Capabilities of the SIP endpoints
acknowledgements and/or shared compression is not effected even if it are communicated during session initiation, and tend not to change
receives this kind of feedback. unless the capabilities of the device change. Similarly, user-
specific information such as the user's URL, name, and e-mail address
likely will not change on a frequent basis, and will appear
regularly in SIP signaling exchanges involving a specific user.
The following sections described the implications due to explicit Therefore, a SigComp compressor could include the user-specific
acknowledgements and shared compression. dictionary as part of the initial messages to the decompressor, even
before any time critical signaling messages are generated from a
particular application. This enables increased compression efficiency
once the messages start to flow.
6.1. Implications on SigComp messages Obviously, the user-specific dictionary is a state item that would be
good to have as a cross-session state: see Section 5.3.
For the support of the extended operation mechanisms, shared 5.5. Checkpoint State
compression and explicit acknowledgements, SigComp messages must be
able to carry the indications and information addressed in Sections
5.1 and 5.2.
The basic SigComp message has the following format: The following mechanism can be used to avoid decompression failure
due to reference to a non-existent state. This may occur in three
cases: a) a state is not established at remote SigComp endpoint due
to loss of a SigComp message; b) a state is not established due to
insufficient memory; c) a state has been established but was deleted
later due to insufficient memory.
0 1 2 3 4 5 6 7 When a compressor sends a SigComp message that will create a new
+---+---+---+---+---+---+---+---+ state on the decompressor side, it can indicate that the newly
| | created state will be a checkpoint state by setting
: state_identifier (n-bytes) : state_retention_priority [SIGCOMP] to the highest value sent by the
| | same compressor. In addition, a checkpoint state must be explicitly
+---+---+---+---+---+---+---+---+ acknowledged by the receiving decompressor to the sending compressor.
| |
: Remaining UDVM bytecode :
| |
+---+---+---+---+---+---+---+---+
Figure 3. Format of basic SigComp message. Consider Figure 3. An event flow for this kind of state management
can be as follows:
The content of the UDVM byte code is an implementation decision. (1): Compressor 1 saves e.g. state(A), which it would like to have as
However, in the case of extended operations it should convey the a checkpoint state at decompressor 2.
following information: (2): The UDVM bytecode to indicate the state priority ([SIGCOMP] -
state_retention_priority) of state(A) and initiate a state save
for state(A) is either carried in the compressed message, or can
be retrieved by decompressor 2 from a state already saved at
endpoint 2.
(3): A save state request for state(A) is passed to the state handler
using the END-MESSAGE instruction, including the indication of
the state priority. The application grants the saving of
state(A): see [SIGCOMP].
(4): An acknowledgement for state(A) (the checkpoint state) is
returned to endpoint B using one of the mechanisms described in
Section 5.1.
- The shared_identifier as described in Section 2, and Section 5.2, Note: To avoid using a state that has been deleted due to
MUST be conveyed when shared compression is applied. insufficient memory a compressor must keep track of the memory
available for saving states at the remote endpoint. The SigComp
parameter state_memory_size which is announced by the SigComp
feedback mechanism can be used to infer if a previous checkpoint
state has been deleted (by a later checkpoint state creation request)
due to lack of memory.
- State identifiers of states that are acknowledged as successfully 5.6. Implicit Deletion for Dictionary Update
saved by the decompressor, i.e. acked_identifiers.
Figure 4, depicts an example of what an extended basic SigComp Usually a state consists of two parts: UDVM bytecode and dictionary.
message, with the support of shared compression and explicit When dynamic compression is applied, new content needs to be added to
acknowledgements, could look like. Note that this is only an example, the dictionary. To keep an upper bound of the memory consumption such
the format is an implementation decision. as in the case for a low end mobile terminal, existing content of the
dictionary must be deleted to make room for the new content.
0 1 2 3 4 5 6 7 Instead of explicitly signaling which parts of the dictionary need to
+---+---+---+---+---+---+---+---+ be deleted on a per message basis, an implicit deletion approach may
| | be applied. Specifically, some parts of the dictionary are chosen to
: state_identifier (n-bytes) : be deleted according to a well-defined algorithm that is known and
| | applied in the same way at both compressor and decompressor. For
+---+---+---+---+---+---+---+---+ instance, the algorithm can be part of the predefined UDVM bytecode
| s | a | r | b | Reserved | that is agreed between the two SigComp endpoints. As input into to
+---+---+---+---+---+---+---+---+ the algorithm, one provides the total number of bytes to be deleted.
| | The algorithm then specifies which parts of dictionary are to be
: shared_identifier (n-bytes) : Present if 's' is set deleted. Since the same algorithm is applied at both SigComp
| | endpoints, there is no need for explicit signaling on a per message
+---+---+---+---+---+---+---+---+ basis. This may lead to higher compression efficiency due to the
| | avoidance of signaling overhead. It also means more robustness as
: acked_identifier (n-bytes) : Present if 'a' is set there are no signaling bit on the wire that are subject to possible
| | transmission errors/losses.
+---+---+---+---+---+---+---+---+
| Possible |
: Compressed data :
| |
+---+---+---+---+---+---+---+---+
Figure 4. Example of SigComp message for extended operations. 6. Implications on SigComp
'r' : If set, then a state corresponding to the decompressed The extended features will have implications on the SigComp messages
version of this compressed message was saved at the sent between the compressor and its remote decompressor, and on how
compressor. to interpret e.g. returned SigComp parameters [SIGCOMP]. However,
except for the mandatory bytes of the SigComp messages [SIGCOMP], the
final message formats used are implementation issues.
Note that an implementation that does not make use of explicit
acknowledgements and/or shared compression is not affected, even if
it receives this kind of feedback.
'b' : Explained in Section 6.2.2. 6.1. Implications on SigComp Messages
For the explanation of (n-bytes) see [SIGCOMP]. To support the extended features, SigComp messages must carry the
indications and information addressed in Section 5.
For example to support shared compression and explicit
acknowledgements the SigComp messages need to convey the following
information:
6.2. SigComp capability announcement format - The acked_state_id as described in Sections 2 and 5.1.
- The shared_state_id as described in Sections 2 and 5.2.
The SigComp capability announcement information mechanisms is, as Figure 4, depicts the format of a SigComp message according to:
explained in Section 3, used to provide the support for shared [SIGCOMP]
compression and explicit acknowledgements. The following format is 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
specified in SigComp and is made available to the compressor by the +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
UDVM instruction END-MESSAGE | 1 1 1 1 1 | T | len | | 1 1 1 1 1 | T | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| length | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : returned feedback item : : returned feedback item :
| UDVM_version | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| overall_memory_size | | | | code_len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : partial state identifier : +---+---+---+---+---+---+---+---+
| cycles_per_bit | | | | code_len | destination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| cycles_per_message | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : remaining SigComp message : : uploaded UDVM bytecode :
| n | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| id_length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_1 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_n :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: reserved : : remaining SigComp message :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---+---+---+---+---+---+---+---+
Figure 4. Format of a SigComp message.
Figure 5. SigComp capability announcement information The format of the field "remaining SigComp message" is an
implementation decision by the compressor which supplies the UDVM
bytecode. Therefore there is no need to specify a message format to
carry the information necessary for the extended features described
in this document.
For description of the items see [SigComp]. Figure 5, depicts an example of what the "remaining SigComp message"
with support for shared compression and explicit acknowledgements,
could look like. Note that this is only an example; the format is an
implementation decision.
The following Section describes how the capability announcement 0 1 2 3 4 5 6 7
information is interpreted to provide feedback according to Section +---+---+---+---+---+---+---+---+
5.1 and 5.2. | Format according to Figure 4 |
: except for the field called :
| "remaining SigComp message" | "remaining SigComp message" field
+---+---+---+---+---+---+---+---+ --------
| s | a | r | Reserved | |
+---+---+---+---+---+---+---+---+ |
| | |
: shared_state_id* : Present if 's' is set
| | |
+---+---+---+---+---+---+---+---+ |
| | |
: acked_state_id* : Present if 'a' is set
| | |
+---+---+---+---+---+---+---+---+ |
| | |
: Rest of the SigComp message : |
| | v
+---+---+---+---+---+---+---+---+ --------------
6.2.1. Extended SigComp feedback format Figure 5. Example of SigComp message for some of the extended
features.
When a SigComp message is not regarded as a capability announcement 'r' : If set, then a state corresponding to the decompressed
message, the END-MESSAGE instruction does not actually point to the version of this compressed message (shared state) was saved at
capability announcement location but rather to a feedback location the compressor.
with the feedback format block as depicted in Figure 7. The * : The length of the shared_state_id and acked_state_id fields
id_length(s) and id_value(s) corresponds to the hash_length and are of the same length as the partial state identifier.
hash_value for state(s) that have been established at the remote end-
point due to received SigComp messages and may be used for
compression, i.e. these are acknowledgements for established states.
The 'r' bit indicates that an uncompressed version of the compressed 6.2. Extended SigComp Announcement/Feedback Format
message sent in this message has been saved at the remote endpoint,
with the demands of Section 5.2. The 'b' bit is explained in Section
6.2.2. The format of the feedback information block is of the
following form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This section describes how the "returned_SigComp_parameters"
| length | [SIGCOMP] information is interpreted to provide feedback according to
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 5.1 and 5.2.
| UDVM_version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| overall_memory_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_1 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_n :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|b| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: reserved :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. Format of the extended feedback. The partial_state_identifiers correspond to the hash_value for states
that have been established at the remote endpoint after received
SigComp messages, i.e. these are acknowledgements for established
states and may be used for compression. The partial_state_identifiers
may also announce "global state" that is not mapped to any particular
compartment and is not established upon the receipt of a SigComp
message.
A basic SigComp implementation will not recognize the identifier It is up to the implementation to deduce what kind of state each
values and should not consider the reserved field in the feedback partial_state_identifier refers to, e.g. an acknowledged state or a
location therefore it is not effected if it receives this kind of shared state. In case a SigComp message that includes state
feedback. identifiers for shared states and/or acknowledged states is received
by a basic SigComp implementation, these identifiers will be ignored.
6.2.2. Acknowledgement optimization The I-bit of the requested feedback format is provided to switch off
the list of locally available state items. An endpoint that wishes to
receive shared_state_id must not set the I-bit to 1. The endpoint
storing shared states and sending the list of locally available
states to its remote endpoint must be careful when taking the
decision whether to excluded or include different types of the
locally available states (i.e. shared states or states of e.g. well-
known algorithms) from/to the list.
Consider the following scenario, see Figure 1. Compressor 1 sends a 6.3. Acknowledgement Optimization
message m, compressed with state s0, to decompressor 2. As Compressor
1 supports shared compression it saves the uncompressed message m as
a state M, and sets bit 'r', to signal that state M can be used by
compressor 2 in the compression process.
If decompressor_1 saves a new state, s1, using information in state If shared compression is used between two endpoints (see Figure 1)
s0 and m then this new state can be implicitly acknowledged in case then there exists an optimization, which if implemented makes an
compressor 2 utilizes shared compression by using state M for further acked_state_id in the SigComp message unnecessary:
compression.
The implicit acknowledgement is given by compressor 2 which sets the Compressor 1 saves a shared state(M), which is the uncompressed
'b' bit and the shared identifier. The shared identifier indicates version of the current compressed message (message m) to be sent.
that the state M has been used for compression together with the Compressor 1 also sets bit 'r' (see Figure 5), to signal that
state indicated in the state_identifier. The 'b' bit indicates that state(M) can be used by endpoint 2 in the compression process. The
state s1 has been saved at decompressor 2. That is, the 'b' bit and acked_state_id for state(S), which was created at endpoint 2 upon the
the shared identifier for M indicate that the state used to compress decompression of message m, may not have to be explicitly placed in
m together with the actual message m, have been saved as a new state the compressed messages from compressor 2 if the shared state(M) is
(s1) at decompressor 2. This avoids the acked_identifier for state s1 used in the compression process.
to be present in the SigComp message.
Also, the compressor that sets the 'r' bit should also hold a mapping When endpoint 1 notices that shared state(M) is requested by
between the state M and state s1. decompressor 1, it implicitly knows that state(S) was created at
endpoint 2. This follows since:
Note: The only state that this feature acknowledges, is the state * Compressor 1 has instructed decompressor 2 to save state(S).
that was created by combining the state used for compression of the * The indication of shared state(M) would never have been received by
shared message and the shared message itself. For any other case the compressor 2 if state(S) had not been successfully saved, because
acked_identifier has to be used. if a state save request is denied then the corresponding
announcement information is discarded by the state handler.
7. Security considerations Note: Endpoint 1's state handler must maintain a mapping between
state(M) and state(S) for this optimization to work.
The features in this document are believed not to add any additional Note: The only state acknowledge by this feature acknowledges is the
security risks to the ones in [SIGCOMP]. state that was created by combining the state used for compression of
the message and message itself. For any other case the
acked_state_id has to be used.
8. IANA considerations Note: There is a possibility that state(S) is discarded due to lack
of state memory even though the announcement information is
successfully forwarded. This possibility must be taken into account
(otherwise a decompression failure may occur), and can be so by using
the SigComp parameter state_memory_size which is announced by the
SigComp feedback mechanism. The endpoint can use this parameter to
infer if a state creation request has failed due to lack of memory.
[Editor's note: TBW] 7. Security Considerations
9. Acknowledgements The features in this document are believed not to add any security
risks to the ones mentioned in [SIGCOMP].
Thanks to 8. IANA Considerations
Carsten Bormann (cabo@tzi.org) This document does not require any IANA involvement.
Christopher Clanton (christopher.clanton@nokia.com)
Miguel Garcia (Miguel.A.Garcia@ericsson.com)
Lars-Erik Jonsson (lars-erik.jonsson@epl.ericsson.se)
Khiem Le (khiem.le@nokia.com)
Mats Nordberg (mats.nordberg@epl.ericsson.se)
Jonathan Rosenberg (jdrosen@dynamicsoft.com)
Krister Svanbro (krister.svanbro@epl.ericsson.se)
for valuable input and review. 9. Acknowledgements
10. Authors' addresses Thanks to Carsten Bormann, Christopher Clanton, Miguel Garcia,
Lars-Erik Jonsson, Khiem Le, Mats Nordberg, Jonathan Rosenberg
and Krister Svanbro for valuable input.
10. Authors' Addresses
Hans Hannu Hans Hannu
Box 920
Ericsson AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 84 Phone: +46 920 20 21 84
Fax: +46 920 20 20 99
E-Mail: hans.hannu@epl.ericsson.se E-Mail: hans.hannu@epl.ericsson.se
Jan Christoffersson Jan Christoffersson
Box 920
Ericsson AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 28 40 Phone: +46 920 20 28 40
Fax: +46 920 20 20 99
E-Mail: jan.christoffersson@epl.ericsson.se E-Mail: jan.christoffersson@epl.ericsson.se
Stefan Forsgren Stefan Forsgren
Phone: +46 920 20 23 39 E-Mail: stefan.forsgren@haggve.se
Fax: +46 920 20 20 99
E-Mail: stefan.forsgren@epl.ericsson.se
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Ka Cheong Leung Ka Cheong Leung
Phone: +1 972 374-0630 E-mail: kcleung@eee.hku.hk
Fax: +1 972 894-4589
E-mail: kacheong.leung@nokia.com
Zhigang Liu Zhigang Liu
Phone: +1 972 894-5935
Fax: +1 972 894-4589
E-Mail: zhigang.liu@nokia.com
Nokia Research Center Nokia Research Center
6000 Connection Drive Irving, TX 75039, USA 6000 Connection Drive Irving, TX 75039, USA
Phone: +1 972 894-5935
E-Mail: zhigang.liu@nokia.com
Richard Price Richard Price
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN, United Kingdom
Phone: +44 1794 833681 Phone: +44 1794 833681
E-mail: richard.price@roke.co.uk E-mail: richard.price@roke.co.uk
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
11. Intellectual Property Right Considerations 11. Intellectual Property Right Considerations
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
12. References 12. References
[SIP] Handley et. al., SIP: Session Initiation Protocol, [SIP] M. Handley et. al., SIP: Session Initiation Protocol,
RFC 2543, Internet Engineering Task Force, March 1999 RFC 2543, Internet Engineering Task Force, March 1999
[SIGCOMP] H. Hannu et. al., Signaling Compression (SigComp), [SIGCOMP] R. Price et. al., Signaling Compression (SigComp),
Internet Draft (work in progress), March 2002. Internet Draft (work in progress), May 2002.
<draft-ietf-rohc-sigcomp-05.txt> <draft-ietf-rohc-sigcomp-06.txt>
Appendix A. Document history
- January 28, 2002, version 00
First version. This draft describes the extended operation
mechanisms, explicit acknowledgements and shared compression from
draft-ietf-rohc-sigcomp-02.txt.
- February 15, 2002, version 01
Second version. Updated to reflect the changes made in SigComp-04.
- March 1, 2002, version 02
Third version. Updated to reflect the changes made in [SIGCOMP].
This Internet-Draft expires in September 2002. This Internet-Draft expires November 03, 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/