Network Working Group                                 H. Hannu, Ericsson
INTERNET-DRAFT                              J. Christoffersson, Ericsson
Expires: September November 2002                                       S. Forsgren. Ericsson Forsgren
                                                                K. Leung, Nokia Leung
                                                           Z. Liu, Nokia
                                            R. Price, Siemens/Roke Manor
                                                           March 1,
                                                            May 03, 2002

                      SigComp - Extended Operations
                <draft-ietf-rohc-sigcomp-extended-02.txt>
                <draft-ietf-rohc-sigcomp-extended-03.txt>

Status of this memo

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

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

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

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

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

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

Abstract

   This document defines extended operation describes mechanisms to be used with Signaling
   Compression (SigComp), RFC XXX, that significantly improve the
   compression efficiency compared to using per-message compression. The
   mechanisms, such as explicit acknowledgements and shared compression, for [SIGCOMP]. When these
   extended mechanisms are applied an increase of the compression
   efficiency is expected.
   are defined and explained in this document.

Table of contents

   1.  Introduction..................................................2  Introduction....................................................2
   2.  Terminology...................................................2  Terminology.....................................................2
   3.  Architectural view View of feedback................................4 Feedback..................................4
   4.  State reference model.........................................5 Reference Model...........................................4
   5.  Extended operation mechanisms.................................6 Mechanisms.............................................6
   6.  Implications on SigComp.......................................9 SigComp........................................11
   7.  Security considerations......................................13 Considerations........................................15
   8.  IANA considerations..........................................13 Considerations............................................15
   9.  Acknowledgements.............................................14  Acknowledgements...............................................15
   10. Authors' addresses...........................................14 Addresses.............................................15
   11. Intellectual Property Right Considerations...................15 Considerations.....................16
   12. References...................................................15
   Appendix A. Document history.....................................15 References.....................................................16

1. Introduction

   This document defines extended operation mechanisms, such as explicit
   acknowledgements and shared compression, for [SIGCOMP]. These describes how to implement mechanisms are expected with [SIGCOMP] to
   significantly improve the compression efficiency, efficiency compared to per-
   messages compression.

   One such mechanism is to use previously sent messages in the case 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 one SigComp is applied to protocols that are of
   request/response type, is shared compression. This involves using
   received messages in the communicating implementations
   only supports SigComp compression process. In particular
   the basic SigComp. 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 consult be familiar
   with the concept of [SIGCOMP].

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in reader should consult [SIGCOMP] for definitions of terminology,
   since this
   document are to be interpreted as described in [RFC-2119].

   Universal Decompressor Virtual Machine (UDVM)

     The virtual machine described in [SIGCOMP]. The UDVM draft uses the same terminology. Further terminology is
   defined below.

   Compressor

     Entity that encodes application messages using a certain
     compression algorithm and keeps track of state that can be used
     for
     decompression of SigComp messages.

   Decompressor compression. The decompressor compressor is responsible for ensuring that
     the messages it generates can be decompressed by the remote UDVM.

   Decompressor

     The decompressor is responsible for converting a SigComp message
     into uncompressed data. Decompression functionality is provided by
     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

   Dynamic compression

     Compression relative to messages sent prior to the remote decompressor in order for current
     compressed data to
     be decompressed. message.

   Explicit acknowledgements

     Is defined as the case where an acknowledgement

     Acknowledgement for a state that is explicitly sent from a
     decompressor to its remote compressor. The
     acknowledgment can either acknowledgement should
     be sent standalone or piggybacked with onto a SigComp message. message in order not to create
     additional security risks.

   Shared compression

     Compression relative to messages received by the local associated
     decompressor endpoint
     prior to the current compressed message.

   Dynamic

   Shared state

     A state used for shared compression

     Compression relative to messages sent prior to the current
     compressed message.

   Encoder

     Encodes data according to a (compression) algorithm into UDVM
     bytecode. The encoded data can be decoded by a UDVM.

   Application

     For the purpose consists only of this document, an application is a text-based
     protocol software that: invokes
     uncompressed message. This makes the SigComp compressor and
     decompressor.

   State

     Data saved for retrieval by later SigComp messages. An item of state typically reflects the contents independent of the UDVM memory after
     decompressing a message, but state can also be created by the
     compressor or by the application.
     compression algorithm.

   State identifier

     Reference used to access an item of state a previously created by the
     compressor, the decompressor or the application. item of state.

     - state_identifier

         This is a reference to a state, which shared_state_id

         State identifier of a compressor uses for
         compression. shared state.

     - shared_identifier

         This is a reference to a state, which consist only of an
         uncompressed message. This kind acked_state_id

         State identifier of a state that is necessary for
         efficient utilization of shared compression, acknowledged as remote
         compressors might use different compression algorithms.

     - acked_identifier

         This is a reference to a state, which is
         successfully saved and acknowledged by a the decompressor.

