Network Working Group                                 H. Hannu (Editor), Hannu, Ericsson
INTERNET-DRAFT                              J. Christoffersson, Ericsson
Expires: July August 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,
                                                       February 15, 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,


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

0. Document History

   - January 28, 2002, version 00

      First version. This draft describes the extended operation
      mechanisms, explicit acknowledgements and shared compression from

Table of contents

   1.  Introduction..................................................2
   2.  Terminology...................................................2
   3.  The Extended SigComp Architecture.............................4  Architectural view for feedback...............................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 mechanisms.................................6
   6.  Implications on SigComp.......................................8
   6.1.  Acknowledgement optimization................................9
   6.2.  Saving state information....................................9 SigComp.......................................9
   7.  Security considerations......................................10 considerations......................................14
   8.  IANA considerations..........................................10 considerations..........................................14
   9.  Acknowledgements.............................................10  Acknowledgements.............................................14
   10. Authors' addresses...........................................10 addresses...........................................14
   11. Intellectual Property Right Considerations...................11 Considerations...................15
   12. References...................................................11 References...................................................15
   Appendix A. Document history.....................................16

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, efficiency,
   compared to the case when one of the communicating implementations
   only support 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 [UDVM]. [SIGCOMP]. The UDVM is used for
     decompression of SigComp messages. The UDVM is capable of
     interoperating with a wide range of compression algorithms.


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


     The compressor invokes the encoder, and keeps track of states that
     can be used for compression. Responsible for supplying UDVM
     instructions to the peer its remote 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.


     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.


     Invokes the SigComp compressor and decompressor.


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

   State index identifier

     Reference to a state saved either by a compressor or a

     - state_index state_identifier

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

     -  shared_index  shared_identifier

          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 remote
          compressors might use different compression algorithms.

     - acked_index acked_identifier

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

   SigComp message

     May contain a compressed application message in the form of UDVM
     bytecode. In case of a message oriented transport mechanism, message- based transport, such as UDP, a
     SigComp message corresponds to exactly one (UDP) packet. datagram. For a
     stream oriented
     stream-based transport, such as TCP, each SigComp message is
     separated by a 0xFFFF delimiter, see [UDVM]. delimiter.

   Application data (message)

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

3. The Extended Architectural view for feedback

   A SigComp Architecture

   Compression and decompression is performed at two communicating end-
   points, endpoint may provide feedback to its remote SigComp
   endpoint, see Figure 1.

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

                Figure 1.  Extended SigComp High-level view.

   The difference between SigComp and extended SigComp is the
   availability of "interface" E (symbol [E]).  Architectural view

   With the extended
   operation, explicit acknowledgements (symbol [E]), feedback format specified in Section 6, it is
   possible for
   e.g. decompressor 1 a SigComp endpoint to inform compressor 1 about confirm which states that have
   been established at decompressor 1. Compressor 1 can then use these
   states in the compression process. to its remote SigComp endpoint. The established
   state confirmations are referred to as acknowledgments.

   Depending on the established
   states, states this is expected particular type of feedback
   may be used 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 memory and this status is
   referred to as a state. The decompressor may allow the As explained in [SIGCOMP] a save state to
   request may or may not be
   saved. granted. For later reference to this 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 index. identifier.

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 its remote
   (decomp_1) (decomp_2) 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

   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

   Acked state(s)

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

        Compressor 1                    Decompressor 1 2
           +---+                            +---+
           | 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   |            |

   Figure 2. Example of message flow.

5. Extended operation mechanisms

   For a compressor to be able to utilize a certain state it must know
   that the peer remote 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 remote
   compressor that a certain state has been established.
   Over reliable and ordered transport the most recent state can always may be
   used, if the compressor has downloaded such a UDVM instruction code
   to the peer its remote decompressor.

   The following subsections describe how an explicit acknowledgement
   scheme and shared compression can be used applied in SigComp.

