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

Versions: (draft-ietf-rohc-sigcomp-udvm) 00 01 02 03 04 05 06 RFC 3320

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

                                                       November 21, 2001



                     Signaling Compression (SigComp)
                     draft-ietf-rohc-sigcomp-02.txt




Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

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











Hannu, et al.                                                   [Page 1]

INTERNET-DRAFT                  SigComp              November 21 , 2001


Abstract

   The Session Initiation Protocol (SIP), along with many other
   protocols used for multimedia communications, such as RTSP, are
   textual protocols engineered for bandwidth rich links. With the
   planned usage of these protocols in wireless handsets as part of 2.5G
   and 3G cellular networks, the large size of their messages and the
   chatty nature of the protocols are problematic.

   This document provides a modular, robust and efficient message
   compression scheme, suitable for compression of ASCII based
   protocols' messages.


0. Document History

   - October 19, 2001, version 00

      First version. The draft describes the current ideas, from people
      involved in the ROHC WG, of how to perform compression of
      application signaling messages.

   - October 31, 2001, version 01

      Second version. Additional section, 5.2.1, which describes when a
      message identifier can be reused.

   - November 21, 2001, version 02

      Third version. Section 6 has been moved to a separate draft. The
      third version describes a modular solution, providing flexibility
      for implementers to decide which functions they want to integrate.


Table of contents

   1.  Introduction..................................................3
   2.  Terminology...................................................3
   3.  High-level description of SigComp.............................4
   4.  The SigComp protocol..........................................5
   5.  Compression Framework Component...............................9
   6.  Capability exchange...........................................13
   7.  Security considerations.......................................14
   8.  IANA considerations...........................................14
   9.  Authors' addresses............................................14
   10. Intellectual Property Right Considerations....................16
   11. References....................................................16








Hannu, et al.                                                   [Page 2]

INTERNET-DRAFT                  SigComp              November 21 , 2001


1. Introduction

   The Session Initiation Protocol (SIP) [SIP], along with many other
   application protocols used for multimedia communications, such as
   RTSP [RTSP], are textual protocols engineered for bandwidth rich
   links. As a result, these messages have not been optimized for
   message size. Typical SIP messages are from a few hundred bytes to as
   high as 2000. To date, this has not been a significant problem.

   With the planned usage of these protocols in wireless handsets as
   part of 2.5G and 3G cellular networks, the large size of these
   messages is problematic. The problem is not bandwidth efficiency (the
   media stream still consumes the majority of the bandwidth), but
   rather latency. With low-rate IP connectivity, store-and-forward
   delays are significant. For CDMA2000, for example, the basic channel
   will support only 9.6 kbps. At this rate, transmission of each byte
   requires 0.8ms. A 500 byte SIP message requires nearly half a second
   to transmit. Taking into account retransmits, and the multiplicity of
   messages that are required in some flows, call setup and feature
   invocation are adversely affected. Therefore, we believe there is
   merit in investigating ways to reduce message sizes.

   This document defines SigComp, a modular, robust and efficient
   message compression scheme, even when the transport path between the
   compressor and decompressor is unreliable, i.e. prone to errors,
   losses and misordering.

   From the view of external users, SigComp is only to provide
   compression service. What you get is the service of the underlying
   transport + compression. Nothing more. Nothing less.

   SigComp consists of a compression component and a protocol component.
   The protocol component should not be "extracted" out of the contents
   of this document for other purpose.

   This document does not specify a negotiation mechanism. The
   application that would like to apply SigComp should also negotiate
   the usage of SigComp.


2. Terminology

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

   Byte buffer

      The decompressor used by SigComp maintains a byte buffer, which
      depending on the implementation choice, contain any previously
      received text strings that might be useful for future compression.




Hannu, et al.                                                   [Page 3]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   Context

      The context of SigComp is the necessary information to perform
      compression and decompression. The correct context to use is
      identified by the IP Source and Destination addresses.


