GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3321

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.
  1. shared_state_id
         State identifier of a shared state.
  1. 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:
  1. The acked_state_id as described in Sections 2 and 5.1.
  2. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3321.txt · Last modified: 2003/01/03 20:35 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki