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

Versions: 00 01 02 03 RFC 3321

Network Working Group                        H. Hannu (Editor), Ericsson
INTERNET-DRAFT                              J. Christoffersson, Ericsson
Expires: July 2002                                     C. Clanton, Nokia
                                                   S. Forsgren. Ericsson
                                                            K. Le, Nokia
                                                         K. Leung, Nokia
                                                           Z. Liu, Nokia
                                            R. Price, Siemens/Roke Manor
                                               J. Rosenberg, Dynamicsoft
                                                    K. Svanbro, Ericsson
                                                        January 28, 2002



                     SigComp - Extended Operations
               <draft-ietf-rohc-sigcomp-extended-00.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.


Abstract

   This document defines extended operation mechanisms, explicit
   acknowledgements and shared compression, for [SIGCOMP]. When
   extended SigComp implementations communicate an increase of the
   compression efficiency is expected.





Hannu, et al.                                                   [Page 1]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


0. Document History

   - January 28, 2002, version 00

      First version. This draft describes the extended operation
      mechanisms, explicit acknowledgements and shared compression from
      draft-ietf-rohc-sigcomp-02.txt.


Table of contents

   1.  Introduction..................................................2
   2.  Terminology...................................................2
   3.  The Extended SigComp Architecture.............................4
   4.  State reference model.........................................5
   4.1.  Overview of state reference with dynamic compression........6
   5.  Extended operation mechanisms.................................7
   5.1.  Explicit acknowledgement scheme.............................7
   5.2.  Shared Compression..........................................7
   6.  Implications on SigComp.......................................8
   6.1.  Acknowledgement optimization................................9
   6.2.  Saving state information....................................9
   7.  Security considerations......................................10
   8.  IANA considerations..........................................10
   9.  Acknowledgements.............................................10
   10. Authors' addresses...........................................10
   11. Intellectual Property Right Considerations...................11
   12. References...................................................11


1. Introduction

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

   For better understanding of this draft the reader should consult
   [SIGCOMP].


2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].







Hannu, et al.                                                   [Page 2]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


   Universal Decompressor Virtual Machine (UDVM)

     The virtual machine described in [UDVM]. The UDVM is used for
     decompression of SigComp messages. The UDVM is capable of
     interoperating with a wide range of compression algorithms.

   Decompressor

     The decompressor invokes the UDVM. It is responsible for supplying
     the UDVM with compressed data and make decompressed data available
     for the application.

   Compressor

     The compressor invokes the encoder, and keeps track of states that
     can be used for compression. Responsible for supplying UDVM
     instructions to the peer decompressor in order for compressed
     data to be decompressed.

   Explicit acknowledgements

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

   Shared compression

     Is defined as the case when a compressor uses data that has been
     received by the associated decompressor.

   Dynamic compression

     Is defined as the case when a compressor uses data, which are
     related to previous SigComp messages.

   Encoder

     Encodes data according to a (compression) algorithm into UDVM
     readable code. The encoded data can be decoded by a UDVM provided
     with the needed instructions.

   Application

     Invokes the SigComp compressor and decompressor.

   State

     Data saved either by a compressor or a decompressor. The data
     reflects the contents of a UDVM memory.





Hannu, et al.                                                   [Page 3]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


   State index

     Reference to a state saved either by a compressor or a
     decompressor.

     - state_index

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

     -  shared_index

          This is a reference to a state, which consist only of an
          uncompressed message. This kind of state is necessary for
          efficient utilization of shared compression, as peer
          compressors might use different compression algorithms.

     - acked_index

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

   SigComp message

     In case of a message oriented transport mechanism, such as UDP, a
     SigComp message corresponds to exactly one (UDP) packet. For a
     stream oriented transport, such as TCP, each SigComp message is
     separated by a 0xFFFF delimiter, see [UDVM].

   Application data (message)

     Data, also referred to as message, 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 or decompressed message.


3. The Extended SigComp Architecture

   Compression and decompression is performed at two communicating end-
   points, see Figure 1.