3. High-level description of SigComp

   Compression and decompression is performed at two communicating end-
   points, A and B, see Figure 1. When a message is to be compressed the
   compressing entity looks up the IP source and destination addresses
   and identifies the correct context to use. If no context exists, one
   is created. Depending on the implementation of the SigComp
   compressing entity the protocol might add a header to the output of
   the compressor. The final SigComp message is then passed on to
   underlying layers for transport to the decompressing entity.

   Upon the arrival of a SigComp message the SigComp decompressing
   entity will, if no context exists create one. If the SigComp message
   carries a header it removes the header and takes the appropriate
   actions (which depends on the implementation of the decompressing
   entity), then it gives the remaining SigComp message as input to the
   decompressor. After a correct decompression the uncompressed message
   will be passed on to the receiver.


     original   +------------------+  SigComp   +--------------------+
     message    | +----------+     |  message   | +------------+     |
    ------------+>|Compressor|-- - + - - - - - -+>|Decompressor|-----+->
                | +-----|----+     |            | +----|-------+     |
                |   +---|---+      |            |  +---|---+         |
                |   |Context|      |            |  |Context|         |
                |   +---+---+      |            |  +---+---+         |
                |   +---+---+      |            |  +---+---+         |
                |   |Context|      |            |  |Context|         |
   decompressed |   +---|---+      |  SigComp   |  +---|---+         |
     message    | +-----|--------+ |  message   | +----|-----------+ |
   <------------+-| Decompressor |<+- - - - - - +-|   Compressor   |<+--
                | +--------------+ |            | +----------------+ |
                +------------------+            +--------------------+
                         A                                B

                  Figure 1.  SigComp High-level view.

   Note: There is no need for one uncompressed message to correspond to
   exactly one compressed message. Two or more compressed messages can
   be sent to reconstruct a single uncompressed message, which is useful
   for segmenting compressed messages that are larger than the MTU of
   the transport protocol, see [ALG].





Hannu, et al.                                                   [Page 4]

INTERNET-DRAFT                  SigComp              November 21 , 2001


4. The SigComp protocol

   The main task of the SigComp protocol is to provide feedback from the
   decompressor to its peer compressor. The amount of feedback
   information and how the compressor react to the feedback are choices
   of the implementation. An implementation may also choose not to
   implement any feedback mechanisms.

   For the purpose of feedback, SigComp has a set of headers, as defined
   in Section 4.1. The use of headers is established at the capability
   exchange phase, see Section 6. The acknowledgment procedure in
   Section 4.2 together with the headers MAY be used by a decompressing
   entity to provide knowledge to the compressing entity about what
   SigComp messages it has received. This would allow the compressor to
   use previously sent messages in the compression process, even when
   the underlying transport protocol is unreliable, see Section 5.


4.1. The SigComp headers

   The SigComp headers consist of the following fields:

   Message IDentification (MID) number

      The MID number is used to keep track of sent and received
      messages, and is useful for detecting message loss and/or
      misordering.

   CRC-verification of messages (CRC-M)

      This CRC is calculated over the uncompressed message, e.g. the SIP
      INVITE message, and is used to verify the correctness of a
      decompressed SigComp message.

   Acknowledgement

      A SigComp acknowledgement can either be carried within a SigComp
      message (Piggybacked) or be sent by itself (Standalone).

   Note: It is assumed that the total length of a SigComp message is
   provided by the underlying transport layer. Since the length of the
   header part is self-contained the length of the compressed
   information can be derived by subtracting the header length from the
   total SigComp message length. The compressed information length could
   be zero in the case of a Standalone acknowledgement.
   Header formats are described in the following sub-sections.









Hannu, et al.                                                   [Page 5]

INTERNET-DRAFT                  SigComp              November 21 , 2001