3. Architectural View of Feedback

   SigComp message

     May contain has a compressed application message in the form of UDVM
     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

     An uncompressed message, as provided from or to the application,
     which is to be compressed by the compressor. When delivered from
     the decompressor the data has passed through the decompression
     process and is referred request/response mechanism to as decompressed data.

3. Architectural view of feedback

   A SigComp endpoint may provide capability announcement information to
   its remote SigComp endpoint using the UDVM instruction END-MESSAGE.
   That feedback between
   endpoints, see Figure 1. This particular functionality of SigComp is
   used in this document to provide support for extended operation the 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. document.

       +--------------------+              +--------------------+
       |    Endpoint 1      |              |     Endpoint 2     |
       |  +--------------+  |              |  +--------------+  |
       |  | Compressor 1 |  |              |  |Decompressor 2|  |
       |  | [------------+--+--------------+--+--]   *       |  |
       |  +-|-------^----+  |              |  +--|---|-------+  |
       |    |       |       |              |     |   |          |
       |    |       |       |              |     |   |          |
       |    |       |       |              |     |   |          |
       |  +-|-------|----+  |              |  +--v---|-------+  |
       |  | *       [----+--+--------------+--+------]       |  |
       |  |Decompressor 1|  |              |  | Compressor 2 |  |
       |  +--------------+  |              |  +--------------+  |
       +--------------------+              +--------------------+
                Figure 1.  Architectural view
   This

   The feedback functionality of SigComp is extended used in this document to make it
   possible
   provide a mechanism for a SigComp endpoint to confirm which states that
   have been established to by its remote SigComp endpoint during the
   lifetime of a SigComp
   session. compartment. The established state
   confirmations are referred to as acknowledgments. Depending on the
   established states this particular type of feedback may or may not be
   used to increase the compression efficiency.

   The following Sections describes sections describe how the mechanism for SigComp functionality of
   providing the
   capability announcement feedback information is used for providing to support for
   some of the extended SigComp mechanisms
   described in this document. Section 4 starts by describing describes the State state reference
   model of SigComp. Section 5 continues with a general description of SigComp extended
   operation mechanisms,
   the mechanisms and Section 6 describes the implications on
   basic SigComp for of some of
   the extended mechanisms. mechanisms on basic SigComp.

4. State reference model Reference Model

   A UDVM may want to save the status of its memory memory, and this status is
   referred to as a state. As explained in [SIGCOMP] a state save
   request may or may not be granted. granted by the application. For later
   reference to a saved 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 a state identifier.

