[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 RFC 3321

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

                      SigComp - Extended Operations

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

   The list of Internet-Draft Shadow Directories can be accessed at

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


   This document defines extended operation mechanisms, such as explicit
   acknowledgements and shared compression, for [SIGCOMP]. When these
   extended mechanisms are applied an increase of the compression
   efficiency is expected.

Hannu, et al.                                                   [Page 1]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

Table of contents

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

1. Introduction

   This document defines extended operation mechanisms, such as explicit
   acknowledgements and shared compression, for [SIGCOMP]. These
   mechanisms are expected to improve the compression efficiency,
   compared to the case when one of the communicating implementations
   only supports the basic SigComp.

   For better understanding of this draft the reader should consult

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC-2119].

   Universal Decompressor Virtual Machine (UDVM)

     The virtual machine described in [SIGCOMP]. The UDVM is used for
     decompression of SigComp messages.


     The decompressor is responsible for converting a SigComp message
     into uncompressed data. Decompression functionality is provided by
     the UDVM.


     The compressor invokes an encoder, and keeps track of states that
     can be used for compression. It is responsible for supplying UDVM
     bytecode to the remote decompressor in order for compressed data to

Hannu, et al.                                                   [Page 2]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

     be decompressed.

   Explicit acknowledgements

     Is defined as the case where an acknowledgement for a state is
     explicitly sent from a decompressor to its remote compressor. The
     acknowledgment can either be sent standalone or piggybacked with a
     SigComp message.

   Shared compression

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

   Dynamic compression

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


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


     For the purpose of this document, an application is a text-based
     protocol software that: invokes the SigComp compressor and


     Data saved for retrieval by later SigComp messages. An item of
     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

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

     - state_identifier

         This is a reference to a state, which a compressor uses for

     - shared_identifier

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

Hannu, et al.                                                   [Page 3]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

         efficient utilization of shared compression, as remote
         compressors might use different compression algorithms.

     - acked_identifier

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

   SigComp message

     May contain a compressed application message in the form of UDVM
     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 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 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     |
       |  +--------------+  |              |  +--------------+  |
       |  | Compressor 1 |  |              |  |Decompressor 2|  |
       |  | [------------+--+--------------+--+--]   *       |  |
       |  +-|-------^----+  |              |  +--|---|-------+  |
       |    |       |       |              |     |   |          |
       |    |       |       |              |     |   |          |
       |    |       |       |              |     |   |          |
       |  +-|-------|----+  |              |  +--v---|-------+  |
       |  | *       [----+--+--------------+--+------]       |  |
       |  |Decompressor 1|  |              |  | Compressor 2 |  |
       |  +--------------+  |              |  +--------------+  |
       +--------------------+              +--------------------+
                Figure 1.  Architectural view

Hannu, et al.                                                   [Page 4]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

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

   The following Sections describes how the mechanism for providing the
   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

   A UDVM may want to save the status of its memory and this status is
   referred to as a state. As explained in [SIGCOMP] a state save
   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
   is needed to locate the specific state. This reference is called
   state identifier.

4.1. Overview of state reference with dynamic compression

   When compressor 1 compresses a message m it uses the information
   corresponding to a UDVM state that its remote decompressor 2 has
   established and acknowledged. If compressor 1 would like to be able
   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 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.

   Saved state(s)

     Compressor: The state is anticipated for compression of later
     messages, and is therefore saved.

     Decompressor: The decompressor saves the state if it will
     acknowledge it. An acknowledged state may be used for

   Acked state(s)

     The compressor can only use a state(s) that the remote decompressor
     has saved and acknowledged.

Hannu, et al.                                                   [Page 5]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

         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

   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
   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
   acknowledgement must be used by a decompressor to notify the remote
   compressor that a certain state has been established. This is also
   needed in SigComp because the UDVM memory is reset after each
   compressed message due to security risks, and also as a request to
   save a state may not be granted.

   A SigComp message will along with the compressed message carry a
   reference to which state that was used for compression of the
   message. This reference is the state_identifier, as described in
   Section 2.

Hannu, et al.                                                   [Page 6]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

   Together with state_identifier the SigComp message may also carry an
   acknowledgement, which would be the acked_identifier, see Section 2.
   The acknowledgement can be either standalone or piggybacked. For
   security reasons as explained in SigComp it is RECOMMENDED that this
   particular feedback is piggybacked and not sent standalone.