4.1.1. Normal header formats

   These are the normal header formats to use. Format 1 SHOULD be used
   when there has been no gap in the received MID numbers up to the
   generation of this SigComp message. To acknowledge received SigComp
   messages after a gap in the received MID numbers, Format 2 MUST be
   used

   Format 1

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |      MID      | Cumulative ACK|
      +---+---+---+---+---+---+---+---+
      |             CRC-M             |
      +---+---+---+---+---+---+---+---+
      /   Compressed information      /
      /   according to Section 5      /
      +---+---+---+---+---+---+---+---+

   Format 2

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | 1   1   1   0 |      MID      |
      +---+---+---+---+---+---+---+---+
      |             CRC-M             |
      +---+---+---+---+---+---+---+---+
      |      AC       |     RMID (1)  |
      +---+---+---+---+---+---+---+---+
      |    RMID (2)   |     RMID (3)  |
      +---+---+---+---+---+---+---+---+
      :                               :
      /                               /
      :                               :
      +---+---+---+---+---+---+---+---+
      |    RMID (C-1) |    RMID (C)   |
      +---+---+---+---+---+---+---+---+
      /   Compressed information      /
      /   according to Section 5      /
      +---+---+---+---+---+---+---+---+


   MID: "0000" to "1101".

      The Message IDentification (MID) number is commonly increased with
      one for each sent message. However, there is the exception when
      the next MID to be assigned is not "free", see Section 4.2.1.







Hannu, et al.                                                   [Page 6]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   Cumulative ACK

      Acknowledges all SigComp messages with MID number equal to or less
      than the value of this field. The value of this field MUST NOT be
      set to a value so that non-received SigComp messages are
      acknowledged. A received acknowledgement with higher value than
      the maximum MID MUST be ignored and MUST NOT be considered as an
      acknowledgement for SigComp messages.

   CRC-M

      TBW

   RMID

      Received MID of a SigComp message, which is being acknowledged.

   AC

      Number of received SigComp message being acknowledged (RMID),
      which are included in the List. If AC is an even number the last
      RMID, RMID(C), is only padding, in order to get octet aligned.


4.1.2. Extended message formats

   Format 3

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | 1   1   1   1 |      TBD      |
      +---+---+---+---+               +
      /              TBD              /
      :                               :
      /                               /
      +---+---+---+---+---+---+---+---+

   Note: The usage of this format is yet to be determined.
   (Decompressing failure etc.)


4.2. Acknowledgement procedure

   The acknowledgement procedure is dependent on the information carried
   in the SigComp headers. It is RECOMMENDED that all SigComp messages
   are acknowledged.

   Three functions are needed:

   - A function that holds the received MID-numbers which should be
   acknowledged.




Hannu, et al.                                                   [Page 7]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   - A function that keeps a mapping between sent MID numbers and
   acknowledged MID numbers.

   - A function that controls which MID numbers that an entity is
   allowed to use.

   It is up to the implementation to realize these functions

   The acknowledgement procedure is best described using an example, see
   Figure 3.

               A                              B
               |                              |
    Step (0)   |<----------- MID 1B ----------|
               |                              |
    Step (1)   |-------- MID 1A, ACK 1B  ---->|
               |                              |
    Step (2)   |<--------MID 2B, ACK 1A ------|
               |                              |

            Figure 3. Example of the acknowledgement procedure.

   Step (0): A SigComp message with Message IDenitifcation number 1 is
   sent from B to A, denoted MID 1B in Figure 3. MID 1B MUST be
   acknowledged by A until A is confident that B knows that MID 1B is
   received.

   Step (1): Entity A acknowledges MID 1B with SigComp message MID 1A. A
   mapping between MID 1A and MID 1B is stored at A. Note that MID 1A do
   not have to carry compressed information, it can be a Standalone
   Acknowledgement.

   Step (2): Entity B acknowledges MID 1A and stores a mapping between
   MID 2B and MID 1A. When Entity A receives MID 2B it uses the mapping
   to find out which SigComp message(s) from B was acknowledged by MID
   1A. The mapping is removed and MID 1B MUST NOT be acknowledged
   anymore.


4.2.1. Reuse of Message IDentification numbers

   This section describe when a MID can be reused to avoid
   misinterpretations in case of wraparound of MID numbers combined with
   message loss and/or misordering.

   A MID number MUST NOT be reused until the SigComp message with that
   particular MID number has been acknowledged and stopped being
   acknowledged, or that the message can be regarded as lost.