4.1. Overview of state reference State Reference with dynamic compression Dynamic Compression

   When compressor 1 compresses a message m it uses the information
   corresponding to a UDVM SigComp state that its remote decompressor 2 has
   established and acknowledged. If compressor 1 would like to be able wishes to use the new
   state for compression of later messages it must save the new state.
   The new state contains information from the former state and from m.
   When an acknowledgement is received for this new state, compressor 1
   can utilize the new state in the compression process. Below is an
   overview of the model. model together with an example of a message flow.

   Saved state(s)

     Compressor: The

     A state which is anticipated expected to be used for compression compression/decompression
     of later
     messages, and is therefore saved.

     Decompressor: The decompressor saves the state if it will
     acknowledge it. messages.

   Acked state(s)

     An acknowledged acked state is a saved state may be used for
     compression.

   Acked state(s)

     The which the compressor can only use a state(s) has
     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
     has saved and acknowledged. decompressor, otherwise a
     decompression failure will occur. For this reason, acknowledgements
     are necessary, at least for unreliable transport.

         Compressor 1                    Decompressor 2
           +---+                            +---+
           | C |                            | D |
           +---+                            +---+

     Saved       Acked    |            |   Saved
    State(s)    State(s)  |            |  State(s)
   -----------------------+------------+------------------
   s0             s0      |            |    s0
   s1=s0+m1               | --m1(s0)-->|
                          | <--ack(s1) |  s0,s1
   s0,s1        s0,s1     |            |
                          |            |
   s0,s1        s0,s1     | --m2(s1)-->|   (m2 Lost)
   s2=s1+m1               |            |
                          |            |
   s0-s2        s0,s1     |            |
   s3=s1+m3               | --m3(s1)-->|   s0,s1
                          |            |
                          |            |
                          | <--ack(s3) |   s0,s1,s3=s1+m3
   s0-s3       s0,s1,s3   |            |

                Figure 2. Example of message flow.

5. Extended operation mechanisms Mechanisms

   The following subsections give a general description for of the extended
   operation mechanisms and features, such as explicit acknowledgements
   and shared compression.
   mechanisms.

5.1. Explicit acknowledgement scheme Acknowledgement Scheme

   For a compressor to be able to utilize a certain state it must know
   that the remote decompressor has access to this state.

   In the case where compressed messages can be lost or misordered on
   the path between compressor and decompressor, some sort of an acknowledgement
   scheme must be used by a decompressor to notify the remote compressor that a certain
   state has been established.

   Explicit acknowledgements can be initiated either by UDVM-code
   uploaded to the decompressor by the remote compressor or by the
   endpoint where the states have been established. These two cases will
   be explained in more detail in the following two sections.

5.1.1. Remote Compressor Initiated Acknowledgements

   This is also
   needed in SigComp because the case when e.g. compressor 1 has uploaded UDVM memory is reset after each
   compressed message due to security risks, and also as a request bytecode to
   save a state may not be granted.

   A SigComp message
   decompressor 2. The UDVM bytecode will along with use the compressed message carry a
   reference to which state that was used for compression of requested feedback
   field in the
   message. This reference is announcement information and the state_identifier, as described returned feedback field
   in
   Section 2.

   Together with state_identifier the SigComp message may also carry an
   acknowledgement, which would be the acked_identifier, see Section header to obtain knowledge about established states at
   endpoint 2.
   The acknowledgement

   Consider Figure 3. An event flow for successful use of remote
   compressor initiated acknowledgements 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

   To allow for shared compression follows:

   (1): Compressor 1 saves e.g. state(A).
   (2): The UDVM bytecode to initiate a compressing endpoint MUST state save the
   uncompressed version of for state(A) is
        either carried in the compressed message as message, or can be retrieved by
        decompressor 2 from a state. 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
   reference 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

5.1.2. Local Endpoint Initiated Acknowledgements

   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:

   (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): 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.

   Note: When the requested feedback length is non-zero endpoint
   initiated acknowledgements should not be used, due to possible waste
   of bandwidth. When deciding to implement this mechanism one should
   consider whether this is worth the effort as all SigComp
   implementations will support the feedback mechanism and thus have the
   possibility to implement the mechanism of Section 5.1.1.

5.2. Shared Compression

   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_identifier, as
   described in Section 2. It shared
   state pushed existing state out of the state memory buffer).

   A compressing endpoint must also indicate to its the remote
   decompressor compressor
   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 is available, but only if the local
   decompressor MUST be able to can retrieve that particular the shared state. The retrieval of this particular the
   shared state is done according accordingly to the state retrieval instructions instruction
   of the UDVM.

   Consider Figure 3. An event flow for successful use of shared
   compression can be as follows:

   (1): Compressor 1 saves e.g. state(M), which is the uncompressed
        version of the current application message to be compressed and
        sent.
   (2): The UDVM bytecode to indicate the presence of state(M) at
        endpoint 1 is either carried in the compressed message, or can
        be retrieved by decompressor 2 from a state already saved at
        endpoint 2.
   (3): The SHA-1 instruction is used at endpoint 2 to calculate the
        shared_state_id for state(M). The indication is passed to the
        state handler, by placing the shared identifier at the location
        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): 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.