5.1. Explicit acknowledgement scheme

   As described above, a

   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, state_identifier, as described in
   Section 2.

   Together with state_index state_identifier the SigComp message may also carry an
   acknowledgement, which would be the acked_index, 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 compressor must compressing endpoint MUST save a
   state, which is the uncompressed version of the compressed message.
   The reference to this uncompressed version is the  shared_index, shared_identifier,
   as described in Section 2. It must also indicate to the peer its remote
   decompressor that this compressed message's uncompressed version was
   saved as a state at the compressor.

   When If a decompressor receives compressing endpoint
   indicates that a compressed message utilizing shared
   compression, the state indicated by state_index in the SigComp
   message is loaded to the UDVM. Thereafter the compression state indicated by
   shared_state is loaded was saved, its local
   decompressor MUST be able to the UDVM. retrieve that particular state.
   The shared retrieval of this particular state is loaded to the UDVM by setting the first_token to
   the shared_pointer (a pointer at a defined position), which points done according to the code that will insert the shared state into the "live dictionary"
   retrieval instructions of the UDVM. The shared

5.3. Maintaining state data is copied into compressed_start
   and compressed_end is updated, and across session

   Usually, signaling protocols (e.g. SIP) have the UDVM is invoked. Then
   first_token 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 set natural to its previous value, and maintain the message state data from the same
   source across sessions so that high performance can be
   compressed by invoking the UDVM.

6. Implications on SigComp

   For achieved and
   maintained with the support 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 extended operation mechanisms, SigComp following
   observation that for protocols such as SIP, a given user/device
   combination will produce some messages must be able to carry containing fields that are
   always populated with the indications same data.

   Take SIP as an example, capabilities of the SIP endpoints
   are communicated during session initiation, and information
   addressed in Section 5.

   A decompressor that does do not support the extended operations, must be
   able tend to derive the length of 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 message,
   which the peer compressor might have added for could start uploading the extended operation user-
   specific dictionary, as part of the initial state, to the
   decompressor even before any signaling messages are generated from a
   particular application . This enables the immediate
   compression/decompression once the messages start to flow.

5.5. Checkpoint state and rollback mechanism

   The following mechanisms can be used to recover from decompression
   failure due to a reference to a non-exist state (i.e. not established
   at all or has been deleted by the decompressor) or a corrupted state:

   1) When a compressor sends a compressed message that will create new
   decompression state on the decompressor side, it can set a CHK_PT bit
   in the message to indicate that the newly created state will be a
   checkpoint state. A checkpoint state means that the decompressor
   SHOULD NOT delete it until it is explicitly instructed -- by the
   compressor -- to do so. In addition, the checkpoint state MUST be
   explicitly acknowledged by the receiving decompressor to the sending

   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

   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 the interface between the UDVM and its local
   decompressor functionalities.

6.1. Implications on SigComp messages

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

   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.

   - State identifiers of states that are acknowledged as successfully
     saved by the decompressor, i.e. acked_identifiers.

   Figure 4, depicts an example of what an extended basic SigComp
   message, with the support of all extended operation mechanisms, could
   look like. Note that this is only an example, the format is an
   implementation decision.

     0   1   2   3   4   5   6   7
   |                               |
   :  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.3.

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

6.2. Implications on the UDVM-decompressor interface

   This interface is used to pass feedback information from the UDVM to
   its local decompressor. The decompressor then forwards this
   information on to the local compressor.

6.2.1. General SigComp feedback format

   The general SigComp feedback information has the following format:

      |      Total length         |
      |       UDVM_version        |
      |    overall_memory_size    |
      |      cycles_per_bit       |
      |    cycles_per_message     |
      | Requested feedback length |
      |                           |
      :    Requested feedback     :
      |                           |
      | Returned feedback length  |
      |                           |
      :     Returned feedback     :
      |                           |

   Figure 5. High-level view of general SigComp feedback information.

   For description of the items see [SIGCOMP]. In case that shared compression and/or
   explicit acknowledgements are not supported [SigComp].

   The following Section describes how the information general feedback format is
   discarded before the
   used to provided extended operation mechanisms to basic sigComp.