Hannu, et al.                                                   [Page 8]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   Figure 4, is a continuation of the example given in Figure 3. The
   Figure depicts an example when it is allowed to reuse a MID number
   that has been acknowledged and stopped being acknowledged.

               A                              B
               |                              |
    Step (3)   |-------- MID 2A, ACK 2B  ---->|
               |                              |

             Figure 4. Continuation of Figure 3.

   Step (3): When Entity B receives an acknowledgement for MID 2B it
   knows that the mapping for MID 1B is removed at A. Therefore it
   is safe for entity B to reuse MID 1B.

   A message can be regarded as lost, if the SigComp entity has received
   acknowledgments for higher MID numbers than the MID number the entity
   wishes to reuse. However, as SigComp must stand against moderate
   misordering according to [REQ], a MID number X MUST NOT be regarded
   as lost until an acknowledgement for message(s) with MID numbers >
   (X+2) has been received.


5. Compression Framework Component

   SigComp uses the "Universal Decompression Algorithm" described in
   [ALG] for the actual compression. The "universal decompressor" is
   capable of interoperating with a wide range of compression
   algorithms. It is the compressor which decides what information that
   is stored in the dictionary of the decompressor. The compressor also
   controls how the decompressor performs the decompression.

   This section describes various features that a SigComp implementation
   may use to improve the compression efficiency. Some of these feature
   requires additional entries in the byte buffer of the "universal
   decompressor".


5.1. Pre-population

   A compressor MAY pre-populate the dictionary with well-known
   information (text-strings), in order to increase the compression
   efficiency. This is a rather simple approach with the "universal
   decompressor", see [ALG].


5.2. Per-message compression

   Compressing a message without any relation to any other message is
   referred to as per-message compression. Per-message compression can
   be used regardless of the reliability of the underlying transport and




Hannu, et al.                                                   [Page 9]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   the usage of the SigComp headers, as it is not dependent on any
   previously transmitted messages. To get compression of messages at
   all, this is the approach which all implementations of SigComp MUST
   support.

   Implementation support for the features in the following sections is
   optional.


5.3. Dynamic compression

   A compressing entity MAY choose to use previously sent messages in
   the compression process in an attempt to improve the compression
   efficiency. This is referred to as dynamic compression. To ensure
   reliable operation of the compression algorithm a compressor MUST NOT
   use dynamic compression, unless it is certain of that the message it
   is about to compress can be decompressed by the decompressor. If
   SigComp is used over reliable transport, such as TCP, dynamic
   compression does not introduce any robustness problem. To withhold
   robustness over unreliable transport, such as UDP, the SigComp
   acknowledgement procedure MUST be used when dynamic compression is
   applied. Thus, a previously sent message MUST NOT be used in the
   compression process until it has been acknowledged. Referring to
   Figure 3, B MAY use information in 1B to improve the compression
   efficiency of the message corresponding to 2B.


5.4. Shared compression

   Shared compression is referred to the case when a compressor 'A' make
   use of decompressed messages received by the decompressor located at
   the same SigComp entity. These decompressed messages MUST originate
   from the corresponding SigComp entity, which decompressor is
   controlled by compressor 'A'. Shared compression is OPTIONAL and its
   support is established in the capability exchange.

   To allow shared compression it is REQUIRED to use the SigComp
   acknowledgment procedure regardless of the reliability of the
   underlying transport.

   Referring to Figure 3, B MAY use information in 1A to improve the
   compression efficiency of the message corresponding to 2B.

   For shared compression to be applicable with the "universal
   decompressor" a SigComp entity supporting shared compression MUST
   implement two additional entries in the byte buffer of the
   decompressor:

   shared_start

      This is the start address in the byte buffer where original




Hannu, et al.                                                  [Page 10]