5.3. Maintaining state data across session State Data Across Application Sessions

   Usually, signaling protocols (e.g. SIP) have employ the concept of
   sessions. However, from the compression point of view, the messages
   sent by the same source contain redundancies beyond the 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 maintained, with the overhead amortized over a much
   longer period of time than one application session.

   Maintaining states across application sessions can be achieved
   simply by making the lifetime of a compartment longer than the
   time duration of a single application session. Note that the
   states here are referring to those stored on a per-compartment
   basis, not the locally available states that are stored on a global
   basis (i.e. not compartment specific).

5.4. Use of user-specific dictionary User-Specific Dictionary

   The concept of the 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 example. Capabilities of the SIP endpoints
   are communicated during session initiation, and do not tend not to change
   unless the device's capabilities of the device change.  Similarly, user-specific user-
   specific information such as a the user's URL, a user's name, and a user's e-mail address
   likely won't will not change on a frequent basis, and will appear
   regularly in SIP signaling exchanges involving a specific user.

   Therefore, a SigComp compressor could start uploading include the user-
   specific dictionary, user-specific
   dictionary as part of the initial state, messages to the
   decompressor decompressor, even
   before any time critical signaling messages are generated from a
   particular application . application. This enables the immediate
   compression/decompression increased compression efficiency
   once the messages start to flow.

   Obviously, the user-specific dictionary is a state item that would be
   good to have as a cross-session state: see Section 5.3.

5.5. Checkpoint state and rollback mechanism State

   The following mechanisms mechanism can be used to recover from avoid decompression failure
   due to a reference to a non-exist non-existent state. This may occur in three
   cases: a) a state (i.e. is not established at all or 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 by the decompressor) or a corrupted state:

   1)
   later due to insufficient memory.

   When a compressor sends a compressed SigComp message that will create a 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 state by setting
   state_retention_priority [SIGCOMP] to the highest value sent by the
   same compressor.  In addition, a checkpoint state means that must be explicitly
   acknowledged by the receiving decompressor
   SHOULD NOT delete it until to the sending compressor.

   Consider Figure 3. An event flow for this kind of state management
   can be as follows:

   (1): Compressor 1 saves e.g. state(A), which it would like to have as
        a checkpoint state at decompressor 2.
   (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 explicitly instructed -- by either carried in the
   compressor -- 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 do so. In addition, the checkpoint state MUST be
   explicitly acknowledged by the receiving decompressor to handler
        using the sending
   compressor.

   2) When a decompressor encounters a decompression failure as
   described above, it can send a rollback message to its remote
   compressor indicating such a failure. In addition, END-MESSAGE instruction, including the rollback
   message may carry a list indication of
        the state IDs priority. The application grants the saving of those
        state(A): see [SIGCOMP].
   (4): An acknowledgement for state(A) (the checkpoint states that
   are currently maintained by the decompressor. This state) is useful in the
   case when
        returned to endpoint B using one of the decompressor mechanisms described in
        Section 5.1.

   Note: To avoid using a state that has to delete even checkpoint states been deleted due to limited memory. When receiving such
   insufficient memory a rollback message, the compressor MUST NOT use any state to compress subsequent messages
   other than those explicitly listed in must keep track of the rollback message or if memory
   available for saving states at the
   list remote endpoint. The SigComp
   parameter state_memory_size which is empty, than those announced by the SigComp
   feedback mechanism can be used to infer if a previous checkpoint states it stores locally and
   have
   state has been acknowledged. deleted (by a later checkpoint state creation request)
   due to lack of memory.