Hannu, et al.                                                   [Page 4]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


          +--------------------+                 +--------------------+
          |    Compressor 1    |                 |    Decompressor 1  |
          |    +---------+     |                 |     +---------+    |
          |    | Encoder |     |                 |     |  UDVM   |    |
          |    +---------+     |                 |     +---------+    |
          +--------------------+                 +--------------------+
            ^  ^   App. ^    |                     ^     | App.  ^  |
            |  |   data |    |                     |     v data  |  v
          +-|--|-------------|-+                 +-|-------------|--|-+
          | |  |             | |     SigComp     | |             |  | |
          |[E] | Application v |     message     | | Application |  | |
          | |  v             +---------->----------+             v  | |
          | | +-------+        |                 |        +-------+ | |
          | | | State |        | Data transport  |        | State | | |
          | | +-------+        |                 |        +-------+ | |
          | |  ^             +----------<----------+             ^  | |
          | |  |             | |     SigComp     | ^             | [E]|
          | |  |             | |     message     | |             |  | |
          +-|--|-------------|-+                 +-|-------------|--|-+
            ^  |   App. ^    |                     |     | App.  |  |
            |  v   data |    v                     |     v data  v  v
          +--------------------+                 +--------------------+
          |   Decompressor 2   |                 |     Compressor 2   |
          |    +---------+     |                 |     +---------+    |
          |    |  UDVM   |     |                 |     | Encoder |    |
          |    +---------+     |                 |     +---------+    |
          +--------------------+                 +--------------------+

   Figure 1.  Extended SigComp High-level view.


   The difference between SigComp and extended SigComp is the
   availability of "interface" E (symbol [E]). With the extended
   operation, explicit acknowledgements (symbol [E]), it is possible for
   e.g. decompressor 1 to inform compressor 1 about states that have
   been established at decompressor 1. Compressor 1 can then use these
   states in the compression process. Depending on the established
   states, this is expected to increase the compression efficiency. See
   Section 6 for the extended SigComp message format.


4. State reference model

   A UDVM [UDVM] may want to save the status of its memory. This status
   is referred to as a state. The decompressor may allow the state to be
   saved. For later reference to this 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 index.







Hannu, et al.                                                   [Page 5]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


4.1. Overview of state reference with dynamic compression

   When compressor 1 (comp_1) compresses a message M it uses the
   information corresponding to a UDVM state that the peer decompressor
   (decomp_1) has established and acknowledged. If comp_1 decides that
   it for compression of later messages would like to be able to use the
   new state, which is the former state with the addition of information
   from M, it must save the new state. If an acknowledgement is received
   for this new state, comp_1 can utilize the new state in the
   compression process. Below is an overview of the model.

   Available 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
     compression.

   Acked state(s)

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


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

   Available     Acked    |            |  Available
    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   |            |







Hannu, et al.                                                   [Page 6]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


5. Extended operation mechanisms

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

   In 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 peer
   compressor that a certain state has been established.
   Over reliable and ordered transport the most recent state can always
   be used, if the compressor has downloaded such a UDVM instruction
   code to the peer decompressor.
   The following subsections describe how an explicit acknowledgement
   scheme and shared compression can be used in SigComp.


5.1. Explicit acknowledgement scheme


   As described above, 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_index, as
   described in Section 2.

   Together with state_index the SigComp message may also carry an
   acknowledgement, which would be the acked_index, see Section 2. The
   acknowledgement can be either standalone or piggybacked.


5.2. Shared Compression

   To allow for shared compression a compressor must save a state, which
   is the uncompressed version of the compressed message. The reference
   to this uncompressed version is the  shared_index, as described in
   Section 2. It must also indicate to the peer decompressor that this
   compressed message's uncompressed version was saved as a state at the
   compressor.

   When a decompressor receives a compressed message utilizing shared
   compression, the state indicated by state_index in the SigComp
   message is loaded to the UDVM. Thereafter the state indicated by
   shared_state is loaded to the UDVM.

   The shared state is loaded to the UDVM by setting the first_token to
   the shared_pointer (a pointer at a defined position), which points to
   the code that will insert the shared state into the "live dictionary"
   of the UDVM. The shared state data is copied into compressed_start
   and compressed_end is updated, and the UDVM is invoked. Then
   first_token is set to its previous value, and the message can be
   compressed by invoking the UDVM.





Hannu, et al.                                                   [Page 7]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