INTERNET-DRAFT                  SigComp              November 21 , 2001


      messages (not compressed) from this entity, which are being
      acknowledged, are to be placed into the byte buffer of the
      decompressor. By setting shared_start = 0, a compressor can
      avoid that any acknowledged message is written to the byte buffer.

   shared_length

      This is used by the protocol part to inform the decompressor
      algorithm if there was any new information, and the length of it,
      written to the shared compression part of the byte buffer. To
      avoid that same message information is processed twice, in case of
      multiple acknowledges for one message, the protocol MUST set
      shared_length = 0.

   Figure 5. depicts a logical view of the decompressor byte buffer at a
   SigComp entity which supports shared compression.

      +----A----------------------B---------------------+
      |    | Circular buffer for  | Circular buffer for |
      |    | received messages    | shared compression  |
      +----A----------------------B---------------------+

           Figure 5. Logical view of the decompressor byte buffer.

   A and B are the addresses which circular_buffer and shared_start
   point to. The received circular buffer will be between
   circular_buffer and shared_start-1. When the decompressing SigComp
   entity receives a SigComp message containing acknowledgements for
   e.g. MID-2 and MID-3  it will copy the original messages
   corresponding to MID-2 and MID-3 to the decompressor buffer at the
   address specified in shared_start.


5.4.1. Specification of ordering constraints

   Inconsistency in the dynamic context data can happen if the context
   is shared and messages, which will update the dynamic context data,
   are sent concurrently by both entities. The approach to deal with
   this problem is to specify ordering constraints of all update
   messages sent by both entities so that the order is total and the
   same at both entities, at least for the eligible updates. Three rules
   are defined; local, causality and concurrent rule. With the first two
   rules and the use of the 3-way handshake, it is possible to ensure
   consistency during updates of dynamic context data, but there is one
   case that these do not resolve; dynamic context data updates issued
   concurrently by both entities.

   With an update request in the description of the rules below means;
   Every message that carries information that is used to update the
   dynamic context data.





Hannu, et al.                                                  [Page 11]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   Local Rule

      When a dynamic context data update request R' is sent before R" at
      the same entity, R' is scheduled to perform an update before R" at
      both entities.  A sending entity schedules its own update requests
      according to their sequence numbers, whereas a receiving entity
      schedules these requests according to the request sequence
      numbers, which can be inferred from the sequence numbers of those
      SigComp messages containing these requests.

   Causality rule

      When a SigComp message containing a dynamic context data update
      request R' piggybacks with acknowledgements, R' is scheduled to
      perform an update after all the updates corresponding to the
      acknowledged update requests.

   Concurrent rule

      The problem explained above can be eliminated by requiring the
      maintenance of a total order relationship for a sequence of all
      known context update requests at each entity. This requires that
      one entity is the master and one is the slave.

   An example showing how the scheme with the total order relationship
   solves the inconsistent context update problem is shown in Figure 6.
   Suppose all messages exchanged between Entity X (a master entity) and
   Entity Y (a slave entity) are employed for subsequent
   compression/decompression, and all received messages are acknowledged
   and piggybacked in all subsequent messages sent by the receiver.
   Whenever concurrent dictionary updates are happened, update requests
   initiated from the master entity are ordered first.  For example, the
   update requests for Messages 1, 2, and 3 are ordered before those for
   Messages 101, 102, and 103 respectively in the list of the total
   order relationship for a sequence of dictionary updates (TOL).
   DD is a logical representation of the Dynamic Context Data, TSS is
   the logical representation of sent SigComp messages and TRS is the
   logical representation storage of received SigComp messages.

   Since the update request for Message 1 is ordered before that for
   Message 101 according to the total order relationship, the update
   request for Message 101 at Entity Y is blocked until that for Message
   1 becomes ready to be moved, as indicated by the reception of the
   acknowledgement piggybacked with Message 3.

                        |                          |
      DD  = {}          |                          |  DD  = {}
      TSS = {1}         |                          |  TSS = {101}
      TRS = {}          |                          |  TRS = {}
      TOL = {1}         |                          |  TOL = {}
                        |      [1]          [101]  |




Hannu, et al.                                                  [Page 12]