5.6. Implicit deletion when creating Deletion for Dictionary Update

   Usually a new state consists of two parts: UDVM bytecode and dictionary.
   When dynamic compression is applied, new content needs to be added to
   the dictionary. To achieve keep an upper bound of the maximum compression efficiency, memory consumption such
   as in the case for a compressor may want
   to delete part (e.g. dictionary part) low end mobile terminal, existing content of byte buffer the
   dictionary must be deleted to make room for the new content.  This is especially important when implementing
   SigComp with limited memory (as in the case

   Instead of explicitly signaling which parts of a mobile terminal).

   With the dictionary need to
   be deleted on a per message basis, an implicit deletion, deletion approach may
   be applied. Specifically, some part(s) parts of the byte buffer dictionary are chosen to
   be deleted according to a well defined 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
   that is agreed between the two SigComp endpoints. As input into to
   the algorithm, one provides the total
   size to be deleted (e.g. number of bytes), and the bytes to be deleted.
   The algorithm then specifies which part(s) parts of dictionary 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
   endpoints, 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 explicit signaling
   information).

   For example, the implicit deletion on a per message
   basis. This may be applied lead to higher compression efficiency due to the entire
   writable UDVM memory defined by working_memory_start and
   working_memory_end or only some parts
   avoidance of the writable UDVM memory. In
   the latter case, it is assumed that the peer SigComp entities agree signaling overhead. It also means more robustness as
   there are no signaling bit on which parts the operation is applied wire that are subject to and the total size of
   those parts. possible
   transmission errors/losses.

6. Implications on SigComp

   The extended operations features will have implication implications on the SigComp messages
   sent between the compressor and the its remote decompressor. It will also
   have implications decompressor, and on how
   to interpret e.g. returned SigComp parameters [SIGCOMP]. However,
   except for the interface between mandatory bytes of the UDVM
   and its local decompressor functionalities. 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 effected affected, 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

   For the Messages

   To support of the extended operation mechanisms, shared
   compression and explicit acknowledgements, features, SigComp messages must be
   able to 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:

   - The acked_state_id as described in Sections
   5.1 2 and 5.2. 5.1.
   - The basic shared_state_id as described in Sections 2 and 5.2.

   Figure 4, depicts the format of a SigComp message has the following format: according to:
   [SIGCOMP]
     0   1   2   3   4   5   6   7       0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1 | T |  len  |   | 1   1   1   1   1 | T |   0   |
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   |                               |   |                               |
   :    returned feedback item     :   :    returned feedback item     :
   |                               |   |                               |
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   |                               |   |           code_len            |
   :   state_identifier (n-bytes)   partial state identifier    :   +---+---+---+---+---+---+---+---+
   |                               |   |   code_len    |  destination  |
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   |                               |   |                               |
   :   remaining SigComp message   :    Remaining   :    uploaded UDVM bytecode     :
   |                               |   |                               |
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
                                       |                               |
                                       :   remaining SigComp message   :
                                       |                               |
                                       +---+---+---+---+---+---+---+---+
                  Figure 3. 4. Format of basic a SigComp message.

   The content format of the UDVM byte code field "remaining SigComp message" is an
   implementation decision.
   However, in decision by the case of extended operations it should convey compressor which supplies the
   following information:

   - The shared_identifier as described in Section 2, and Section 5.2,
     MUST be conveyed when shared compression UDVM
   bytecode. Therefore there is applied.

   - State identifiers of states that are acknowledged as successfully
     saved by no need to specify a message format to
   carry the decompressor, i.e. acked_identifiers. information necessary for the extended features described
   in this document.

   Figure 4, 5, depicts an example of what an extended basic the "remaining SigComp
   message, message"
   with the support of for shared compression and explicit acknowledgements,
   could look like. Note that this is only an example, example; the format is an
   implementation decision.

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | Format according to Figure 4  |
   :  state_identifier (n-bytes)   except for the field called :
   |   "remaining SigComp message" |   "remaining SigComp message" field
   +---+---+---+---+---+---+---+---+             --------
   | s | a | r | b |    Reserved       |                |
   +---+---+---+---+---+---+---+---+                |
   |                               |                |
   : shared_identifier (n-bytes)       shared_state_id*        : Present if 's' is set
   |                               |                |
   +---+---+---+---+---+---+---+---+                |
   |                               |                |
   :  acked_identifier (n-bytes)       acked_state_id*         : Present if 'a' is set
   |                               |
   +---+---+---+---+---+---+---+---+
   |           Possible            |
   :        Compressed data        :
   |                               |
   +---+---+---+---+---+---+---+---+

   Figure 4. Example of SigComp message for extended operations.

   'r' : If set, then a state corresponding to the decompressed
         version of this compressed message was saved at the
         compressor.

   'b' : Explained in Section 6.2.2.

   For the explanation of (n-bytes) see [SIGCOMP].

