draft-ietf-rohc-sigcomp-extended-00.txt   draft-ietf-rohc-sigcomp-extended-01.txt 
Network Working Group H. Hannu (Editor), Ericsson Network Working Group H. Hannu, Ericsson
INTERNET-DRAFT J. Christoffersson, Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson
Expires: July 2002 C. Clanton, Nokia Expires: August 2002 S. Forsgren. Ericsson
S. Forsgren. Ericsson
K. Le, Nokia
K. Leung, Nokia K. Leung, Nokia
Z. Liu, Nokia Z. Liu, Nokia
R. Price, Siemens/Roke Manor R. Price, Siemens/Roke Manor
J. Rosenberg, Dynamicsoft February 15, 2002
K. Svanbro, Ericsson
January 28, 2002
SigComp - Extended Operations SigComp - Extended Operations
<draft-ietf-rohc-sigcomp-extended-00.txt> <draft-ietf-rohc-sigcomp-extended-01.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 44 skipping to change at page 1, line 40
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@cdt.luth.se.
Abstract Abstract
This document defines extended operation mechanisms, explicit This document defines extended operation mechanisms, explicit
acknowledgements and shared compression, for [SIGCOMP]. When acknowledgements and shared compression, for [SIGCOMP]. When these
extended SigComp implementations communicate an increase of the extended mechanisms are applied an increase of the compression
compression efficiency is expected. efficiency is expected.
0. 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.
Table of contents Table of contents
1. Introduction..................................................2 1. Introduction..................................................2
2. Terminology...................................................2 2. Terminology...................................................2
3. The Extended SigComp Architecture.............................4 3. Architectural view for feedback...............................4
4. State reference model.........................................5 4. State reference model.........................................5
4.1. Overview of state reference with dynamic compression........6 5. Extended operation mechanisms.................................6
5. Extended operation mechanisms.................................7 6. Implications on SigComp.......................................9
5.1. Explicit acknowledgement scheme.............................7 7. Security considerations......................................14
5.2. Shared Compression..........................................7 8. IANA considerations..........................................14
6. Implications on SigComp.......................................8 9. Acknowledgements.............................................14
6.1. Acknowledgement optimization................................9 10. Authors' addresses...........................................14
6.2. Saving state information....................................9 11. Intellectual Property Right Considerations...................15
7. Security considerations......................................10 12. References...................................................15
8. IANA considerations..........................................10 Appendix A. Document history.....................................16
9. Acknowledgements.............................................10
10. Authors' addresses...........................................10
11. Intellectual Property Right Considerations...................11
12. References...................................................11
1. Introduction 1. Introduction
This document defines extended operation mechanisms, explicit This document defines extended operation mechanisms, explicit
acknowledgements and shared compression, for [SIGCOMP]. These acknowledgements and shared compression, for [SIGCOMP]. These
mechanisms are expected to improve the compression efficiency between mechanisms are expected to improve the compression efficiency,
communicating extended SigComp implementations, compared to the case compared to the case when one of the communicating implementations
when one of the communicating implementations only support basic only support the basic SigComp.
SigComp.
For better understanding of this draft the reader should consult For better understanding of this draft the reader should consult
[SIGCOMP]. [SIGCOMP].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
Universal Decompressor Virtual Machine (UDVM) Universal Decompressor Virtual Machine (UDVM)
The virtual machine described in [UDVM]. The UDVM is used for The virtual machine described in [SIGCOMP]. The UDVM is used for
decompression of SigComp messages. The UDVM is capable of decompression of SigComp messages. The UDVM is capable of
interoperating with a wide range of compression algorithms. interoperating with a wide range of compression algorithms.
Decompressor Decompressor
The decompressor invokes the UDVM. It is responsible for supplying The decompressor invokes the UDVM. It is responsible for supplying
the UDVM with compressed data and make decompressed data available the UDVM with compressed data and make decompressed data available
for the application. for the application.
Compressor Compressor
The compressor invokes the encoder, and keeps track of states that The compressor invokes the encoder, and keeps track of states that
can be used for compression. Responsible for supplying UDVM can be used for compression. Responsible for supplying UDVM
instructions to the peer decompressor in order for compressed instructions to its remote decompressor in order for compressed
data to be decompressed. data to be decompressed.
Explicit acknowledgements Explicit acknowledgements
Is defined as the case where an acknowledgement for a state is Is defined as the case where an acknowledgement for a state is
explicitly sent from a decompressor to a compressor. The explicitly sent from a decompressor to a compressor. The
acknowledgment can either be sent standalone or piggybacked with a acknowledgment can either be sent standalone or piggybacked with a
SigComp message. SigComp message.
Shared compression Shared compression
skipping to change at page 4, line 5 skipping to change at page 3, line 39
Application Application
Invokes the SigComp compressor and decompressor. Invokes the SigComp compressor and decompressor.
State State
Data saved either by a compressor or a decompressor. The data Data saved either by a compressor or a decompressor. The data
reflects the contents of a UDVM memory. reflects the contents of a UDVM memory.
State index State identifier
Reference to a state saved either by a compressor or a Reference to a state saved either by a compressor or a
decompressor. decompressor.
- state_index - state_identifier
This is a reference to a state, which a compressor uses for This is a reference to a state, which a compressor uses for
compression. compression.
- shared_index - shared_identifier
This is a reference to a state, which consist only of an This is a reference to a state, which consist only of an
uncompressed message. This kind of state is necessary for uncompressed message. This kind of state is necessary for
efficient utilization of shared compression, as peer efficient utilization of shared compression, as remote
compressors might use different compression algorithms. compressors might use different compression algorithms.
- acked_index - acked_identifier
This is a reference to a state, which is acknowledged and saved This is a reference to a state, which is acknowledged and saved
by a decompressor. by a decompressor.
SigComp message SigComp message
In case of a message oriented transport mechanism, such as UDP, a May contain a compressed application message in the form of UDVM
SigComp message corresponds to exactly one (UDP) packet. For a bytecode. In case of a message- based transport, such as UDP, a
stream oriented transport, such as TCP, each SigComp message is SigComp message corresponds to exactly one (UDP) datagram. For a
separated by a 0xFFFF delimiter, see [UDVM]. stream-based transport, such as TCP, each SigComp message is
separated by a 0xFFFF delimiter.
Application data (message) Application message
Data, also referred to as message, which is to be An uncompressed message, as provided from or to the application,
compressed by the compressor. When delivered from the decompressor which is to be compressed by the compressor. When delivered
the data has passed through the decompression process and is from the decompressor the data has passed through the decompression
referred to as decompressed data or decompressed message. process and is referred to as decompressed data or a decompressed
message.
3. The Extended SigComp Architecture 3. Architectural view for feedback
Compression and decompression is performed at two communicating end- A SigComp endpoint may provide feedback to its remote SigComp
points, see Figure 1. endpoint, see Figure 1.
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Compressor 1 | | Decompressor 1 | | Endpoint 1 | | Endpoint 2 |
| +---------+ | | +---------+ | | +--------------+ | | +--------------+ |
| | Encoder | | | | UDVM | | | | Compressor | | | | Decompressor | |
| +---------+ | | +---------+ | | | [------------+--+--------------+--+--] * | |
+--------------------+ +--------------------+ | +-|-------^----+ | | +--|---|-------+ |
^ ^ App. ^ | ^ | App. ^ | | | | | | | | |
| | data | | | v data | v | | | | | | | |
+-|--|-------------|-+ +-|-------------|--|-+ | | | | | | | |
| | | | | SigComp | | | | | | +-|-------|----+ | | +--v---|-------+ |
|[E] | Application v | message | | Application | | | | | * [----+--+--------------+--+------] | |
| | v +---------->----------+ v | | | | Decompressor | | | | Compressor | |
| | +-------+ | | +-------+ | | | +--------------+ | | +--------------+ |
| | | State | | Data transport | | State | | |
| | +-------+ | | +-------+ | |
| | ^ +----------<----------+ ^ | |
| | | | | SigComp | ^ | [E]|
| | | | | message | | | | |
+-|--|-------------|-+ +-|-------------|--|-+
^ | App. ^ | | | App. | |
| v data | v | v data v v
+--------------------+ +--------------------+
| Decompressor 2 | | Compressor 2 |
| +---------+ | | +---------+ |
| | UDVM | | | | Encoder | |
| +---------+ | | +---------+ |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 1. Extended SigComp High-level view. Figure 1. Architectural view
The difference between SigComp and extended SigComp is the With the extended feedback format specified in Section 6, it is
availability of "interface" E (symbol [E]). With the extended possible for a SigComp endpoint to confirm which states that have
operation, explicit acknowledgements (symbol [E]), it is possible for been established to its remote SigComp endpoint. The established
e.g. decompressor 1 to inform compressor 1 about states that have state confirmations are referred to as acknowledgments.
been established at decompressor 1. Compressor 1 can then use these
states in the compression process. Depending on the established Depending on the established states this particular type of feedback
states, this is expected to increase the compression efficiency. See may be used to increase the compression efficiency.
Section 6 for the extended SigComp message format.
4. State reference model 4. State reference model
A UDVM [UDVM] may want to save the status of its memory. This status A UDVM may want to save the status of its memory and this status is
is referred to as a state. The decompressor may allow the state to be referred to as a state. As explained in [SIGCOMP] a save state
saved. For later reference to this state, e.g. if the UDVM is to be request may or may not be granted. For later reference to a saved
loaded with this state, a reference is needed to locate the specific state, e.g. if the UDVM is to be loaded with this state, a reference
state. This reference is called state index. is needed to locate the specific state. This reference is called
state identifier.
4.1. Overview of state reference with dynamic compression 4.1. Overview of state reference with dynamic compression
When compressor 1 (comp_1) compresses a message M it uses the When compressor 1 (comp_1) compresses a message M it uses the
information corresponding to a UDVM state that the peer decompressor information corresponding to a UDVM state that its remote
(decomp_1) has established and acknowledged. If comp_1 decides that decompressor (decomp_2) has established and acknowledged. If comp_1
it for compression of later messages would like to be able to use the decides that it for compression of later messages would like to be
new state, which is the former state with the addition of information able to use the new state, which is the former state with the
from M, it must save the new state. If an acknowledgement is received addition of information from M, it must save the new state. If an
for this new state, comp_1 can utilize the new state in the acknowledgement is received for this new state, comp_1 can utilize
compression process. Below is an overview of the model. the new state in the compression process. Below is an overview of the
model.
Available state(s) Available state(s)
Compressor: The state is anticipated for compression of later Compressor: The state is anticipated for compression of later
messages, and is therefore saved. messages, and is therefore saved.
Decompressor: The decompressor saves the state if it will Decompressor: The decompressor saves the state if it will
acknowledge it. An acknowledged state may be used for acknowledge it. An acknowledged state may be used for
compression. compression.
Acked state(s) Acked state(s)
The compressor can only use a state(s) that the peer decompressor The compressor can only use a state(s) that the remote decompressor
has saved and acknowledged. has saved and acknowledged.
Compressor 1 Decompressor 1 Compressor 1 Decompressor 2
+---+ +---+ +---+ +---+
| C | | D | | C | | D |
+---+ +---+ +---+ +---+
Available Acked | | Available Available Acked | | Available
State(s) State(s) | | State(s) State(s) State(s) | | State(s)
-----------------------+------------+------------------ -----------------------+------------+------------------
s0 s0 | | s0 s0 s0 | | s0
s1=s0+m1 | --m1(s0)-->| s1=s0+m1 | --m1(s0)-->|
| <--ack(s1) | s0,s1 | <--ack(s1) | s0,s1
skipping to change at page 7, line 5 skipping to change at page 6, line 28
s0,s1 s0,s1 | --m2(s1)-->| (m2 Lost) s0,s1 s0,s1 | --m2(s1)-->| (m2 Lost)
s2=s1+m1 | | s2=s1+m1 | |
| | | |
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.
5. Extended operation mechanisms 5. Extended operation mechanisms
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 peer decompressor has access to this state. that the remote decompressor has access to this state.
In case where compressed messages can be lost or misordered on the In case where compressed messages can be lost or misordered on the
path between compressor and decompressor, some sort of path between compressor and decompressor, some sort of
acknowledgement must be used by a decompressor to notify the peer acknowledgement must be used by a decompressor to notify the remote
compressor that a certain state has been established. compressor that a certain state has been established.
Over reliable and ordered transport the most recent state can always Over reliable and ordered transport the most recent state may be
be used, if the compressor has downloaded such a UDVM instruction used, if the compressor has downloaded such a UDVM instruction code
code to the peer decompressor. to its remote decompressor.
The following subsections describe how an explicit acknowledgement The following subsections describe how an explicit acknowledgement
scheme and shared compression can be used in SigComp. scheme and shared compression can be applied in SigComp.
5.1. Explicit acknowledgement scheme 5.1. Explicit acknowledgement scheme
As described above, a SigComp message will along with the compressed A SigComp message will along with the compressed message carry a
message carry a reference to which state that was used for reference to which state that was used for compression of the
compression of the message. This reference is the state_index, as message. This reference is the state_identifier, as described in
described in Section 2. Section 2.
Together with state_index the SigComp message may also carry an Together with state_identifier the SigComp message may also carry an
acknowledgement, which would be the acked_index, see Section 2. The acknowledgement, which would be the acked_identifier, see Section 2.
acknowledgement can be either standalone or piggybacked. 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 5.2. Shared Compression
To allow for shared compression a compressor must save a state, which To allow for shared compression a compressing endpoint MUST save a
is the uncompressed version of the compressed message. The reference state, which is the uncompressed version of the compressed message.
to this uncompressed version is the shared_index, as described in The reference to this uncompressed version is the shared_identifier,
Section 2. It must also indicate to the peer decompressor that this as described in Section 2. It must also indicate to its remote
compressed message's uncompressed version was saved as a state at the 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
Usually, signaling protocols (e.g. SIP) have the concept of sessions.
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
The concept of user-specific dictionary is based on the following
observation that for protocols such as SIP, a given user/device
combination will produce some messages containing fields that are
always populated with the same data.
Take SIP as an example, capabilities of the SIP endpoints
are communicated during session initiation, and do not tend to change
unless the device's capabilities change. Similarly, user-specific
information such as a user's URL, a user's name, and a user's e-mail
address likely won't change on frequent basis, and will appear
regularly in SIP signaling exchanges involving a specific user.
Therefore, a SigComp compressor could start uploading the user-
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
The following mechanisms can be used to recover from decompression
failure due to a reference to a non-exist state (i.e. not established
at all or has been deleted by the decompressor) or a corrupted state:
1) When a compressor sends a compressed message that will create new
decompression state on the decompressor side, it can set a CHK_PT bit
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. compressor.
When a decompressor receives a compressed message utilizing shared 2) When a decompressor encounters a decompression failure as
compression, the state indicated by state_index in the SigComp described above, it can send a rollback message to its remote
message is loaded to the UDVM. Thereafter the state indicated by compressor indicating such a failure. In addition, the rollback
shared_state is loaded to the UDVM. message may carry a list of state IDs of those checkpoint states that
are currently maintained by the decompressor. This is useful in the
case when the decompressor has to delete even checkpoint states due
to limited memory. When receiving such a rollback message, the
compressor MUST NOT use any state to compress subsequent messages
other than those explicitly listed in the rollback message or if the
list is empty, than those checkpoint states it stores locally and
have been acknowledged.
The shared state is loaded to the UDVM by setting the first_token to 5.6. Implicit deletion when creating a new state
the shared_pointer (a pointer at a defined position), which points to
the code that will insert the shared state into the "live dictionary" To achieve the maximum compression efficiency, a compressor may want
of the UDVM. The shared state data is copied into compressed_start to delete part (e.g. dictionary part) of byte buffer to make room for
and compressed_end is updated, and the UDVM is invoked. Then the new content. This is especially important when implementing
first_token is set to its previous value, and the message can be SigComp with limited memory (as in the case of a mobile terminal).
compressed by invoking the UDVM.
With the implicit deletion, some part(s) of the byte buffer are
chosen to be deleted according to a well defined algorithm that is
known and applied in the same way at both compressor and
decompressor. As input into the algorithm, one provides the total
size to be deleted (e.g. number of bytes), and the algorithm
specifies which part(s) are to be deleted. The freed room can then
allow new content to be added to the byte buffer. Since the same
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
writable UDVM memory defined by working_memory_start and
working_memory_end or only some parts of the writable UDVM memory. In
the latter case, it is assumed that the peer SigComp entities agree
on which parts the operation is applied to and the total size of
those parts.
6. Implications on SigComp 6. Implications on SigComp
The extended operations will have implication on the SigComp messages
sent between the compressor and the remote decompressor. It will also
have implications on the interface between the UDVM and its local
decompressor functionalities.
6.1. Implications on SigComp messages
For the support of the extended operation mechanisms, SigComp For the support of the extended operation mechanisms, SigComp
messages must be able to carry the indications and information messages must be able to carry the indications and information
addressed in Section 5. addressed in Section 5.
A decompressor that does not support the extended operations, must be The basic SigComp message has the following format:
able to derive the length of the information in a SigComp message,
which the peer compressor might have added for the extended operation
mechanisms, see [SIGCOMP]. In case that shared compression and/or
explicit acknowledgements are not supported the information is
discarded before the SigComp message is processed any further.
Figure 1, depicts a complete SigComp message, with the support of all
extended operation mechanisms. An Optimization of this message is
also shown and explained in Section 6.1.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| i | c | s | a | r | b |Reserv.| | |
: state_identifier (n-bytes) :
| |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: state_index (n-bytes) : Present if 'i' is set : Remaining UDVM bytecode :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 3. Format of basic SigComp message.
The content of the UDVM byte code is an implementation decision.
However, in the case of extended operations it should convey the
following information:
- The shared_identifier as described in Section 2, and Section 5.2,
MUST be conveyed when shared compression is applied.
- State identifiers of states that are acknowledged as successfully
saved by the decompressor, i.e. acked_identifiers.
Figure 4, depicts an example of what an extended basic SigComp
message, with the support of all extended operation mechanisms, could
look like. Note that this is only an example, the format is an
implementation decision.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | | |
: CRC : Present if 'c' is set : state_identifier (n-bytes) :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| s | a | r | b | Reserved |
+---+---+---+---+---+---+---+---+
| | | |
: shared_index (n-bytes) : Present if 's' is set : shared_identifier (n-bytes) : Present if 's' is set
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: acked_index (n-bytes) : Present if 'a' is set : acked_identifier (n-bytes) : Present if 'a' is set
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Possible | | Possible |
: Compressed data that should : : Compressed data :
| be given as input to the UDVM | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 1. SigComp message. Figure 4. Example of SigComp message for extended operations.
'r' : If set, then a state corresponding to the decompressed 'r' : If set, then a state corresponding to the decompressed
version of this compressed message was saved at the version of this compressed message was saved at the
compressor. compressor.
'b' : Explained in Section 6.1. 'b' : Explained in Section 6.2.3.
The CRC is calculated over the uncompressed message and can e.g. be
used for verification of successful decompression.
For the explanation of (n-bytes) see [SIGCOMP]. For the explanation of (n-bytes) see [SIGCOMP].
6.1. Acknowledgement optimization 6.2. Implications on the UDVM-decompressor interface
This interface is used to pass feedback information from the UDVM to
its local decompressor. The decompressor then forwards this
information on to the local compressor.
6.2.1. General SigComp feedback format
The general SigComp feedback information has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDVM_version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| overall_memory_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested feedback length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Requested feedback :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Returned feedback length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Returned feedback :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. High-level view of general SigComp feedback information.
For description of the items see [SigComp].
The following Section describes how the general feedback format is
used to provided extended operation mechanisms to basic sigComp.
6.2.2. Extended SigComp requested feedback format
The requested feedback is feedback from the UDVM to its remote
compressor. To make the extended acknowledgement scheme work, the
Requested feedback is filled with information on states that UDVM
requests the state handler to save. In case the state handler refuses
to save one or more of the indicated states, the feedback sent from
the compressor will be updated accordingly. The format of the
Requested feedback is of the following form:
The variable n specifies the number of state identifiers included in
the extended operations feedback format.
id_length (x) and id_values (x) corresponds to the same state.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_1 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_2 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_n :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Format of the Requested feedback.
6.2.2. Extended SigComp returned feedback format
The returned feedback is feedback from the remote endpoint to the
local compressor. The 'r' bit indicates that an uncompressed version
of the compressed 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.3. The format of the returned feedback is of
the following form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|b| n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_1 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_2 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_n :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. Format of the Returned feedback.
6.2.3. Acknowledgement optimization
This section describes an optimization for the case when shared This section describes an optimization for the case when shared
compression is used and an acknowledgement is piggybacked. compression is used and an acknowledgement is piggybacked.
Consider the following. Comp_1 sends a message M compressed, with Consider the following scenario. Comp_1 sends a message M compressed,
state(s0) to decomp_1. As comp_1 supports shared compression it saves with state(s0) to decomp_1. As comp_1 supports shared compression it
state(M), and sets bit 'r', to signal that state(M) can be used by saves state(M), and sets bit 'r', to signal that state(M) can be used
comp_2 in the compression process. by comp_2 in the compression process.
If decomp_1 saves state(s0+M) = state(s1), which is the new state of If decomp_1 saves state(s0+M) = state(s1), which is the new state of
the UDVM after decompression of M, then state(s1) can be implicitly the UDVM after decompression of M, then state(s1) can be implicitly
acknowledged, if comp_2 uses M for further compression. Comp_2 sets acknowledged, if comp_2 uses M for further compression. Comp_2 sets
the 'b' bit, which indicates that state(s0+M) is saved, which can be the 'b' bit, which indicates that state(s0+M) is saved, which can be
found from state(M), which is referenced by shared_index. This avoids found from state(M), which is referenced by shared_identifier. This
acked_index to be present in the SigComp message for state(s0+M). avoids acked_identifier to be present in the SigComp message for
state(s0+M).
Thus, a compressor that sets the 'r' bit should also hold a mapping Thus, a compressor that sets the 'r' bit should also hold a mapping
between state(M) and state(s0+M). between state(M) and state(s0+M).
Note: The only state that this feature acknowledges, is the state Note: The only state that this feature acknowledges, is the state
that was created by combining the state used for compression of the that was created by combining the state used for compression of the
shared message and the shared message itself. For any other case the shared message and the shared message itself. For any other case the
acked_index has to be used. acked_identifier has to be used.
6.2. Saving state information
There are some simple rules, which must be followed, when a state is
to be saved.
Decompressor
If there already exists a state for a state index, it must not be
replaced with the requested state to be saved. This is to avoid
that a compressed message cannot be decompressed because its state
has been replace with another one.
Compressor
If there already exists a state for a state index, generated by the
compressor, the compressor must not use that state for
compression of any later messages even if an acknowledgement for
this state is received. These states (state indexes) should be kept
for a reasonable amount of time to avoid that a state used by the
compressor is not actually the same as the one stored at the peer
decompressor, even though the state index is the same.
7. Security considerations 7. Security considerations
The features in this document are believed not to add any additional The features in this document are believed not to add any additional
security risks to the ones in [SIGCOMP] and [UDVM]. security risks to the ones in [SIGCOMP].
8. IANA considerations 8. IANA considerations
[Editors note: This section is TBW] [Editors note: This section is TBW]
9. Acknowledgements 9. Acknowledgements
[Editors note: This section is TBW] [Editors note: This section is TBW. Some names have been moved here
from the list of authors]
Thanks to
Carsten Bormann (cabo@tzi.org)
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.
10. Authors' addresses 10. Authors' addresses
Hans Hannu, Editor Hans Hannu
Phone: +46 920 20 21 84 Phone: +46 920 20 21 84
Fax: +46 920 20 20 99 Fax: +46 920 20 20 99
E-Mail: hans.hannu@epl.ericsson.se E-Mail: hans.hannu@epl.ericsson.se
Jan Christoffersson Jan Christoffersson
Phone: +46 920 20 28 40 Phone: +46 920 20 28 40
Fax: +46 920 20 20 99 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 Phone: +46 920 20 23 39
Fax: +46 920 20 20 99 Fax: +46 920 20 20 99
E-Mail: stefan.forsgren@epl.ericsson.se E-Mail: stefan.forsgren@epl.ericsson.se
Krister Svanbro
Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
E-Mail: krister.svanbro@epl.ericsson.se
Box 920 Box 920
Ericsson Erisoft AB Ericsson Erisoft AB
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Christopher Clanton
Phone: +1 972 894-4886
Fax: +1 972 894-4589
E-mail: christopher.clanton@nokia.com
Khiem Le
Phone: +1 972 894-4882
Fax: +1 972 894-4589
E-mail: khiem.le@nokia.com
Ka Cheong Leung Ka Cheong Leung
Phone: +1 972 374-0630 Phone: +1 972 374-0630
Fax: +1 972 894-4589 Fax: +1 972 894-4589
E-mail: kacheong.leung@nokia.com E-mail: kacheong.leung@nokia.com
Zhigang Liu Zhigang Liu
Phone: +1 972 894-5935 Phone: +1 972 894-5935
Fax: +1 972 894-4589 Fax: +1 972 894-4589
E-Mail: zhigang.liu@nokia.com E-Mail: zhigang.liu@nokia.com
skipping to change at page 11, line 30 skipping to change at page 15, line 29
6000 Connection Drive Irving, TX 75039, USA 6000 Connection Drive Irving, TX 75039, USA
Richard Price Richard Price
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 Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN Romsey, Hants, SO51 0ZN
United Kingdom United Kingdom
Jonathan Rosenberg
E-mail: jdrosen@dynamicsoft.com
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
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,
RFC 2543, Internet Engineering Task Force, March 1999
[SIGCOMP] H. Hannu et. al., Signaling Compression (SigComp), [SIGCOMP] H. Hannu et. al., Signaling Compression (SigComp),
Internet Draft (work in progress), January 2002. Internet Draft (work in progress), February 2002.
<draft-ietf-rohc-sigcomp-03.txt> <draft-ietf-rohc-sigcomp-04.txt>
[UDVM] R. Price et. al., Universal Decompressor Virtual Machine
(UDVM), Internet Draft (work in progress), January 2002.
<draft-ietf-rohc-sigcomp-udvm-00.txt>
This Internet-Draft expires in July 2002. 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].
This Internet-Draft expires in August 2002.
 End of changes. 

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