doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc3321.txt b/doc/rfc/rfc3321.txt
new file mode 100644
index 0000000..ec15d27
--- /dev/null
+++ b/doc/rfc/rfc3321.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                           H. Hannu
+Request for Comments: 3321                            J. Christoffersson
+Category: Informational                                         Ericsson
+                                                             S. Forsgren
+                                                             K.-C. Leung
+                                                   Texas Tech University
+                                                                  Z. Liu
+                                                                   Nokia
+                                                                R. Price
+                                                      Siemens/Roke Manor
+                                                            January 2003
+
+
+         Signaling Compression (SigComp) - Extended Operations
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes how to implement certain mechanisms in
+   Signaling Compression (SigComp), RFC 3320, which can significantly
+   improve the compression efficiency compared to using simple per-
+   message compression.
+
+   SigComp uses a Universal Decompressor Virtual Machine (UDVM) for
+   decompression, and the mechanisms described in this document are
+   possible to implement using the UDVM instructions defined in RFC
+   3320.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                      [Page 1]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+Table of Contents
+
+   1.  Introduction..................................................2
+   2.  Terminology...................................................3
+   3.  Architectural View of Feedback................................4
+   4.  State Reference Model.........................................5
+   5.  Extended Mechanisms...........................................6
+   6.  Implications on SigComp......................................13
+   7.  Security Considerations......................................17
+   8.  IANA Considerations..........................................17
+   9.  Acknowledgements.............................................17
+   10. Intellectual Property Right Considerations...................17
+   11. References...................................................17
+   12. Authors' Addresses...........................................18
+   13. Full Copyright Statement.....................................19
+
+1.  Introduction
+
+   This document describes how to implement mechanisms with [SIGCOMP] to
+   significantly improve the compression efficiency compared to per-
+   message compression.
+
+   One such mechanism is to use previously sent messages in the 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
+   acknowledgement.
+
+   Another mechanism that will improve the compression efficiency of
+   SigComp, especially when SigComp is applied to protocols that are of
+   request/response type, is shared compression.  This involves using
+   received messages in the SigComp compression process.  In particular
+   the compression of the first few messages will gain from shared
+   compression.  Shared compression is described in this document.
+
+   For better understanding of this document the reader should be
+   familiar with the concept of [SIGCOMP].
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                      [Page 2]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+2.  Terminology
+
+   The reader should consult [SIGCOMP] for definitions of terminology,
+   since this document 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 compression.  The 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.
+
+     Dynamic compression
+
+       Compression relative to messages sent prior to the current
+       compressed message.
+
+     Explicit acknowledgement
+
+       Acknowledgement for a state.  The acknowledgment is explicitly
+       sent from a decompressor to its remote compressor.  The
+       acknowledgement should be piggybacked onto a SigComp message in
+       order not to create additional security risks.
+
+     Shared compression
+
+       Compression relative to messages received by the local endpoint
+       prior to the current compressed message.
+
+     Shared state
+
+       A state used for shared compression consists only of an
+       uncompressed message.  This makes the state independent of the
+       compression algorithm.
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                      [Page 3]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+     State identifier
+
+       Reference used to access a previously created item of state.
+
+       - shared_state_id
+
+           State identifier of a shared state.
+
+       - acked_state_id
+
+           State identifier of a state that is acknowledged as
+           successfully saved by the decompressor.
+
+3.  Architectural View of Feedback
+
+   SigComp has a request/response mechanism to provide feedback between
+   endpoints, see Figure 1.  This particular functionality of SigComp is
+   used in this document to provide support for the mechanisms described
+   in this document.
+
+      +--------------------+              +--------------------+
+      |    Endpoint 1      |              |     Endpoint 2     |
+      |  +--------------+  |              |  +--------------+  |
+      |  | Compressor 1 |  |              |  |Decompressor 2|  |
+      |  | [------------+--+--------------+--+--]   *       |  |
+      |  +-|-------^----+  |              |  +--|---|-------+  |
+      |    |       |       |              |     |   |          |
+      |    |       |       |              |     |   |          |
+      |    |       |       |              |     |   |          |
+      |  +-|-------|----+  |              |  +--v---|-------+  |
+      |  | *       [----+--+--------------+--+------]       |  |
+      |  |Decompressor 1|  |              |  | Compressor 2 |  |
+      |  +--------------+  |              |  +--------------+  |
+      +--------------------+              +--------------------+
+
+                       Figure 1.  Architectural view
+
+   The feedback functionality of SigComp is used in this document to
+   provide a mechanism for a SigComp endpoint to confirm which states
+   have been established by its remote SigComp endpoint during the
+   lifetime of a SigComp 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.
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                      [Page 4]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   The following sections describe how the SigComp functionality of
+   providing feedback information is used to support the mechanisms
+   described in this document.  Section 4 describes the state reference
+   model of SigComp.  Section 5 continues with a general description of
+   the mechanisms and Section 6 describes the implications of some of
+   the mechanisms on basic SigComp.
+
+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 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 with Dynamic Compression
+
+   When compressor 1 compresses a message m it uses the information
+   corresponding to a SigComp state that its remote decompressor 2 has
+   established and acknowledged.  If compressor 1 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 together with an example of a message flow.
+
+   Saved state(s)
+
+     A state which is expected to be used for compression/decompression
+     of later messages.
+
+   Acked state(s)
+
+     An acked state is a saved state for which the compressor 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, otherwise a
+     decompression failure will occur.  For this reason,
+     acknowledgements are necessary, at least for unreliable transport.
+
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                      [Page 5]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+            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 for dynamic compression
+
+   Legend: Message 1 compressed making use of state s0 is denoted
+   m1(s0).  The notation s1=s0+m1 means that state s1 is created using
+   information from state s0 and message m1.  ack(s1) means that the
+   creation of state s1 is acknowledged through piggybacking on a
+   message traveling in the reverse direction (which is not shown in the
+   figure).
+
+5.  Extended Mechanisms
+
+   The following subsections give a general description of the extended
+   mechanisms.
+
+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, an acknowledgement
+   scheme must be used to notify the remote compressor that a certain
+   state has been established.
+
+
+
+
+
+Hannu, et. al.               Informational                      [Page 6]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   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 the case when e.g., compressor 1 has uploaded UDVM bytecode
+   to decompressor 2.  The UDVM bytecode will use the requested feedback
+   field in the announcement information and the returned feedback field
+   in the SigComp header to obtain knowledge about established states at
+   endpoint 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                      [Page 7]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   Consider Figure 3.  An event flow for successful use of remote
+   compressor 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): 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 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                      [Page 8]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+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], whose 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 Section 2 the reference 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 according 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
+
+
+
+Hannu, et. al.               Informational                      [Page 9]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   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 state pushed existing
+   state out of the state memory buffer).
+
+   A compressing endpoint must also indicate to the remote compressor
+   that the shared state is available, but only if the local
+   decompressor can retrieve the shared state.  The retrieval of the
+   shared state is done according to the state retrieval 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 Application Sessions
+
+   Usually, signaling protocols (e.g., SIP) 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
+
+
+
+Hannu, et. al.               Informational                     [Page 10]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   achieved and 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
+
+   The concept of the user-specific dictionary is based on the
+   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 tend not to change unless
+   the capabilities of the device change.  Similarly, user-specific
+   information such as the user's URL, name, and e-mail address will
+   likely not change on a frequent basis, and will appear regularly in
+   SIP signaling exchanges involving a specific user.
+
+   Therefore, a SigComp compressor could include the user-specific
+   dictionary as part of the initial messages to the decompressor, even
+   before any time critical signaling messages are generated from a
+   particular application.  This enables an increase in 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
+
+   The following mechanism can be used to avoid decompression failure
+   due to reference to a non-existent state.  This may occur in three
+   cases: a) a state is not established at the remote SigComp endpoint
+   due to the loss of a SigComp message; b) a state is not established
+   due to insufficient memory; c) a state has been established but was
+   deleted later due to insufficient memory.
+
+   When a compressor sends a SigComp message that will create a new
+   state on the decompressor side, it can indicate that the newly
+   created state will be a checkpoint state by setting
+   state_retention_priority [SIGCOMP] to the highest value sent by the
+   same compressor.  In addition, a checkpoint state must be explicitly
+   acknowledged by the receiving decompressor to the sending compressor.
+
+
+
+Hannu, et. al.               Informational                     [Page 11]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   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 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, including the indication of
+        the state priority.  The application grants the saving of
+        state(A): see [SIGCOMP].
+   (4): An acknowledgement for state(A) (the checkpoint state) is
+        returned to endpoint 2 using one of the mechanisms described in
+        Section 5.1.
+
+   Note: To avoid using a state that has been deleted due to
+   insufficient memory a compressor must keep track of the memory
+   available for saving states at the remote endpoint.  The SigComp
+   parameter state_memory_size which is announced by the SigComp
+   feedback mechanism can be used to infer if a previous checkpoint
+   state has been deleted (by a later checkpoint state creation request)
+   due to lack of memory.
+
+5.6.  Implicit Deletion for Dictionary Update
+
+   Usually a state consists of two parts: UDVM bytecode and dictionary.
+   When dynamic compression is applied, new content needs to be added to
+   the dictionary.  To keep an upper bound of the memory consumption
+   such as in the case for a low end mobile terminal, existing content
+   of the dictionary must be deleted to make room for the new content.
+
+   Instead of explicitly signaling which parts of the dictionary need to
+   be deleted on a per message basis, an implicit deletion approach may
+   be applied.  Specifically, some parts of the dictionary 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.  For
+   instance, the algorithm can be part of the predefined UDVM bytecode
+   that is agreed between the two SigComp endpoints.  As input to the
+   algorithm, one provides the total number of bytes to be deleted.  The
+   algorithm then specifies which parts of the dictionary are to be
+   deleted.  Since the same algorithm is applied at both SigComp
+   endpoints, there is no need for explicit signaling on a per message
+   basis.  This may lead to higher compression efficiency due to the
+   avoidance of
+
+
+
+
+Hannu, et. al.               Informational                     [Page 12]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   signaling overhead.  It also means more robustness as there are no
+   signaling bits on the wire that are subject to possible transmission
+   errors/losses.
+
+6.  Implications on SigComp
+
+   The extended features will have implications on the SigComp messages
+   sent between the compressor and its remote decompressor, and on how
+   to interpret e.g., returned SigComp parameters [SIGCOMP].  However,
+   except for the mandatory bytes of the 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 affected, even if it receives this
+   kind of feedback.
+
+6.1.  Implications on SigComp Messages
+
+   To support the extended features, SigComp messages must 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 2 and 5.1.
+   - The shared_state_id as described in Sections 2 and 5.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                     [Page 13]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   Figure 4 depicts the format of a SigComp message 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            |
+   :   partial state identifier    :   +---+---+---+---+---+---+---+---+
+   |                               |   |   code_len    |  destination  |
+   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
+   |                               |   |                               |
+   :   remaining SigComp message   :   :    uploaded UDVM bytecode     :
+   |                               |   |                               |
+   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
+                                       |                               |
+                                       :   remaining SigComp message   :
+                                       |                               |
+                                       +---+---+---+---+---+---+---+---+
+
+                  Figure 4.  Format of a SigComp message
+
+   The format of the field "remaining SigComp message" is an
+   implementation decision by the compressor which supplies the UDVM
+   bytecode.  Therefore there is no need to specify a message format to
+   carry the information necessary for the extended features described
+   in this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                     [Page 14]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   Figure 5 depicts an example of what the "remaining SigComp message"
+   with support for 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
+   +---+---+---+---+---+---+---+---+
+   | Format according to Figure 4  |
+   :   except for the field called :
+   |   "remaining SigComp message" |   "remaining SigComp message" field
+   +---+---+---+---+---+---+---+---+             --------
+   | s | a | r |    Reserved       |                |
+   +---+---+---+---+---+---+---+---+                |
+   |                               |                |
+   :       shared_state_id*        : Present if 's' is set
+   |                               |                |
+   +---+---+---+---+---+---+---+---+                |
+   |                               |                |
+   :       acked_state_id*         : Present if 'a' is set
+   |                               |                |
+   +---+---+---+---+---+---+---+---+                |
+   |                               |                |
+   :  Rest of the SigComp message  :                |
+   |                               |                v
+   +---+---+---+---+---+---+---+---+          --------------
+
+   Figure 5. Example of SigComp message for some of the 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 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 "returned_SigComp_parameters"
+   [SIGCOMP] information is interpreted to provide feedback according to
+   Section 5.1 and 5.2.
+
+   The partial_state_identifiers correspond to the hash_value for states
+   that have been established at the remote endpoint after the reception
+   of SigComp messages, i.e., these are acknowledgements for established
+   states and may be used for compression.  The
+   partial_state_identifiers may also announce "global state" that is
+   not mapped to any particular compartment and is not established upon
+   the receipt of a SigComp message.
+
+
+
+Hannu, et. al.               Informational                     [Page 15]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   It is up to the 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, 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 set the I-bit to 1.  The endpoint
+   storing shared states and sending the list of locally available
+   states to its remote endpoint must be careful when taking the
+   decision whether to exclude or include different types of the 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)
+   then there exists an optimization, which, if implemented, makes an
+   acked_state_id in the SigComp message unnecessary:
+
+   Compressor 1 saves a shared state(M), which is the uncompressed
+   version of the current compressed message (message m) to be sent.
+   Compressor 1 also sets bit 'r' (see Figure 5), to signal that
+   state(M) can be used by endpoint 2 in the compression process.  The
+   acked_state_id for state(S), which was created at endpoint 2 upon the
+   decompression of message m, may not have to be explicitly placed in
+   the compressed messages from compressor 2 if the shared state(M) is
+   used in the compression process.
+
+   When endpoint 1 notices that shared state(M) is requested by
+   decompressor 1, it implicitly knows that state(S) was created at
+   endpoint 2.  This follows since:
+
+   * Compressor 1 has instructed decompressor 2 to save state(S).
+   * The indication of shared state(M) would never have been received by
+     compressor 2 if state(S) had not been successfully saved, because
+     if a state save request is denied then the corresponding
+     announcement information is discarded by the state handler.
+
+   Note: Endpoint 1's state handler must maintain a mapping between
+   state(M) and state(S) for this optimization to work.
+
+   Note: The only state that is acknowledged by this feature is the
+   state that was created by combining the state used for compression of
+   the message and the message itself.  For any other case the
+   acked_state_id has to be used.
+
+
+
+
+Hannu, et. al.               Informational                     [Page 16]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+   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); this can be done 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
+
+   The features in this document are believed not to add any security
+   risks to the ones mentioned in [SIGCOMP].
+
+8.  IANA Considerations
+
+   This document does not require any IANA involvement.
+
+9.  Acknowledgements
+
+   Thanks to Carsten Bormann, Christopher Clanton, Miguel Garcia, Lars-
+   Erik Jonsson, Khiem Le, Mats Nordberg, Jonathan Rosenberg and Krister
+   Svanbro for valuable input.
+
+10.  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.
+
+11.  References
+
+   [SIP]       Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+               A., Peterson, J., Sparks, R., Handley, M. and E.
+               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+               June 2002.
+
+   [SIGCOMP]   Price R., Bormann, C., Christoffersson, J., Hannu, H.,
+               Liu, Z. and J. Rosenberg, "Signaling Compression
+               (SigComp)", RFC 3320, January 2003.
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                     [Page 17]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+12.  Authors' Addresses
+
+   Hans Hannu
+   Box 920
+   Ericsson AB
+   SE-971 28 Lulea, Sweden
+
+   Phone: +46 920 20 21 84
+   EMail: hans.hannu@epl.ericsson.se
+
+   Jan Christoffersson
+   Box 920
+   Ericsson AB
+   SE-971 28 Lulea, Sweden
+
+   Phone: +46 920 20 28 40
+   EMail: jan.christoffersson@epl.ericsson.se
+
+   Stefan Forsgren
+
+   EMail: StefanForsgren@alvishagglunds.se
+
+   Ka-Cheong Leung
+   Department of Computer Science
+   Texas Tech University
+   Lubbock, TX 79409-3104
+   United States of America
+
+   Phone: +1 806 742-3527
+   EMail: kcleung@cs.ttu.edu
+
+   Zhigang Liu
+   Nokia Research Center
+   6000 Connection Drive
+   Irving, TX 75039, USA
+
+   Phone: +1 972 894-5935
+   EMail: zhigang.c.liu@nokia.com
+
+   Richard Price
+   Roke Manor Research Ltd
+   Romsey, Hants, SO51 0ZN, United Kingdom
+
+   Phone: +44 1794 833681
+   EMail: richard.price@roke.co.uk
+
+
+
+
+
+
+Hannu, et. al.               Informational                     [Page 18]
+
+RFC 3321             SigComp - Extended Operations          January 2003
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hannu, et. al.               Informational                     [Page 19]
+