6.2. SigComp capability announcement 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
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |          length           |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |       UDVM_version        |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |    overall_memory_size    |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |      cycles_per_bit       |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |    cycles_per_message     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |            n              |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |        id_length 1        |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |                           |
            :        id_value_1         :
            |                           |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     :         :
                     :         :
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |        id_length n        |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |                |
            :        id_value_n         :
   +---+---+---+---+---+---+---+---+                |
   |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |                |
   :         reserved  Rest of the SigComp message  :                |
   |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |                v
   +---+---+---+---+---+---+---+---+          --------------

   Figure 5. Example of SigComp capability announcement information

   For description message for some of the items see [SigComp]. extended
             features.

   'r' : If set, then a state corresponding to the decompressed
         version of this compressed message (shared state) was saved at
         the compressor.
   *   : The following Section length of the shared_state_id and acked_state_id fields
         are of the same length as the partial state identifier.

6.2. Extended SigComp Announcement/Feedback Format

   This section describes how the capability announcement "returned_SigComp_parameters"
   [SIGCOMP] information is interpreted to provide feedback according to
   Section 5.1 and 5.2.

6.2.1. Extended SigComp feedback format

   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 partial_state_identifiers correspond to the hash_length and hash_value for state(s) states
   that have been established at the remote end-
   point due to endpoint after received
   SigComp messages and may be used for
   compression, messages, i.e. these are acknowledgements for established states.
   states and may be used for compression. The 'r' bit indicates partial_state_identifiers
   may also announce "global state" 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 not mapped to any particular
   compartment and is of not established upon the
   following form:

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |          length           |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |       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 receipt of a SigComp
   message.

   It is up to the extended feedback.

   A implementation to deduce what kind of state each
   partial_state_identifier refers to, e.g. an acknowledged state or a
   shared state. In case a SigComp message that includes state
   identifiers for shared states and/or acknowledged states is received
   by a basic SigComp implementation implementation, these identifiers will be ignored.

   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 recognize set the identifier
   values I-bit to 1. The endpoint
   storing shared states and should not consider sending the reserved field in list of locally available
   states to its remote endpoint must be careful when taking the feedback
   location therefore it is not effected if it receives this kind
   decision whether to excluded or include different types of
   feedback.

6.2.2. Acknowledgement optimization

   Consider the following scenario, see
   locally available states (i.e. shared states or states of e.g. well-
   known algorithms) from/to the list.