5.2. Shared Compression

   To allow for shared compression a compressing endpoint MUST save the
   uncompressed version of the compressed message as a state. The
   reference to this uncompressed version is the shared_identifier, as
   described in Section 2. It must also indicate to its remote
   decompressor that this compressed message's uncompressed version was
   saved as a state at the compressor. If a compressing endpoint
   indicates that a shared compression state was saved, its local
   decompressor MUST be able to retrieve that particular state.
   The retrieval of this particular state is done according to the state
   retrieval instructions of the UDVM.

5.3. Maintaining state data across session

   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.

Hannu, et al.                                                   [Page 7]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

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

   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, the rollback
   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.

5.6. Implicit deletion when creating a new state

   To achieve the maximum compression efficiency, a compressor may want
   to delete part (e.g. dictionary part) of byte buffer to make room for
   the new content.  This is especially important when implementing
   SigComp with limited memory (as in the case of a mobile terminal).

   With the implicit deletion, some part(s) of the byte buffer are
   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

Hannu, et al.                                                   [Page 8]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

   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

   The extended operations will have implication on the SigComp messages
   sent between the compressor and the remote decompressor. It will also
   have implications on how to interpret the interface between the UDVM
   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

   For the support of the extended operation mechanisms, shared
   compression and explicit acknowledgements, SigComp messages must be
   able to carry the indications and information addressed in Sections
   5.1 and 5.2.

   The basic SigComp message has the following format:

        0   1   2   3   4   5   6   7
      |                               |
      :   state_identifier (n-bytes)  :
      |                               |
      |                               |
      :    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.

Hannu, et al.                                                   [Page 9]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

   - 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 shared compression and explicit
   acknowledgements, could look like. Note that this is only an example,
   the format is an implementation decision.

     0   1   2   3   4   5   6   7
   |                               |
   :  state_identifier (n-bytes)   :
   |                               |
   | s | a | r | b |   Reserved    |
   |                               |
   : shared_identifier (n-bytes)   : Present if 's' is set
   |                               |
   |                               |
   :  acked_identifier (n-bytes)   : 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

   '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

Hannu, et al.                                                  [Page 10]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

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

   Figure 5. SigComp capability announcement information

   For description of the items see [SigComp].

   The following Section describes how the capability announcement
   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 to the hash_length and
   hash_value for state(s) that have been established at the remote end-

Hannu, et al.                                                  [Page 11]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

   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:

            |          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 of the extended feedback.

   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

Hannu, et al.                                                  [Page 12]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

6.2.2. Acknowledgement optimization

   Consider the following scenario, see Figure 1. Compressor 1 sends a
   message m, compressed with state s0, to decompressor 2. As Compressor
   1 supports shared compression it saves the uncompressed message m as
   a state M, and sets bit 'r', to signal that state M can be used by
   compressor 2 in the compression process.

   If decompressor_1 saves a new state, s1, using information in state
   s0 and m then this new state can be implicitly acknowledged in case
   compressor 2 utilizes shared compression by using state M for further

   The implicit acknowledgement is given by compressor 2 which sets the
   'b' bit and the shared identifier. The shared identifier indicates
   that the state M has been used for compression together with the
   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
   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 has to be used.

7. Security considerations

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

8. IANA considerations

   [Editor's note: TBW]

Hannu, et al.                                                  [Page 13]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

9. Acknowledgements

   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

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

   Jan Christoffersson
   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

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

   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

Hannu, et al.                                                  [Page 14]

INTERNET-DRAFT       SigComp - Extended Operations        March 1, 2002

   Richard Price
   Phone:  +44 1794 833681
   E-mail: richard.price@roke.co.uk

     Roke Manor Research Ltd
     Romsey, Hants, SO51 0ZN
     United Kingdom

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

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),
               Internet Draft (work in progress), March 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

   - February 15, 2002, version 01

      Second version. Updated to reflect the changes made in SigComp-04.

   - March 1, 2002, version 02

      Third version. Updated to reflect the changes made in [SIGCOMP].

   This Internet-Draft expires in September 2002.

Hannu, et al.                                                  [Page 15]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/