6.2.2. Extended SigComp message requested feedback format

   The requested feedback is processed any further.
   Figure 1, depicts a complete SigComp message, feedback from the UDVM to its remote
   compressor. To make the extended acknowledgement scheme work, the
   Requested feedback is filled with information on states that UDVM
   requests the support state handler to save. In case the state handler refuses
   to save one or more of all
   extended operation mechanisms. An Optimization the indicated states, the feedback sent from
   the compressor will be updated accordingly. The format of this message the
   Requested feedback is
   also shown and explained of the following form:

   The variable n specifies the number of state identifiers included in Section 6.1.

     0   1   2   3   4   5   6   7
   | i | c
   the extended operations feedback format.
   id_length (x) and id_values (x) corresponds to the same state.

   | s            n              | a
   | r        id_length 1        | b |Reserv.|
   |                           |
   :    state_index (n-bytes)        id_value_1         : Present if 'i' is set
   |                               |
   |                           |
   :            CRC                : Present if 'c' is set
   |        id_length 2        |
   |                           |
   :    shared_index (n-bytes)        id_value_2         : Present if 's' is set
   |                               |
   |                           |
            :    acked_index (n-bytes)         : Present if 'a' is set
            :         :
   |        id_length n        |
   |           Possible                           |
   :  Compressed data that should        id_value_n         :
   | be given as input to the UDVM                           |

   Figure 1. 6. Format of the Requested feedback.

6.2.2. Extended SigComp message.

   'r' : If set, then a state corresponding returned feedback format

   The returned feedback is feedback from the remote endpoint to the decompressed
   local compressor. The 'r' bit indicates that an uncompressed version
   of this the compressed message was sent in this message has been saved at the
   remote endpoint, with the demands of Section 5.2. The 'b' bit is
   explained in Section 6.2.3. The format of the returned feedback is of
   the following form:

   |r|b|        n              |
   |        id_length 1        |
   |                           |
   :        id_value_1         :
   |                           |
   |        id_length 2        |
   |                           |
   :        id_value_2         :
   |                           |
            :         :
            :         :
   |        id_length n        |
   |                           |
   : Explained in Section 6.1.

   The CRC is calculated over the uncompressed message and can e.g. be
   used for verification        id_value_n         :
   |                           |

   Figure 7. Format of successful decompression.

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

6.1. Returned feedback.

6.2.3. Acknowledgement optimization

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

   Consider the following. following scenario. 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. shared_identifier. This
   acked_index acked_identifier to be present in the SigComp message for
   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_identifier has to be used.

6.2. Saving state information

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


     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.


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

7. Security considerations

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

8. IANA considerations

   [Editors note: This section is TBW]

9. Acknowledgements

   [Editors note: This section is TBW] TBW. Some names have been moved here
   from the list of authors]

   Thanks to

     Carsten Bormann (
     Christopher Clanton (
     Miguel Garcia (
     Lars-Erik Jonsson (
     Khiem Le (
     Mats Nordberg (
     Jonathan Rosenberg (
     Krister Svanbro (

   for valuable input and review.

10. Authors' addresses

   Hans Hannu, Editor Hannu
   Phone:  +46 920 20 21 84
   Fax:    +46 920 20 20 99

   Jan Christoffersson
   Phone:  +46 920 20 28 40
   Fax:    +46 920 20 20 99

   Stefan Forsgren
   Phone:  +46 920 20 23 39
   Fax:    +46 920 20 20 99

   Krister Svanbro
   Phone:  +46 920 20 20 77
   Fax:    +46 920 20 20 99
     Box 920
     Ericsson Erisoft AB
     SE-971 28 Lulea, Sweden

   Christopher Clanton
   Phone:  +1 972 894-4886
   Fax:    +1 972 894-4589
   Khiem Le
   Phone:  +1 972 894-4882
   Fax:    +1 972 894-4589

   Ka Cheong Leung
   Phone:  +1 972 374-0630
   Fax:    +1 972 894-4589

   Zhigang Liu
   Phone:  +1 972 894-5935
   Fax:    +1 972 894-4589

     Nokia Research Center
     6000 Connection Drive Irving, TX 75039, USA

   Richard Price
   Phone:  +44 1794 833681

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

   Jonathan Rosenberg

     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

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), January February 2002.
   [UDVM]      R. Price et. al., Universal Decompressor Virtual Machine
               (UDVM), Internet Draft (work in progress),

Appendix A. Document history

   - January 2002.
               <draft-ietf-rohc-sigcomp-udvm-00.txt> 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].

   This Internet-Draft expires in July August 2002.