6.3. Acknowledgement Optimization

   If shared compression is used between two endpoints (see Figure 1. Compressor 1 sends a 1)
   then there exists an optimization, which if implemented makes an
   acked_state_id in the SigComp message m, compressed with state s0, to decompressor 2. As unnecessary:

   Compressor 1 supports shared compression it saves a shared state(M), which is the uncompressed
   version of the current compressed message m as
   a state M, and (message m) to be sent.
   Compressor 1 also sets bit 'r', 'r' (see Figure 5), to signal that state M
   state(M) can be used by
   compressor endpoint 2 in the compression process.

   If decompressor_1 saves a new state, s1, using information in state
   s0 and m then this new state can The
   acked_state_id for state(S), which was created at endpoint 2 upon the
   decompression of message m, may not have to be implicitly acknowledged explicitly placed in case
   compressor 2 utilizes shared compression by using state M for further
   compression.

   The implicit acknowledgement is given by
   the compressed messages from compressor 2 which sets the
   'b' bit and if the shared identifier. The shared identifier indicates
   that the state M has been state(M) is
   used for compression together with the
   state indicated in the state_identifier. The 'b' bit indicates compression process.

   When endpoint 1 notices that
   state s1 has been saved at decompressor 2. That is, the 'b' bit and
   the shared identifier for M indicate state(M) is requested by
   decompressor 1, it implicitly knows that the state used state(S) was created at
   endpoint 2. This follows since:

   * Compressor 1 has instructed decompressor 2 to compress
   m together with the actual message m, save state(S).
   * The indication of shared state(M) would never have been saved as received by
     compressor 2 if state(S) had not been successfully saved, because
     if a new state
   (s1) at decompressor 2. This avoids the acked_identifier for state s1
   to be present in the SigComp message.

   Also, save request is denied then the compressor that sets corresponding
     announcement information is discarded by the 'r' bit should also hold state handler.

   Note: Endpoint 1's state handler must maintain a mapping between the state M
   state(M) and state s1. state(S) for this optimization to work.

   Note: The only state that acknowledge by this feature acknowledges, acknowledges is the
   state that was created by combining the state used for compression of
   the
   shared  message and the shared message itself. For any other case the
   acked_identifier
   acked_state_id has to be used.

   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.

7. Security considerations Considerations

   The features in this document are believed not to add any additional security
   risks to the ones mentioned in [SIGCOMP].

8. IANA considerations

   [Editor's note: TBW] Considerations

   This document does not require any IANA involvement.

9. Acknowledgements

   Thanks to Carsten Bormann (cabo@tzi.org) Bormann, Christopher Clanton (christopher.clanton@nokia.com) Clanton, Miguel Garcia (Miguel.A.Garcia@ericsson.com) Garcia,
   Lars-Erik Jonsson (lars-erik.jonsson@epl.ericsson.se) Jonsson, Khiem Le (khiem.le@nokia.com) Le, Mats Nordberg (mats.nordberg@epl.ericsson.se) Nordberg, Jonathan Rosenberg (jdrosen@dynamicsoft.com)
   and Krister Svanbro (krister.svanbro@epl.ericsson.se) for valuable input and review. input.

10. Authors' addresses Addresses

   Hans Hannu
   Box 920
   Ericsson AB
   SE-971 28 Lulea, Sweden

   Phone:  +46 920 20 21 84
   Fax:    +46 920 20 20 99
   E-Mail: hans.hannu@epl.ericsson.se

   Jan Christoffersson
   Box 920
   Ericsson AB
   SE-971 28 Lulea, Sweden

   Phone:  +46 920 20 28 40
   Fax:    +46 920 20 20 99
   E-Mail: jan.christoffersson@epl.ericsson.se

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

     Box 920
     Ericsson Erisoft AB
     SE-971 28 Lulea, Sweden stefan.forsgren@haggve.se

   Ka Cheong Leung
   Phone:  +1 972 374-0630
   Fax:    +1 972 894-4589
   E-mail: kacheong.leung@nokia.com kcleung@eee.hku.hk

   Zhigang Liu
   Phone:  +1 972 894-5935
   Fax:    +1 972 894-4589
   E-Mail: zhigang.liu@nokia.com
   Nokia Research Center
   6000 Connection Drive Irving, TX 75039, USA

   Phone:  +1 972 894-5935
   E-Mail: zhigang.liu@nokia.com
   Richard Price
   Phone:  +44 1794 833681
   E-mail: richard.price@roke.co.uk
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN 0ZN, United Kingdom
   Phone:  +44 1794 833681
   E-mail: richard.price@roke.co.uk

11. Intellectual Property Right Considerations

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

12. References

   [SIP]       M. Handley et. al., SIP: Session Initiation Protocol,
               RFC 2543, Internet Engineering Task Force, March 1999

   [SIGCOMP]   H. Hannu   R. Price et. al., Signaling Compression (SigComp),
               Internet Draft (work in progress), March May 2002.
               <draft-ietf-rohc-sigcomp-05.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].
               <draft-ietf-rohc-sigcomp-06.txt>

   This Internet-Draft expires in September November 03, 2002.