6. Implications on SigComp

   For the support of the extended operation mechanisms, SigComp
   messages must be able to carry the indications and information
   addressed in Section 5.

   A decompressor that does not support the extended operations, must be
   able to derive the length of the information in a SigComp message,
   which the peer compressor might have added for the extended operation
   mechanisms, see [SIGCOMP]. In case that shared compression and/or
   explicit acknowledgements are not supported the information is
   discarded before the SigComp message is processed any further.
   Figure 1, depicts a complete SigComp message, with the support of all
   extended operation mechanisms. An Optimization of this message is
   also shown and explained in Section 6.1.

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | i | c | s | a | r | b |Reserv.|
   +---+---+---+---+---+---+---+---+
   |                               |
   :    state_index (n-bytes)      : Present if 'i' is set
   |                               |
   +---+---+---+---+---+---+---+---+
   |                               |
   :            CRC                : Present if 'c' is set
   |                               |
   +---+---+---+---+---+---+---+---+
   |                               |
   :    shared_index (n-bytes)     : Present if 's' is set
   |                               |
   +---+---+---+---+---+---+---+---+
   |                               |
   :    acked_index (n-bytes)      : Present if 'a' is set
   |                               |
   +---+---+---+---+---+---+---+---+
   |           Possible            |
   :  Compressed data that should  :
   | be given as input to the UDVM |
   +---+---+---+---+---+---+---+---+

   Figure 1. SigComp message.

   '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.1.

   The CRC is calculated over the uncompressed message and can e.g. be
   used for verification of successful decompression.




Hannu, et al.                                                   [Page 8]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


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


6.1. Acknowledgement optimization

   This section describes an optimization for the case when shared
   compression is used and an acknowledgement is piggybacked.

   Consider the following. Comp_1 sends a message M compressed, with
   state(s0) to decomp_1. As comp_1 supports shared compression it saves
   state(M), and sets bit 'r', to signal that state(M) can be used by
   comp_2 in the compression process.

   If decomp_1 saves state(s0+M) = state(s1), which is the new state of
   the UDVM after decompression of M, then state(s1) can be implicitly
   acknowledged, if comp_2 uses M for further compression. Comp_2 sets
   the 'b' bit, which indicates that state(s0+M) is saved, which can be
   found from state(M), which is referenced by shared_index. This avoids
   acked_index to be present in the SigComp message for state(s0+M).
   Thus, a compressor that sets the 'r' bit should also hold a mapping
   between state(M) and state(s0+M).

   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_index has to be used.


6.2. Saving state information

   There are some simple rules, which must be followed, when a state is
   to be saved.

   Decompressor

     If there already exists a state for a state index, it must not be
     replaced with the requested state to be saved. This is to avoid
     that a compressed message cannot be decompressed because its state
     has been replace with another one.

   Compressor

     If there already exists a state for a state index, generated by the
     compressor, the compressor must not use that state for
     compression of any later messages even if an acknowledgement for
     this state is received. These states (state indexes) should be kept
     for a reasonable amount of time to avoid that a state used by the
     compressor is not actually the same as the one stored at the peer
     decompressor, even though the state index is the same.






Hannu, et al.                                                   [Page 9]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


7. Security considerations

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


8. IANA considerations

   [Editors note: This section is TBW]


9. Acknowledgements

   [Editors note: This section is TBW]


10. Authors' addresses

   Hans Hannu, Editor
   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

   Krister Svanbro
   Phone:  +46 920 20 20 77
   Fax:    +46 920 20 20 99
   E-Mail: krister.svanbro@epl.ericsson.se

     Box 920
     Ericsson Erisoft AB
     SE-971 28 Lulea, Sweden


   Christopher Clanton
   Phone:  +1 972 894-4886
   Fax:    +1 972 894-4589
   E-mail: christopher.clanton@nokia.com








Hannu, et al.                                                  [Page 10]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


   Khiem Le
   Phone:  +1 972 894-4882
   Fax:    +1 972 894-4589
   E-mail: khiem.le@nokia.com

   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


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

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


   Jonathan Rosenberg
   E-mail: jdrosen@dynamicsoft.com

     dynamicsoft
     72 Eagle Rock Avenue
     First Floor
     East Hanover, NJ 07936


11. Intellectual Property Right Considerations

   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

   [SIGCOMP]   H. Hannu et. al., Signaling Compression (SigComp),
               Internet Draft (work in progress), January 2002.
               <draft-ietf-rohc-sigcomp-03.txt>





Hannu, et al.                                                  [Page 11]


INTERNET-DRAFT       SigComp - Extended Operations    January 28 , 2002


   [UDVM]      R. Price et. al., Universal Decompressor Virtual Machine
               (UDVM), Internet Draft (work in progress), January 2002.
               <draft-ietf-rohc-sigcomp-udvm-00.txt>

   This Internet-Draft expires in July 2002.


















































Hannu, et al.                                                  [Page 12]


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