draft-ietf-rohc-sigcomp-extended-01.txt   draft-ietf-rohc-sigcomp-extended-02.txt 
Network Working Group H. Hannu, Ericsson Network Working Group H. Hannu, Ericsson
INTERNET-DRAFT J. Christoffersson, Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson
Expires: August 2002 S. Forsgren. Ericsson Expires: September 2002 S. Forsgren. Ericsson
K. Leung, Nokia K. Leung, Nokia
Z. Liu, Nokia Z. Liu, Nokia
R. Price, Siemens/Roke Manor R. Price, Siemens/Roke Manor
February 15, 2002 March 1, 2002
SigComp - Extended Operations SigComp - Extended Operations
<draft-ietf-rohc-sigcomp-extended-01.txt> <draft-ietf-rohc-sigcomp-extended-02.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 39 skipping to change at page 1, line 39
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@cdt.luth.se.
Abstract Abstract
This document defines extended operation mechanisms, explicit This document defines extended operation mechanisms, such as explicit
acknowledgements and shared compression, for [SIGCOMP]. When these acknowledgements and shared compression, for [SIGCOMP]. When these
extended mechanisms are applied an increase of the compression extended mechanisms are applied an increase of the compression
efficiency is expected. efficiency is expected.
Table of contents Table of contents
1. Introduction..................................................2 1. Introduction..................................................2
2. Terminology...................................................2 2. Terminology...................................................2
3. Architectural view for feedback...............................4 3. Architectural view of feedback................................4
4. State reference model.........................................5 4. State reference model.........................................5
5. Extended operation mechanisms.................................6 5. Extended operation mechanisms.................................6
6. Implications on SigComp.......................................9 6. Implications on SigComp.......................................9
7. Security considerations......................................14 7. Security considerations......................................13
8. IANA considerations..........................................14 8. IANA considerations..........................................13
9. Acknowledgements.............................................14 9. Acknowledgements.............................................14
10. Authors' addresses...........................................14 10. Authors' addresses...........................................14
11. Intellectual Property Right Considerations...................15 11. Intellectual Property Right Considerations...................15
12. References...................................................15 12. References...................................................15
Appendix A. Document history.....................................16 Appendix A. Document history.....................................15
1. Introduction 1. Introduction
This document defines extended operation mechanisms, explicit This document defines extended operation mechanisms, such as explicit
acknowledgements and shared compression, for [SIGCOMP]. These acknowledgements and shared compression, for [SIGCOMP]. These
mechanisms are expected to improve the compression efficiency, mechanisms are expected to improve the compression efficiency,
compared to the case when one of the communicating implementations compared to the case when one of the communicating implementations
only support the basic SigComp. only supports the basic 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 [SIGCOMP]. 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.
interoperating with a wide range of compression algorithms.
Decompressor Decompressor
The decompressor invokes the UDVM. It is responsible for supplying The decompressor is responsible for converting a SigComp message
the UDVM with compressed data and make decompressed data available into uncompressed data. Decompression functionality is provided by
for the application. the UDVM.
Compressor Compressor
The compressor invokes the encoder, and keeps track of states that The compressor invokes an encoder, and keeps track of states that
can be used for compression. Responsible for supplying UDVM can be used for compression. It is responsible for supplying UDVM
instructions to its remote decompressor in order for compressed bytecode to the remote decompressor in order for compressed data to
data to be decompressed. 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 its remote 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
Is defined as the case when a compressor uses data that has been Compression relative to messages received by the local associated
received by the associated decompressor. decompressor prior to the current compressed message.
Dynamic compression Dynamic compression
Is defined as the case when a compressor uses data, which are Compression relative to messages sent prior to the current
related to previous SigComp messages. compressed message.
Encoder Encoder
Encodes data according to a (compression) algorithm into UDVM Encodes data according to a (compression) algorithm into UDVM
readable code. The encoded data can be decoded by a UDVM provided bytecode. The encoded data can be decoded by a UDVM.
with the needed instructions.
Application Application
Invokes the SigComp compressor and decompressor. For the purpose of this document, an application is a text-based
protocol software that: invokes the SigComp compressor and
decompressor.
State State
Data saved either by a compressor or a decompressor. The data Data saved for retrieval by later SigComp messages. An item of
reflects the contents of a UDVM memory. state typically reflects the contents of the UDVM memory after
decompressing a message, but state can also be created by the
compressor or by the application.
State identifier State identifier
Reference to a state saved either by a compressor or a Reference used to access an item of state previously created by the
decompressor. compressor, the decompressor or the application.
- state_identifier - 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_identifier - 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 remote efficient utilization of shared compression, as remote
compressors might use different compression algorithms. compressors might use different compression algorithms.
- acked_identifier - acked_identifier
This is a reference to a state, which is acknowledged and saved This is a reference to a state, which is saved and acknowledged
by a decompressor. by a decompressor.
SigComp message SigComp message
May contain a compressed application message in the form of UDVM May contain a compressed application message in the form of UDVM
bytecode. In case of a message- based transport, such as UDP, a bytecode. In case of a message- based transport, such as UDP, a
SigComp message corresponds to exactly one (UDP) datagram. For a SigComp message corresponds to exactly one (UDP) datagram. For a
stream-based transport, such as TCP, each SigComp message is stream-based transport, such as TCP, each SigComp message is
separated by a 0xFFFF delimiter. separated by a 0xFFFF delimiter.
Application message Application message
An uncompressed message, as provided from or to the application, An uncompressed message, as provided from or to the application,
which is to be compressed by the compressor. When delivered which is to be compressed by the compressor. When delivered from
from the decompressor the data has passed through the decompression the decompressor the data has passed through the decompression
process and is referred to as decompressed data or a decompressed process and is referred to as decompressed data.
message.
3. Architectural view for feedback 3. Architectural view of feedback
A SigComp endpoint may provide feedback to its remote SigComp A SigComp endpoint may provide capability announcement information to
endpoint, see Figure 1. 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
a particular type of feedback, which an endpoint provides to its
remote endpoint, see Figure 1.
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Endpoint 1 | | Endpoint 2 | | Endpoint 1 | | Endpoint 2 |
| +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ |
| | Compressor | | | | Decompressor | | | | Compressor 1 | | | |Decompressor 2| |
| | [------------+--+--------------+--+--] * | | | | [------------+--+--------------+--+--] * | |
| +-|-------^----+ | | +--|---|-------+ | | +-|-------^----+ | | +--|---|-------+ |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| +-|-------|----+ | | +--v---|-------+ | | +-|-------|----+ | | +--v---|-------+ |
| | * [----+--+--------------+--+------] | | | | * [----+--+--------------+--+------] | |
| | Decompressor | | | | Compressor | | | |Decompressor 1| | | | Compressor 2 | |
| +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 1. Architectural view Figure 1. Architectural view
This functionality of SigComp is extended in this document to make it
With the extended feedback format specified in Section 6, it is
possible for a SigComp endpoint to confirm which states that have possible for a SigComp endpoint to confirm which states that have
been established to its remote SigComp endpoint. The established been established to its remote SigComp endpoint during the SigComp
state confirmations are referred to as acknowledgments. 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.
Depending on the established states this particular type of feedback The following Sections describes how the mechanism for providing the
may be used to increase the compression efficiency. capability announcement information is used for providing support for
some of the extended SigComp mechanisms described in this document.
Section 4 starts by describing the State reference model of SigComp.
Section 5 continues with a general description of SigComp extended
operation mechanisms, and Section 6 describes the implications on
basic SigComp for some of the extended mechanisms.
4. State reference model 4. State reference model
A UDVM may want to save the status of its memory and this status is 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 save state 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. For later reference to a saved
state, e.g. if the UDVM is to be loaded with this state, a reference state, e.g. if the UDVM is to be loaded with this state, a reference
is needed to locate the specific state. This reference is called is needed to locate the specific state. This reference is called
state identifier. 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 compresses a message m it uses the information
information corresponding to a UDVM state that its remote corresponding to a UDVM state that its remote decompressor 2 has
decompressor (decomp_2) has established and acknowledged. If comp_1 established and acknowledged. If compressor 1 would like to be able
decides that it for compression of later messages would like to be to use the new state for compression of later messages it must save
able to use the new state, which is the former state with the the new state. The new state contains information from the former
addition of information from M, it must save the new state. If an state and m. When an acknowledgement is received for this new state,
acknowledgement is received for this new state, comp_1 can utilize compressor 1 can utilize the new state in the compression process.
the new state in the compression process. Below is an overview of the Below is an overview of the model.
model.
Available state(s) Saved 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 remote decompressor The compressor can only use a state(s) that the remote decompressor
has saved and acknowledged. has saved and acknowledged.
Compressor 1 Decompressor 2 Compressor 1 Decompressor 2
+---+ +---+ +---+ +---+
| C | | D | | C | | D |
+---+ +---+ +---+ +---+
Available Acked | | Available Saved Acked | | Saved
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
s0,s1 s0,s1 | | s0,s1 s0,s1 | |
| | | |
s0,s1 s0,s1 | --m2(s1)-->| (m2 Lost) s0,s1 s0,s1 | --m2(s1)-->| (m2 Lost)
s2=s1+m1 | | s2=s1+m1 | |
| | | |
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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 operation mechanisms
The following subsections give a general description for the extended
operation mechanisms and features, such as explicit acknowledgements
and shared compression.
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 case where compressed messages can be lost or misordered on the In the case where compressed messages can be lost or misordered on
path between compressor and decompressor, some sort of the path between compressor and decompressor, some sort of
acknowledgement must be used by a decompressor to notify the remote 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. This is also
Over reliable and ordered transport the most recent state may be needed in SigComp because the UDVM memory is reset after each
used, if the compressor has downloaded such a UDVM instruction code compressed message due to security risks, and also as a request to
to its remote decompressor. save a state may not be granted.
The following subsections describe how an explicit acknowledgement
scheme and shared compression can be applied in SigComp.
5.1. Explicit acknowledgement scheme
A SigComp message will along with the compressed message carry a A SigComp message will along with the compressed message carry a
reference to which state that was used for compression of the reference to which state that was used for compression of the
message. This reference is the state_identifier, as described in message. This reference is the state_identifier, as described in
Section 2. Section 2.
Together with state_identifier the SigComp message may also carry an Together with state_identifier the SigComp message may also carry an
acknowledgement, which would be the acked_identifier, see Section 2. acknowledgement, which would be the acked_identifier, see Section 2.
The acknowledgement can be either standalone or piggybacked. For The acknowledgement can be either standalone or piggybacked. For
security reasons as explained in SigComp it is RECOMMENDED that this security reasons as explained in SigComp it is RECOMMENDED that this
particular feedback is piggybacked and not sent standalone. particular feedback is piggybacked and not sent standalone.
5.2. Shared Compression 5.2. Shared Compression
To allow for shared compression a compressing endpoint MUST save a To allow for shared compression a compressing endpoint MUST save the
state, which is the uncompressed version of the compressed message. uncompressed version of the compressed message as a state. The
The reference to this uncompressed version is the shared_identifier, reference to this uncompressed version is the shared_identifier, as
as described in Section 2. It must also indicate to its remote described in Section 2. It must also indicate to its remote
decompressor that this compressed message's uncompressed version was decompressor that this compressed message's uncompressed version was
saved as a state at the compressor. If a compressing endpoint saved as a state at the compressor. If a compressing endpoint
indicates that a shared compression state was saved, its local indicates that a shared compression state was saved, its local
decompressor MUST be able to retrieve that particular state. decompressor MUST be able to retrieve that particular state.
The retrieval of this particular state is done according to the state The retrieval of this particular state is done according to the state
retrieval instructions of the UDVM. retrieval instructions of the UDVM.
5.3. Maintaining state data across session 5.3. Maintaining state data across session
Usually, signaling protocols (e.g. SIP) have the concept of sessions. Usually, signaling protocols (e.g. SIP) have the concept of sessions.
skipping to change at page 9, line 16 skipping to change at page 9, line 16
writable UDVM memory defined by working_memory_start and writable UDVM memory defined by working_memory_start and
working_memory_end or only some parts of the writable UDVM memory. In 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 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 on which parts the operation is applied to and the total size of
those parts. those parts.
6. Implications on SigComp 6. Implications on SigComp
The extended operations will have implication on the SigComp messages The extended operations will have implication on the SigComp messages
sent between the compressor and the remote decompressor. It will also sent between the compressor and the remote decompressor. It will also
have implications on the interface between the UDVM and its local have implications on how to interpret the interface between the UDVM
decompressor functionalities. and its local decompressor functionalities.
Note that an implementation that does not make use of explicit
acknowledgements and/or shared compression is not effected even if it
receives this kind of feedback.
The following sections described the implications due to explicit
acknowledgements and shared compression.
6.1. Implications on SigComp messages 6.1. Implications on SigComp messages
For the support of the extended operation mechanisms, SigComp For the support of the extended operation mechanisms, shared
messages must be able to carry the indications and information compression and explicit acknowledgements, SigComp messages must be
addressed in Section 5. able to carry the indications and information addressed in Sections
5.1 and 5.2.
The basic SigComp message has the following format: The basic SigComp message has the following format:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: state_identifier (n-bytes) : : state_identifier (n-bytes) :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
skipping to change at page 9, line 51 skipping to change at page 10, line 9
However, in the case of extended operations it should convey the However, in the case of extended operations it should convey the
following information: following information:
- The shared_identifier as described in Section 2, and Section 5.2, - The shared_identifier as described in Section 2, and Section 5.2,
MUST be conveyed when shared compression is applied. MUST be conveyed when shared compression is applied.
- State identifiers of states that are acknowledged as successfully - State identifiers of states that are acknowledged as successfully
saved by the decompressor, i.e. acked_identifiers. saved by the decompressor, i.e. acked_identifiers.
Figure 4, depicts an example of what an extended basic SigComp Figure 4, depicts an example of what an extended basic SigComp
message, with the support of all extended operation mechanisms, could message, with the support of shared compression and explicit
look like. Note that this is only an example, the format is an acknowledgements, could look like. Note that this is only an example,
implementation decision. the format is an implementation decision.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: state_identifier (n-bytes) : : state_identifier (n-bytes) :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| s | a | r | b | Reserved | | s | a | r | b | Reserved |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
skipping to change at page 10, line 32 skipping to change at page 10, line 40
: Compressed data : : Compressed data :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 4. Example of SigComp message for extended operations. 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.2.3. 'b' : Explained in Section 6.2.2.
For the explanation of (n-bytes) see [SIGCOMP]. For the explanation of (n-bytes) see [SIGCOMP].
6.2. Implications on the UDVM-decompressor interface 6.2. SigComp capability announcement format
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:
The SigComp capability announcement information mechanisms is, as
explained in Section 3, used to provide the support for shared
compression and explicit acknowledgements. The following format is
specified in SigComp and is made available to the compressor by the
UDVM instruction END-MESSAGE
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total length | | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDVM_version | | UDVM_version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| overall_memory_size | | overall_memory_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_bit | | cycles_per_bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_message | | 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 | | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 1 | | id_length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: id_value_1 : : id_value_1 :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: id_value_2 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length n | | id_length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: id_value_n : : id_value_n :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: reserved :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Format of the Requested feedback. Figure 5. SigComp capability announcement information
6.2.2. Extended SigComp returned feedback format For description of the items see [SigComp].
The returned feedback is feedback from the remote endpoint to the The following Section describes how the capability announcement
local compressor. The 'r' bit indicates that an uncompressed version information is interpreted to provide feedback according to Section
of the compressed message sent in this message has been saved at the 5.1 and 5.2.
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 6.2.1. Extended SigComp feedback format
the following form:
When a SigComp message is not regarded as a capability announcement
message, the END-MESSAGE instruction does not actually point to the
capability announcement location but rather to a feedback location
with the feedback format block as depicted in Figure 7. The
id_length(s) and id_value(s) corresponds to the hash_length and
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
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|b| n | | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 1 | | UDVM_version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | overall_memory_size |
: id_value_1 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 2 | | cycles_per_bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: id_value_2 : : id_value_1 :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id_length n | | id_length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: id_value_n : : id_value_n :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|b| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: reserved :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. Format of the Returned feedback. Figure 7. Format of the extended feedback.
6.2.3. Acknowledgement optimization A basic SigComp implementation will not recognize the identifier
values and should not consider the reserved field in the feedback
location therefore it is not effected if it receives this kind of
feedback.
This section describes an optimization for the case when shared 6.2.2. Acknowledgement optimization
compression is used and an acknowledgement is piggybacked.
Consider the following scenario. Comp_1 sends a message M compressed, Consider the following scenario, see Figure 1. Compressor 1 sends a
with state(s0) to decomp_1. As comp_1 supports shared compression it message m, compressed with state s0, to decompressor 2. As Compressor
saves state(M), and sets bit 'r', to signal that state(M) can be used 1 supports shared compression it saves the uncompressed message m as
by comp_2 in the compression process. a state M, and sets bit 'r', to signal that state M can be used by
compressor 2 in the compression process.
If decomp_1 saves state(s0+M) = state(s1), which is the new state of If decompressor_1 saves a new state, s1, using information in state
the UDVM after decompression of M, then state(s1) can be implicitly s0 and m then this new state can be implicitly acknowledged in case
acknowledged, if comp_2 uses M for further compression. Comp_2 sets compressor 2 utilizes shared compression by using state M for further
the 'b' bit, which indicates that state(s0+M) is saved, which can be compression.
found from state(M), which is referenced by shared_identifier. This
avoids acked_identifier to be present in the SigComp message for The implicit acknowledgement is given by compressor 2 which sets the
state(s0+M). 'b' bit and the shared identifier. The shared identifier indicates
Thus, a compressor that sets the 'r' bit should also hold a mapping that the state M has been used for compression together with the
between state(M) and state(s0+M). state indicated in the state_identifier. The 'b' bit indicates that
state s1 has been saved at decompressor 2. That is, the 'b' bit and
the shared identifier for M indicate that the state used to compress
m together with the actual message m, have been saved as a new state
(s1) at decompressor 2. This avoids the acked_identifier for state s1
to be present in the SigComp message.
Also, the compressor that sets the 'r' bit should also hold a mapping
between the state M and state s1.
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_identifier has to be used. acked_identifier has to be used.
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]. security risks to the ones in [SIGCOMP].
8. IANA considerations 8. IANA considerations
[Editors note: This section is TBW] [Editor's note: TBW]
9. Acknowledgements 9. Acknowledgements
[Editors note: This section is TBW. Some names have been moved here
from the list of authors]
Thanks to Thanks to
Carsten Bormann (cabo@tzi.org) Carsten Bormann (cabo@tzi.org)
Christopher Clanton (christopher.clanton@nokia.com) Christopher Clanton (christopher.clanton@nokia.com)
Miguel Garcia (Miguel.A.Garcia@ericsson.com) Miguel Garcia (Miguel.A.Garcia@ericsson.com)
Lars-Erik Jonsson (lars-erik.jonsson@epl.ericsson.se) Lars-Erik Jonsson (lars-erik.jonsson@epl.ericsson.se)
Khiem Le (khiem.le@nokia.com) Khiem Le (khiem.le@nokia.com)
Mats Nordberg (mats.nordberg@epl.ericsson.se) Mats Nordberg (mats.nordberg@epl.ericsson.se)
Jonathan Rosenberg (jdrosen@dynamicsoft.com) Jonathan Rosenberg (jdrosen@dynamicsoft.com)
Krister Svanbro (krister.svanbro@epl.ericsson.se) Krister Svanbro (krister.svanbro@epl.ericsson.se)
skipping to change at page 15, line 42 skipping to change at page 15, line 25
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] 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] H. Hannu et. al., Signaling Compression (SigComp),
Internet Draft (work in progress), February 2002. Internet Draft (work in progress), March 2002.
<draft-ietf-rohc-sigcomp-04.txt> <draft-ietf-rohc-sigcomp-05.txt>
Appendix A. Document history Appendix A. Document history
- January 28, 2002, version 00 - January 28, 2002, version 00
First version. This draft describes the extended operation First version. This draft describes the extended operation
mechanisms, explicit acknowledgements and shared compression from mechanisms, explicit acknowledgements and shared compression from
draft-ietf-rohc-sigcomp-02.txt. draft-ietf-rohc-sigcomp-02.txt.
- February 15, 2002, version 01 - February 15, 2002, version 01
Second version. Updated to reflect the changes made in [SIGCOMP]. Second version. Updated to reflect the changes made in SigComp-04.
This Internet-Draft expires in August 2002. - March 1, 2002, version 02
Third version. Updated to reflect the changes made in [SIGCOMP].
This Internet-Draft expires in September 2002.
 End of changes. 

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