INTERNET-DRAFT                  SigComp              November 21 , 2001


                        |-----------\  /-----------|
                        |            \/            |
                        |            /\            |
                        |<----------/  \---------->|
                        |                          |
      DD  = {}          |                          |  DD  = {}
      TSS = {1, 2}      |                          |  TSS = {101, 102}
      TRS = {101}       |                          |  TRS = {1}
      TOL = {1, 101, 2} |                          |  TOL = {1}
                        |      [2]          [102]  |
                        |-----------\  /-----------|
                        |            \/            |
                        |            /\            |
                        |<----------/  \---------->|
                        |                          |
      DD  = {1}         |                          |  DD  = {}
      TSS = {2, 3}      |                          |  TSS = {101 - 103}
      TRS = {101, 102}  |                          |  TRS = {1, 2}
      TOL = {101, 2,    |                          |  TOL = {1, 101, 2}
             102, 3}    |                          |
                        |   [3]             [103]  |
                        |-----------\  /-----------|
                        |            \/            |
                        |            /\            |
                        |<----------/  \---------->|
                        |                          |
      DD  = {1, 101, 2} |                          |  DD  = {1, 101}
      TSS = {3}         |                          |  TSS = {102, 103}
      TRS = {102, 103}  |                          |  TRS = {2, 3}
      TOL = {102,3,103} |                          |  TOL = {2, 102, 3}
                        |                          |

                   CD Entity X                CD Entity Y

   Figure 6. An Example of Proposed Scheme with Total Order Relationship
   for Dynamic Context Data Updates.


6. Capability exchange

   Before two SigComp entities start to send compressed messages between
   them, they MUST agree on the capabilities they will use. This section
   does not specify how to perform the exchange, but preferably it
   should be conducted at the negotiation of applying SigComp.

   Buffer size

      The available byte buffer size of the decompressor MUST be
      exchanged.






Hannu, et al.                                                  [Page 13]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   SigComp headers

      Only in the case when both SigComp entities indicate the use of
      headers, the SigComp protocol MUST add a SigComp header to the
      compressor output. In any other case the protocol MUST NOT add a
      header.

   Shared compression

      If a SigComp entity supports shared compression it MAY indicate
      that. However, shared compression can only be used in combination
      with SigComp headers. A SigComp entity is not required to use
      shared compression even if it is supported by the corresponding
      entity.

   CPU power

      TBW


7. Security considerations

   TBW


8. IANA considerations

   TBW


9. Authors' addresses

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

   Phone: +46 920 20 21 84
   Fax: +46 920 20 20 99
   EMail: hans.hannu@epl.ericsson.se

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

   Phone: +46 920 20 28 40
   Fax: +46 920 20 20 99
   EMail: jan.christoffersson@epl.ericsson.se






Hannu, et al.                                                  [Page 14]

INTERNET-DRAFT                  SigComp              November 21 , 2001


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

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


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

   Phone: +46 920 20 23 39
   Fax: +46 920 20 20 99
   EMail: stefan.forsgren@epl.ericsson.se


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

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


   Ka Cheong Leung
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039
   USA

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


   Zhigang Liu
   2-700
   Mobile Networks Laboratory
   Nokia Research Center
   6000 Connection Drive Irving, TX 75039, USA

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




Hannu, et al.                                                  [Page 15]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   EMail: zhigang.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


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

   Email: jdrosen@dynamicsoft.com


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

   Phone: +46 920 20 20 77
   Fax: +46 920 20 20 99
   EMail: krister.svanbro@epl.ericsson.se


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

   [ALG]       R. Price et. al., Universal Decompression Algorithm,
               Internet Draft (work in progress), November 2001.
               <draft-ietf-rohc-sigcomp-algorithm-00.txt>

   [DEFLATE]   "DEFLATE Compressed Data Format Specification version
               1.3", RFC 1951, P. Deutsch, May 1996

   [RTSP]      H. Schulzrinne, A. Rao and R. Lanphier, Real Time
               Streaming Protocol (RTSP), RFC 2326, April 1998.





Hannu, et al.                                                  [Page 16]

INTERNET-DRAFT                  SigComp              November 21 , 2001


   [REQ]       H. Hannu (Editor), Signaling Compression Requirements &
               Assumptions, Internet Draft (work in progress),November
               2001. <draft-ietf-rohc-signaling-req-assump-03.txt>

   [SIP]       M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg,
               SIP: Session Initiation Protocol, RFC 2543, August 2000.

   This Internet-Draft expires in May 2002.















































Hannu, et al.                                                  [Page 17]


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