Internet DRAFT - draft-hannu-rohc-roger

draft-hannu-rohc-roger







Network Working Group                               Hans Hannu, Ericsson
INTERNET-DRAFT                             Jan Christoffersson, Ericsson
Expires: January 2002                          Krister Svanbro, Ericsson
                                               Stefan Forsgren, Ericsson
                                                                  Sweden
                                                           July 06, 2001






             RObust GEneric message size Reduction (ROGER)
                    <draft-hannu-rohc-roger-01.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 an individual submission to the IETF. Comments
   should be directed to the authors.


Abstract

   Using existing ASCII based application signaling protocols over
   bandwidth limited channels, such as cellular access channels, create
   problems with e.g. long session setup times, long control times and
   waste scarce radio resources. This draft provides a robust and
   efficient compression scheme for ASCII based protocols, which reduces
   the mentioned problems.





Hannu, Christoffersson, Svanbro, Forsgren                       [Page 1]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


0. Document History

   - February 23, 2001, version 00

   - July 06, 2001, version 01
     Improved header formats, with additional functionality.


TABLE OF CONTENTS

   1.  Introduction..................................................4

   2.  General description...........................................5

   3.  Terminology...................................................6

   4.  Compression algorithm.........................................7
   4.1.  Dictionary build-up and maintenance.........................8

   5.  ROGER message header functionality............................9
   5.1.  ROGER header type..........................................10
   5.1.1.  Message IDentification number (MID)......................10
   5.1.2.  Code Point (CP)..........................................10
   5.2.  ROGER Acknowledgement......................................11
   5.2.1.  Cumulative Acknowledgement...............................11
   5.2.2.  Bit Mask Acknowledgement.................................11
   5.2.3.  List Acknowledgement.....................................12
   5.3.  CRCs.......................................................12
   5.3.1.  CRC for message..........................................13
   5.3.2.  CRC for Dynamic Dictionary...............................13
   5.4.  Code Point with flags......................................13
   5.4.1.  Forced acknowledgements..................................14
   5.4.2.  The usage of CP-FLUSH....................................14
   5.5.  ROGER header formats.......................................15
   5.6.  Reuse of Message IDentification number (MID)...............16
   5.7.  Dictionary memory space....................................17
   5.7.1.  Sliding window...........................................17
   5.7.2.  No deletion..............................................17
   5.8.  Avoiding deadlock..........................................18
   5.9. User Semi-Static Dictionary.................................18

   6.  Modes of implementation......................................19
   6.1.  No contact mode............................................19
   6.1.1.  Compression..............................................20
   6.1.2.  Decompression............................................20
   6.2.  Limited contact mode.......................................20
   6.2.1.  Compression..............................................21
   6.2.2.  Decompression............................................21
   6.3.  Full contact mode..........................................21
   6.3.1.  Compression..............................................22
   6.3.2.  Decompression............................................22




Hannu, Christoffersson, Svanbro, Forsgren                       [Page 2]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   6.4.  Move of table content......................................22
   6.4.1.  TRD to DD................................................23
   6.4.2.  TST to DD................................................23

   7.  ROGER requirements...........................................23

   8.  Implementation status........................................24

   9.  ROGER over ROHC - A new ROHC profile.........................24
   9.1.  ROGER profile in the ROHC framework........................25
   9.1.1.  Limited contact mode.....................................25
   9.1.1.1.  Packet types...........................................25
   9.1.2.  Full contact mode........................................26
   9.1.2.1.  Packet types...........................................26

   10.  Evaluation of compression scheme............................26

   11.  Conclusion..................................................27

   12.  Security considerations.....................................28

   13.  IANA considerations.........................................28

   14.  Acknowledgments.............................................28

   15.  Intellectual property considerations........................28

   16.  Authors addresses...........................................28

   17.  References..................................................29

























Hannu, Christoffersson, Svanbro, Forsgren                       [Page 3]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


1. Introduction

   Two communication technologies have become commonly used by the
   general public in the recent years: cellular telephony and the
   Internet. Cellular telephony has provided its users with the freedom
   of mobility - the possibility of always being reachable with
   reasonable service quality no matter where they are. However, until
   now the main service provided has been speech. With the Internet, the
   conditions have been almost the opposite. While flexibility for all
   kinds of usage has been its strength, its focus has been on fixed
   connections and large terminals, and the experienced quality of some
   services (such as Internet telephony) has generally been low. Due to
   new enhanced technologies this is about to change. Internet and
   cellular technologies are beginning to merge. Future cellular
   "phones" will contain an IP-stack and support voice over IP in
   addition to web-browsing, e-mail, etc. One could say that the
   Internet is going mobile, or that cellular systems are becoming much
   more than telephony depending on one's point of view.

   Commonly used terms in this technical area are "all-IP" and "IP all
   the way". These terms all relate to the case where IP is used end to
   end, even if the path involves cellular links. This is done for all
   types of traffic, both the user data (e.g. voice or streaming) and
   control signaling data (e.g. SIP or RTSP). A great benefit of this is
   the service flexibility introduced by IP combined with the freedom
   provided by continuos mobility. A high cost, on the other hand, is
   the relative large overhead the IP protocol suite typically
   introduces, due to large headers and text-based signaling protocols.

   It is very important in cellular systems to use the scarce radio
   resources in an efficient way. It must be possible to support a
   sufficient number of users per cell, otherwise costs will be
   prohibitive [CELL].

   The ROHC (RObust Header Compression) working group has successfully
   solved the problem of reducing bandwidth requirements for the header
   parts of e.g. RTP/UDP/IP packets [ROHC]. With this obstacle removed,
   new challenges of enhancing mobile Internet performance arise. One of
   these relates to application signaling protocols. Protocols such as
   SIP [SIP], SDP [SDP] and RTSP [RTSP] will typically be used to setup
   and control applications also in a mobile Internet. However, the
   generous size of the protocol messages combined with their
   request/response nature create delays and waste bandwidth.
   Compression of these messages should be considered in order to
   increase spectrum efficiency and reduce transmission delay [APP].










Hannu, Christoffersson, Svanbro, Forsgren                       [Page 4]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


2. General description

   This chapter describes compression of protocol data above IP/UDP or
   IP/TCP. The solution is a framework which is robust to packet loss
   and will give efficient compression of ASCII based protocol messages.
   Furthermore, the compression is transparent, i.e. a compressed
   message will after decompression be bitwise identical to the original
   message.

   The framework is especially suitable for SIP/SDP, RTSP and HTTP
   [HTTP], but could also be used for other ASCII based protocols.

   Three possible compression/decompression scenarios are identified.
   The scenarios differ from each other depending on to what extent the
   compressor and decompressor can communicate. In all three cases it is
   assumed that the messages are compressed when sent over a narrow band
   link, such as a cellular link. This means that one of the entities
   may reside in the terminal equipment (mobile phone, thin client etc.)
   and the other (somewhere)in the fixed part of a cellular system. The
   different cases and how to handle them are described in Chapter 6.

   The compression scheme enhances dictionary based compression of
   single messages by compressing messages from designated packet
   flow(s) in a sequential manner. Already transmitted messages are used
   when compressing new messages. The great gain in doing so stems from
   the fact that previous messages will contain much of the information
   or text strings that are found in later messages.

   In order to classify messages as belonging to a certain flow the
   messages must all pass through the points where the
   compressor/decompressor entities reside. That is, packets that go to
   different mobile terminals can not in general belong to the same
   compressed packet flow.

   The method takes advantage of the possibility to acknowledge received
   messages. The acknowledgements can either be sent with messages
   travelling in the opposite direction or using a dedicated backwards
   channel. All sent and received messages are temporarily stored. Once
   the messages are acknowledged, they are put in a dictionary which is
   used for compression/decompression of future messages. Details on
   where the messages are stored while waiting for acknowledgements is
   given in Chapter 3. The dictionary management and a more thorough
   description of the different scenarios are described in Chapter 6.

   The compression algorithm used for compression is based on the
   Lempel-Ziv algorithm which replaces strings in the message by
   references to previous occurrences in the message or dictionary. The
   use of a dictionary will greatly increase the compression efficiency.
   More information on the compression algorithm can be found in Chapter
   4.





Hannu, Christoffersson, Svanbro, Forsgren                       [Page 5]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


3. Terminology

   * Static Dictionary (SD)
     A dictionary which is static, i.e. does not change during or
     between compression of message flows. The dictionary contains, e.g.
     protocol-specific Header field names, Methods, Status-codes etc.
     The static dictionary is known by the compressor and decompressor
     prior to compression/decompression at both sides of the link. The
     SD is used for both compression and decompression.

   * Dynamic Dictionary (DD)
     Contains acknowledged messages (or parts of them), which have been
     transmitted during the session. The dynamic dictionary is known by
     both the compressor and the decompressor on the opposite side. The
     DD is empty when the compression begins and is updated according to
     some specific scheme during the message sequence. The DD is used
     for both compression and decompression.

   * Temporary Receiver Dictionary (TRD)
     Messages (or parts of them), which have traversed the link, are
     stored at the receiver side in the TRD. When a receiving entity is
     positive that the opposite side knows that the messages have been
     received, the messages are moved from the TRD to the DD. The TRD is
     used for compression only.

   * Temporary Sender Table (TST)
     Messages that have been sent over the link are stored in the TST at
     the sending side until it is positive that the messages have been
     received at the opposite side, then they are moved to the DD. Thus,
     messages in the TST are not used in the compression process.

   * Temporary Receiver Dictionary Table (TRDT)
     The TRDT is used to keep track of when to move a message from the
     TRD to the DD. The TRDT holds an association between the sent
     messages and the received messages that are being acknowledged by
     the sent messages from an entity.

   * Headers
     In order for the two entities to keep track of which messages have
     been sent from and received by the other entity the compressed
     messages are supplied with a header. The header holds the sequence
     number of the present message and the sequence numbers of all the
     received messages which have not yet been acknowledged, i.e. the
     contents of the TRD.

   * Context
     Contains the information necessary to perform compression and
     decompression, i.e. the dictionaries and the tables described
     above.






Hannu, Christoffersson, Svanbro, Forsgren                       [Page 6]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


4. Compression algorithm

   The default compression algorithm used to compress messages is a
   slightly modified LZSS [LZSS], which is of Lempel-Ziv type. The
   algorithm works by scanning through the file from left to right and
   replace repeated strings by references to the last previous
   occurrence in the file. The reference is of the form (offset, length
   of match) and is typically represented using two bytes.

   The implementation of LZSS must be done so that it is possible to
   compress and decompress messages using dictionaries. A logical
   representation of how this can be achieved is as follows, see also
   Figure 4.1:

   Compression

   1. Append the message to the dictionary and compress the extended
      file using LZSS.
   2. Separate the part of the compressed file that corresponds to the
      dictionary from the part which corresponds to the message. This is
      possible since LZSS processes the file from left to right and the
      part which has already been compressed does not change as the
      compression proceeds. That is, compressing the dictionary by
      itself or compressing it with a message appended to it will
      produce the same output (apart from the compressed message)

   Decompression

   1. Append the compressed message to the compressed dictionary and
      decompress the extended file.
   2. Separate the message from the dictionary.

   It is of course of vital importance that the same dictionary is used
   by both the compressor and decompressor.

   +--------------+---------+                  +--------+------+
   |  Dictionary  | Message |       --->       |   CD   |  CM  |
   +--------------+---------+   Compression    +--------+------+


   +--------------+                            +--------+
   |  Dictionary  |                 --->       |   CD   |
   +--------------+             Compression    +--------+

   Figure 4.1. Compression of the dictionary with a message appended and
   the dictionary by itself. CD is the compressed dictionary and CM is
   the compressed message.

   The LZSS implementation should be tailored to enable the split of the
   compressed file into these two parts in a simple fashion. To
   facilitate the splitting the implementation should not replace a




Hannu, Christoffersson, Svanbro, Forsgren                       [Page 7]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   repeated string which runs from the dictionary and into the message
   with a single reference. The part of the string in the dictionary
   should be replaced with one reference and the part of the string in
   the message should be replaced by another reference.

   Compression with LZSS is valid for virtually all types of protocol
   data, not just ASCII based. However, compression would probably not
   be as efficient for other types of data.

   Note: LZSS is chosen as the default compression algorithm in this
   draft. However, it is left as an open issue how LZSS could be
   modified or if some other compression algorithm should be used, in
   order to enhance the performance of ROGER.


4.1. Dictionary build-up and maintenance

   The DD is part of the ROGER context, and the compressor DD must be
   kept consistent with the decompressor DD to avoid faulty decompressed
   packets. Each packet stream should have its own context, but it would
   of course be possible to share dictionaries between different flows
   as long as they pass the same compression and decompression points.
   However, this depends on where the scheme is placed and is therefore
   left for the implementation.
   The DD should at least be kept as long as packets belonging to the
   context keep arriving. Determining whether a packet flow is still
   active can be done using a timer. It could also be possible to
   identify the end of a packet flow from the semantics of the protocol,
   but this would complicate the compressor scheme by forcing the
   compressor to know the semantics of the compressed protocols and also
   to keep track of the type of the transmitted messages.

   There are several different strategies which could be used to
   determine what to update the dynamic dictionary with. The method
   should ensure a high compression efficiency while keeping the
   dictionary size and the complexity of the scheme at a reasonable
   level. Some possibilities on how to update the dictionary are given
   below:

   * Append all messages to the dictionary. This would give very large
     dictionaries in long sessions with many messages.

   * Only use the first (or last) n messages of the session. Typically,
     n would be small to ensure that the dictionary does not grow to an
     unreasonable size. Still, it would have to be large enough to make
     the compression efficient.

   * Append only new strings, short sub-strings or rows to the
     dictionary. This would also ensure a slower growth of the
     dictionary. However, it remains to be investigated how this will
     affect the compression efficiency.




Hannu, Christoffersson, Svanbro, Forsgren                       [Page 8]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001



   * Messages, strings or rows could also be deleted from the
     dictionary to avoid having an unreasonably large dictionary. One
     strategy for this could be to delete from the beginning of the
     dictionary, i.e. deleting the oldest parts first, i.e. using a
     sliding window.

   See also section 5.7.1 and chapter 7.

   Note: It still remains to be investigated what is the most efficient
   way to update the dictionary.


5. ROGER message header functionality

   To achieve robustness and keep track of sent and received messages, a
   header is added to the compressed message.
   The ROGER header consist of the following parts, and the parts are
   also placed in this order in the header:

   * Header Type
     - Message ID (MID), or
     - Code Point (CP)
   * Acknowledgement
     - Cumulative Acknowledgement, or
     - Bit Mask Acknowledgement, or
     - List Acknowledgement
   * (CRC for Dynamic Dictionary)
   * CRC for message

   Not all of these parts have to be present in each ROGER message.

   ROGER can handle packet reordering, which has happened before the
   compressor, and also message reordering between compressor and
   decompressor. The interval of reordering ([MID-N,MID]) that ROGER
   must support, should be negotiated before compression starts. N must
   be chosen to be less than the number of MIDs used, (0<=N<12) see also
   section 5.1.1.

















Hannu, Christoffersson, Svanbro, Forsgren                       [Page 9]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


5.1. ROGER Header Type

   The basic header format is shown in Figure 5.1.

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | Header Type   |  Depends on   |
   +---+---+---+---+               +
   :                               :
   /    the value of Header Type   /
   :                               :
   +---+---+---+---+---+---+---+---+
   Figure 5.1. Basic ROGER header format

   The Header Type (HT) states either a Message IDentification number
   (MID) or a Code Point (CP).


5.1.1 Message IDentification number (MID)

   The MID is used by the receiving entity (decompressor) to determine,
   which message has been received and it is also acknowledged to the
   sending entity (compressor). If HT has one of the following values it
   indicates a MID:

     +---+---+---+---+       +---+---+---+---+
     | 0   0   0   1 |  to   | 1   1   0   0 |
     +---+---+---+---+       +---+---+---+---+

   The MID is increased with one for each message sent. As there is a
   maximum of twelve numbers for MID usage, they will be reused. How
   this is done is described in section 5.6.
   If there is a gap between MIDs, those missing MIDs messages must be
   considered to be lost if they are not within the interval of
   reordering that ROGER has been configured to handle.


5.1.2 Code Point (CP)

   Four values of the Header Type are used for CPs. The CPs indicates
   special events to be taken and also a slightly modified header
   format. Following values of HT is used for CPs:

   CP-FLUSH
     +---+---+---+---+
     | 0   0   0   0 | : Flush everything in the DD, TRD and TST,
     +---+---+---+---+   and go into "FLUSH-STATE". The receiver of this
                         CP, must respond with a CP described in section
                         5.4.






Hannu, Christoffersson, Svanbro, Forsgren                      [Page 10]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   CP-DD
     +---+---+---+---+
     | 1   1   0   1 | : The header contains a CRC for the DD, see
     +---+---+---+---+   section 5.3.2.

   CP-FLAG
     +---+---+---+---+
     | 1   1   1   0 | : The next following four bits are used as flags,
     +---+---+---+---+   see section 5.4.

   CP-IGNORE
     +---+---+---+---+
     | 1   1   1   1 | : Do not place any part of this message in the
     +---+---+---+---+   TRD of the receiving entity or in the TST of
                         the sending entity.


5.2. ROGER Acknowledgement

   A sent or received message can not be used in the compression process
   by an entity until it is certain that the corresponding entity has
   knowledge about the specific message. For this purpose
   acknowledgments are used. A message indicated in the acknowledgments
   has been received at the entity generating the acknowledgment and is
   stored in its TRD.  Once the message has been moved from the TRD it
   will not be further acknowledged, which means that an acknowledgement
   for a received message might be carried in several consecutive
   packets.
   Three types of acknowledgments can be used as described below.


5.2.1. Cumulative Acknowledgement

   The Cumulative Acknowledgement must only be used when there is no gap
   in the message sequence it is about to acknowledge, e.g. if the
   receiving entity has received all messages up to message m, then it
   sets the Cumulative Acknowledgement to m. The Cumulative
   Acknowledgement is four bits large to handle the sequence number
   space. This is the default acknowledgement to use.


5.2.2. Bit Mask Acknowledgement

   The Bit Mask Acknowledgement must be used when there is a gap in the
   message sequence it is about to acknowledge and only when the
   interval of reordering is set to zero. The bits, which corresponds to
   the messages to be acknowledged, are set in the mask. The Bit Mask is
   twelve bits large to handle the sequence number space. The MSB bit
   corresponds to message 12. Thus, to indicate messages with
   identification numbers 2, 4 and 9 the bit-mask is set to:





Hannu, Christoffersson, Svanbro, Forsgren                      [Page 11]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 0   0   0   1   0   0   0   0 |
   +               +---+---+---+---+
   | 1   0   1   0 |
   +---+---+---+---+

   The use of this acknowledgement must be indicated by using CP-FLAG as
   described in section 5.4.

5.2.3. List Acknowledgement

   The Bit Mask Acknowledgement is replaced by a List Acknowledgement in
   the header formats, when the reordering interval is non-zero. The
   List Acknowledgement must be used when there is a gap in the received
   MID sequence. The List must contain the received MIDs in the order
   that they were received at the decompressing entity. The List
   Acknowledgement has the following format:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |     AC        |     RMID (1)  |
   +---+---+---+---+---+---+---+---+
   |    RMID (2)   |     RMID (3)  |
   +---+---+---+---+---+---+---+---+
   :                               :
   /                               /
   :                               :
   +---+---+---+---+---+---+---+---+
   |    RMID (C)   |
   +---+---+---+---+

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

   RMID: Received MID, which are being acknowledged. Must be placed in
         the List in the order that they were received at the
         decompressor entity and thus in the order the message is to be
         placed in the DD.

   The use of this acknowledgement must be indicated by using CP-FLAG as
   described in section 5.4.


5.3. CRCs

   Two types of CRCs can be carried in the ROGER header. An 8-bit CRC
   to discover residual bit errors in the messages. A 12-bit CRC to
   obtain robustness to errors in the Dynamic Dictionary.





Hannu, Christoffersson, Svanbro, Forsgren                      [Page 12]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


5.3.1 CRC for message

   The 8-bit CRC is computed over the message before compression. Then
   it is transmitted in the header of ROGER messages. After
   decompression, a CRC is computed over the decompressed message and
   compared to the CRC in the header. If these CRCs do not match, an
   error has occurred. In this case the message is not placed in the TRD
   and not acknowledged, thus the message must be treated as it had
   never arrived at the decompressor.
   The CRC polynomial is given by, C(x) = 1 + x + x^2 + x^8.

   If this CRC is present in the message header it must always be placed
   right before the compressed message.


5.3.2 CRC for Dynamic Dictionary

   The CRC for Dynamic Dictionary is a 12-bit CRC. It is used to obtain
   robustness to errors in the Dynamic Dictionary which would cause the
   decompression of messages to fail. It is computed over a text string
   representation of the content in the dynamic dictionary. This CRC is
   compared to the CRC  computed over the dynamic dictionary at the
   other entity. This can be useful when the decompressor has failed to
   decompress several consecutive  messages. The 12-bit CRC computed
   over the dynamic dictionary is signaled using CP-DD.
   The CRC-polynomial is given by, C(x) = 1 + x^2 + x^3 + x^11 + X^12.

   If this CRC is present in the message header it must always be placed
   right before the 8-bit CRC or last if the 8-bit CRC is not present.


5.4. Code Point with flags

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   0 | B   R   A   F |
   +---+---+---+---+---+---+---+---+
   The shown CP follows by four flags, which if set indicates:

   * B: The Bit Mask/List Acknowledgement is used in this message
   * R: This Bit is set to request acknowledgements, i.e. Forced
        Acknowledgements , from the receiver of this message.
   * A: This bit must only be set when this message carries Forced
        Acknowledgements
   * F: This must be set upon the reception of CP-FLUSH in every
        sent message, until the entity generating CP-FLUSH stops sending
        CP-FLUSH.








Hannu, Christoffersson, Svanbro, Forsgren                      [Page 13]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


5.4.1. Forced Acknowledgements

   In some occasions it is useful to have the opposite entity to
   acknowledge the messages it has received (i.e. those stored in the
   TRD), e.g. when the MID numbers are running low. The request is done
   using CP-FLAGS with the R bit set. To avoid inconsistency between the
   DD of the compressor and decompressor, a request must only be sent
   with CP-IGNORE.  The entity, which receives the request, must use CP-
   FLAGS with the A bit set when it responds with acknowledgements, i.e.
   Forced Acknowledgements, to the request.

   More specifically compressor A enters "REQUEST-STATE" and packets
   must be sent with CP-FLAGS/R-bit + CP-IGNORE, until a  Forced
   Acknowledgement is received from decompressor B. The messages stored
   in the TST, which are not acknowledged by the Forced acknowledgement,
   and are not in the supported reordered interval must be regarded as
   lost by the compressor and discarded. When compressor A leaves
   "REQUEST-STATE", the next MID number it should use must be larger
   than the highest Forced acknowledged MID number plus the supported
   interval of reordering.

   Decompressor B enters a "FORCEDACK-STATE" upon the reception of a
   Request, and packets (acknowledgements) must be sent using CP-FLAG/A-
   bit and the same packets must be acknowledged, until decompressor B
   receives an "ordinary" MID packet from compressor A. Decompressor B
   then leaves the "FORCEDACK-STATE" and moves the messages that were in
   the Forced Acknowledgement to the DD. Decompressor B must also be
   able to decompress reordered messages from compressor A, which are in
   the reordered interval to handle, and these messages must not make
   decompressor B leave the "FORCEDACK-STATE". They are also stored as
   usual in the TRD. Reordered packets must remain in the TRD until an
   ordinary acknowledgement for an acknowledgement is received.


5.4.2. The usage of CP-FLUSH

   Sometimes there is a need to empty everything from the dictionaries
   and tables. e.g. when a CRC for the DD indicates that something is
   wrong with the DD. If an entity wants to restart the compression
   process, it must use CP-FLUSH. Thus, the entity enters a "FLUSH-
   STATE", and must continue sending CP-FLUSH until it receives an
   acknowledgment for a message, which carried a CP-FLUSH. The
   acknowledgement must carry CP-FLAGS with the F bit set, otherwise it
   must be ignored. The entity receiving CP-FLUSH also enters a "FLUSH-
   STATE, and must respond with CP-FLAGS and the F bit set within every
   message sent, until it receives a message, which does not carry a CP-
   FLUSH. This indicates that the compressor has left the "FLUSH-STATE"
   and that the decompressor must also leave the "FLUSH-STATE".
   Messages, which carries CP-FLUSH or CP-FLAGS/F must be saved as
   usually in the TRD or TST.





Hannu, Christoffersson, Svanbro, Forsgren                      [Page 14]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


5.5. ROGER header formats

   These are the header formats of ROGER.

   Format-1:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | Header Type   | Cumulative ACK| HT = MID or CP: 1111 (CP-IGNORE)
   +---+---+---+---+---+---+---+---+
   |       CRC for Message         |
   +---+---+---+---+---+---+---+---+
   /   Compressed message          /
   +---+---+---+---+---+---+---+---+

   Format-2:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | Header Type   |MID / CP-IGNORE| HT = CP: 1101 (CP-DD)
   +---+---+---+---+---+---+---+---+
   |Cumulative ACK |   CRC for     |
   +---+---+---+---+               +
   |   Dynamic Dictionary          |
   +---+---+---+---+---------------+
   |       CRC for Message         |
   +---+---+---+---+---+---+---+---+
   /   Compressed message          /
   +---+---+---+---+---+---+---+---+

   Format-3:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | Header Type   |MID / CP-IGNORE| HT = CP: 0000 (CP-FLUSH)
   +---+---+---+---+---+---+---+---+
   |       CRC for Message         |
   +---+---+---+---+---+---+---+---+
   /   Compressed message          /
   +---+---+---+---+---+---+---+---+















Hannu, Christoffersson, Svanbro, Forsgren                      [Page 15]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   Format-4:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | Header TYPE   | B | R | A | F | HT = CP: 1110 (CP-FLAG)
   +---+---+---+---+---+---+---+---+
   :(1) HT or Padding, 4 or 8 bits :
   /                               /
   :(2) Cumulative or Bit Mask ACK :
   :           4 or 12 bits        :
   /                               /
   :(3)   CRC for DD, 12 bits      :
   /                               /
   :(4)  CRC for message, 8 bits   :
   +---+---+---+---+---+---+---+---+
   /        Compressed message     /
   +---+---+---+---+---+---+---+---+

   Format-4, is used when the information described in section 5.4, has
   to be delivered. Format-4 is also used when the Bit Mask/List
   Acknowledgement is used (B-flag is set). Then the header has the same
   format as Format-1 and Format-2 except for the first octet and the
   Cumulative Acknowledgement is replaced in the header formats at place
   (2) with the Bit Mask/List Acknowledgement.

   The compressor and decompressor respectively can use Format-4, with
   the bits R or A set, without carrying any compressed message. If this
   is the case, the following first four bits after the first octet
   should be ignored as it is padding.


5.6. Reuse of Message IDentification number (MID)

   To avoid that wrong message is being acknowledged, which could happen
   if a MID is too early reused, there is a three way handshake that
   must be completed before a MID is reused. This handshake is described
   in the example of Figure 5.2.

            Entity A                            Entity B

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

           Figure 5.2. Three way handshake for MID reuse





Hannu, Christoffersson, Svanbro, Forsgren                      [Page 16]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   Step (1):  The handshake starts with an acknowledgment that the
              message has been received, in this example, by Entity B

   Step (2):  The acknowledgement from Entity B is then implicitly
              acknowledged by, in this example, Entity A.

   Step (3):  At the reception of the acknowledgement from Entity B,
              the acknowledgement from Entity A is implicitly
              acknowledged, and MID-1A can be reused, i.e. a MID cannot
              be reused until it has stopped being acknowledged.

   Although, the example in Figure 5.2 shows a strict request/reply
   pattern, the design of ROGER is done so it can handle non-strict
   request/reply patterns.


5.7. Dictionary memory space

   There will be a limited physical memory space for the dynamic
   dictionary. This section describes two implementations. One with a
   sliding window for the DD and one were the DD is filled up to the
   physical limit, and is kept at that size.


5.7.1. Sliding window

   In the case when a sliding window is used for the DD, the parts of
   the DD that are shifted out must be saved so that reordered messages
   can be decompressed. Thus, when a compressed reordered message is in
   the interval, a temporary  dictionary, which the message was
   compressed with, is reconstructed and the message is decompressed. It
   is then treated in an ordinary fashion (put into the TRD). If the
   reordered interval is set to zero, there is no need to save parts
   that are shifted out from the DD, because reordered packets is in
   this case regarded as lost.


5.7.2. No deletion

   When there is no deletion from the DD, there is a need to signal to
   the opposite entity when the DD is full. This is done to avoid
   unnecessary large message headers.
   CP-IGNORE and the Cumulative Acknowledgement set to number 13 is used
   to signal to the other entity that its DD is full. Thus, when an
   entity finds out that its DD will be full when it receives an
   acknowledgement for the packet it is about to send ("packet full").
   Then the other entity's DD, will be full first and send CP-IGNORE
   with Cumulative Acknowledgement set to number 13, this CP-
   IGNORE/CUMACK-13 will serve as an acknowledgement for the
   acknowledgements in "packet full" and those message can be moved from





Hannu, Christoffersson, Svanbro, Forsgren                      [Page 17]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   TRD to DD, which makes DD full. Both sides will hereafter send CP-
   IGNORE/CUMACK-13.


5.8. Avoiding deadlock

   If more than 12 consecutive messages in one direction are sent
   without any acknowledgement has been received, the compressor runs
   out of MIDs and a deadlock may occur if all 12 messages were lost. To
   avoid this, the following scheme will restart the compression.
   Messages sent within a prescribed time after the 12Ăth message must
   be sent with CP-IGNORE or request an acknowledgement using CP-FLAGS
   with the R bit set. The compressor waits for acknowledgements for a
   prescribe time. After the prescribed time period and if no
   acknowledgment has been received, CP-FLUSH is sent. This signals that
   the DD, TRD and TST are emptied and the compression scheme restarts.
   If no acknowledgement is received for this message the procedure is
   repeated.

   Note: The prescribed time period and how to use the CP-FLAGS/R-bit is
   decided at implementation.


5.9. User Semi-Static Dictionary

   The Static Dictionary (SD) is the same for packets flows rendering
   from different users as it is predefined. However, the User Semi-
   Static Dictionary (USSD), is a dictionary containing user specific
   information, which could be useful to have already at the start of
   compression. The USSD would work in conjunction with the SD. Figure
   5.3 shows the search order using the dictionaries, starting with the
   SD.

   +---------+---------+---------+
   |   SD    |   USSD  |   DD    |
   +---------+---------+---------+
   Figure 5.3. Search order for the compression algorithm

   The information in the USSD is not specified in this draft, but
   information, such as frequently connected addresses could be in USSD.

   The information in the USSD should be exchanged between the involved
   entities' compressor and decompressor during the negotiation phase
   for the usage of ROGER. How, the negotiation is done is out of the
   scope for this draft, but the USSD should then be transported in
   conjunction with other parameters for ROGER compression.









Hannu, Christoffersson, Svanbro, Forsgren                      [Page 18]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


6. Modes of implementation

   In the following sections of this draft the compressor/decompressor
   entities will be referred  to as entity-u (entity-uplink) and entity-
   d (entity-downlink), see Figure 6.1. Entity-uĂs compressor sends
   messages to entity-dĂs decompressor and entity-dĂs compressor sends
   messages to entity-uĂs decompressor. Depending on how the compressor
   and decompressor at one entity resides, or more specifically, to what
   extent they are able to communicate, different modes of
   implementation are possible. The compression efficiency will vary
   depending on the implemented mode. The following three sections
   describe the different scenarios for the implementations. Although
   Figure 6.1 shows a mobile communicating with a base station, the
   ROGER scheme could be applied to other types of systems and
   scenarios.

   Mobile, entity-d            Fixed network, entity-u
    |    ................              |  |
   ++                   /              +--+
   ||                   ............>   ||
   ++                                   /\
                                       /  \

   Figure 6.1. Placement of the compression entities


   An implementation of the Full contact mode can run on all of the
   identified scenarios described in this draft. The other two modes
   should be considered as optimizations for systems, were Full contact
   mode can not be fully utilized.


6.1. No contact mode

   The compressor and decompressor residing at the same entity are
   unable to communicate. Also, the decompressor at entity-u is unable
   to communicate with the compressor at entity-d and vice versa, making
   use of acknowledgements impossible. This precludes the use of ROGER
   headers. Thus, in this particular case no ROGER header is attached to
   the message. This also implies that the compressor at entity-d never
   can be positive that a sent message has been received at the
   decompressor of entity-u. Consequently, use of a dynamic dictionary
   would make decompression impossible if a previous packet had been
   lost. Only the static dictionary can be used without losing
   robustness against packet losses. Figure 6.2 shows this scenario.










Hannu, Christoffersson, Svanbro, Forsgren                      [Page 19]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


                   Entity-d                    Entity-u
                  +---------+                 +---------+
                  |  Comp.  |---------------->| Decomp. |
                  +---------+                 +---------+

                  +---------+                 +---------+
                  | Decomp. |<----------------|  Comp.  |
                  +---------+                 +---------+

   Figure 6.2. No information about the arrival of sent messages reaches
   the compressor.


6.1.1. Compression

   Compression is carried out by using the static dictionary only.

   * Compression steps

   1) Compress message using SD
   2) Send message


6.1.2. Decompression

   Decompression is carried out by using the static dictionary only.

   * Decompression steps

   1) Decompress message using SD


6.2. Limited contact mode

   The decompressor at e.g. entity-u can acknowledge messages to the
   compressor at entity-d. The decompressor at entity-u has a system
   provided link, which from ROGER's point of view looks like a direct
   link, to the compressor at entity-d, see Figure 6.3.

    Entity-d                    Entity-u
   +---------+                 +---------+
   |  Comp.  |---------------->| Decomp. |
   |         |<-----ACK--------|         |
   +---------+                 +---------+

   Figure 6.3. Acknowledgements generated by decompressor.
   From ROGERĂs point of view, the acknowledgements has the same format
   as the message headers described in Chapter 5, except for the CRC
   intended for the message.






Hannu, Christoffersson, Svanbro, Forsgren                      [Page 20]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


6.2.1. Compression

   When the session starts, the dynamic dictionary and the TST are
   empty. The message is compressed using the static and the dynamic
   dictionary and is also stored in the TST. The message header
   indicates which message is sent and which acknowledgements that have
   been received.


   * Compression steps:

   1) If necessary, move content of TST to DD
   2) Compress using SD+DD
   3) Put message in TST
   4) Attached header
   5) Send message


6.2.2. Decompression

   Decompression is done by first looking at the header attached to the
   compressed message. The header indicates which messages were in the
   DD when the message was compressed. That is, the header indicates
   which acknowledgements that have arrived to the compressor and the
   messages corresponding to the acknowledgements are used in the
   compression process. The decompressor makes sure that the same
   messages are used for decompression, i.e. moving the content of the
   TRD to the DD which is indicated in the header. The received message
   is put into the TRD and an acknowledgement is sent to the compressor.
   One could consider to use a sparse acknowledging scheme here.

   * Decompression steps:

   1) If necessary move content of TRD to DD, see Section 6.4.1.
   2) Decompress message using SD+DD
   3) Put message in TRD
   4) Send Acknowledgement


6.3. Full contact mode

   The compressor and decompressor on both sides reside together. Thus,
   both sent and received messages can be used in the compression
   process since the compressor and decompressor share dictionaries. The
   decompressor uses the compressor, which it resides together with, to
   inform the compressor on the other side that a message has been
   received. This is done by an indication in the sent message's header.
   See Figure 6.6 for scenario.







Hannu, Christoffersson, Svanbro, Forsgren                      [Page 21]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   +---------+                 +----------+
   | Comp./  |---------------->| Decomp./ |
   | Decomp. |<----------------| Comp.    |
   +---------+                 +----------+

   Figure 6.6. Compressor and decompressor reside together and are able
   to share the context.


6.3.1. Compression

   Compression is done using the SD, the DD and the TRD. The sent
   message is put into the TST. The message ID is put into the header
   together with the acknowledgement indicating which messages have been
   received and not yet been put into the DD.

   * Compression steps:

   1) Compress using SD+DD+TRD
   2) Put message in TST
   3) Attach header
   4) Send message

   An implementation of the Full contact mode can run on all of the
   identified scenarios described in this draft. The other two modes
   should be considered as optimizations for systems, were Full contact
   mode can not be fully utilized.


6.3.2. Decompression

   The decompression starts by reading the message header. If the
   acknowledgement indicates a previous sent message which acknowledged
   an earlier received message this earlier received message is moved
   from the TRD to the DD. If the acknowledgement indicates that a
   previously sent message has been received at the other entity this
   previously sent message is moved from the TST to the DD.

   * Decompression steps:

   1) If necessary move content of TRD to DD, see Section 6.4.1.
   2) If necessary move content of TST to DD, see Section 6.4.2.
   3) Decompress message using SD+DD
   4) Put message in TRD
   5) Send acknowledgment if needed


6.4. Move of table content

   This section defines when to move contents from the TRD or TST to the
   DD. In general the order for movement is:




Hannu, Christoffersson, Svanbro, Forsgren                      [Page 22]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   1) move contents from TRD to DD
   2) move contents from TST to DD.

   The contents of the TRD and TST may be several messages. Only the
   messages that correspond to a certain acknowledgement are moved.


6.4.1. TRD to DD

   When a message is sent carrying indications of received messages in
   the TRD, a mapping between the message ID and the IDs of the messages
   stored in the TRDT is made. When a future message is received by this
   entity, the entity withdraws the acknowledged messages IDs from the
   received message header. The acknowledged messages IDs are compared
   with the IDs stored in the TRDT. If there is a match the
   corresponding contents in the TRD (given by the mapping) is moved to
   the DD and the mapping is removed from the TRDT. If the next received
   message carries the same acknowledgment it will not cause
   difficulties since the mapping has been removed from the TRDT.


6.4.2. TST to DD

   The contents of the TST is moved to the DD when an acknowledgement is
   received for the message stored in the TST. The TST must be
   constructed so that if the next following messages acknowledge the
   same message there is no move of content from the TST to the DD.


7. ROGER requirements

   For the three modes there are some requirements on the involved
   protocols/layers where ROGER compression is applied.

   1. Negotiation

   1a. There should be a mechanism for negotiating whether ROGER
   compression is to be used or not.

   1b. Maximum physical memory dynamic dictionary size must also be
   negotiated. This could be done by a carrying a parameter in the
   negotiating message, stating "Max DD= A", the response from the other
   entity states its "Max DD= B", the size of the DD to use in the
   compression process is then chosen to be the minimum of A and B.

   1c. The mode ROGER is to run is an implementation issue. However,
   note that an implementation of ROGER in the full contact mode also
   can run in the other two modes if needed.







Hannu, Christoffersson, Svanbro, Forsgren                      [Page 23]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   1d. The interval of reordering ([MID-N,MID]) that ROGER must support,
   should be negotiated before compression starts. N must be chosen to
   be less than the number of MIDs used.

   This draft does not state how the negotiation should be done.

   2. Context identification

   2a. There must be means to identify the flow(s) that correspond to a
   certain context. How, this is done depends on the environment where
   ROGER is placed. Thus, this is an implementation issue.

   3. Feedback

   3a. As ROGER does not define any piggyback headers, it is up to the
   other layers/protocols to provide the feedback to the ROGER entities,
   e.g. by a dedicated feedback channel.

   3b. Its up the implementation to associate flows, when shared
   contexts are in use for the full contact mode.

   4. Dictionary maintenance

   4a. The ROGER context at the compressor and the decompressor must be
   kept equally long to avoid that a compressed message can not be
   decompressed. How, this is done depends on the environment where
   ROGER is placed. Thus, this is an implementation issue. However, CP-
   FLUSH can of course always be used to flush the dictionaries.

   4b. The dictionaries at compressor and decompressor must be updated
   according to the same procedure, otherwise it is impossible to
   decompress a compressed message.

   A ROHC profile for ROGER is described in chapter 9.


8. Implementation status

   ROGER as defined in this draft is implemented by Ericsson ///. The
   implementation work started with the 00-version, and has provided
   useful experience, which lead to the updates in this 01-version of
   the ROGER scheme.
   Compression tests, using the implementation of ROGER 01-version, also
   validate the results in chapter 10.


9. ROGER over ROHC - A new ROHC profile

   ROGER is suitable for compression of ASCII based protocol messages,
   The ASCII protocol messages mentioned in this draft are all carried





Hannu, Christoffersson, Svanbro, Forsgren                      [Page 24]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   on top of UDP/IP or TCP/IP, [UDP],[TCP,[IP]. This chapter describes
   how ROGER could fit into the ROHC framework.

   Figure 9.1 shows a packet before and after compression with ROGER
   included in ROHC. CM is compressed information e.g. SIP/SDP, H is the
   ROGER header and R is the ROHC header handling the UDP/IP part of the
   packet.

        +--------+---------+                      +---+---+----+
        | IP/UDP | SIP/SDP |---- compression ---->| R | H | CM |
        +--------+---------+                      +---+---+----+
             Figure 9.1. Packet before and after compression.


9.1. ROGER profile in the ROHC framework

   The compression scheme ROGER could be made as a part of the ROHC
   framework. Profile 2 in ROHC is a UDP/IP compression profile. A new
   profile which has the same functions and packet types as profile 2
   and includes ROGER could be defined. Thus, the new profile would also
   compress the UDP payload with ROGER. Another profile can also be
   defined in a similar manner using the future ROHC TCP profile.


9.1.1. Limited contact mode

   The limited contact mode implementation of ROGER, does not require
   any changes to the ROHC scheme or any additional features from the
   system that are not already required by ROHC. The next section
   describes the packet types to fit ROGER into the ROHC scheme.


9.1.1.1. Packet types

   The packet types of this combination of ROHC and ROGER have the same
   formats as defined in ROHC for profile 2 with the addition of the
   ROGER message header. The ROGER message header is placed at the end
   of the profile 2 ROHC header:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   :                               :
   /      ROHC profile 2 header    /
   :                               :
   +---+---+---+---+---+---+---+---+
   :                               :
   /          ROGER HEADER         /
   :                               :
   +---+---+---+---+---+---+---+---+
   /      Compressed message       /
   +---+---+---+---+---+---+---+---+




Hannu, Christoffersson, Svanbro, Forsgren                      [Page 25]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001




   The feedback types are the same for ROHC profile 2, with the addition
   of this option:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |  Opt Type = 5 |  Opt Len = *  |
   +---+---+---+---+---+---+---+---+
   :                               :
   /          ROGER HEADER         /   - ROGER feedback
   :                               :
   +---+---+---+---+---+---+---+---+
   /                               /   - Other types of feedback
   +---+---+---+---+---+---+---+---+

   *If the "Opt Len" field has a value larger than the length of the
    ROGER header there are more feedback options in this packet, which
    starts after the ROGER feedback.


9.1.2. Full contact mode

   ROGER gains in compression efficiency if the dictionaries can be
   shared between the compressor and decompressor at the entities. How
   to share contexts is not defined in the ROHC scheme and is therefore
   regarded as an implementation issue. However, this feature must be
   implemented on both sides of the link. The use of shared dictionaries
   requires that it is possible to associate the entities inbound and
   outbound flows.

   The criteria for associating the flows could be the IP-addresses and
   possibly also the port numbers. It is necessary that both the uplink
   and downlink flows pass through the same point.


9.1.2.1.  Packet types

   The packet types of this combination of ROHC and ROGER have the same
   formats as defined in ROHC for profile 2 with the addition of the
   ROGER message header. Thus, the packet types are the same as
   described in section 9.1.1.1.


10. Evaluation of compression scheme

   A small test in the limited contact and full contact mode situations
   was carried out to evaluate the performance of ROGER. The messages
   from a SIP trace of a call setup were compressed. The packet flow
   consisted of 13 messages sent between a client and a SIP proxy.





Hannu, Christoffersson, Svanbro, Forsgren                      [Page 26]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   The compression was performed using an implementation of the LZSS
   algorithm as described in Section 4. To determine the size of the
   compressed file, the size of the compressed dictionary was compared
   to the size of the compressed extended file.

   The static dictionary used for the compression and decompression is
   built up by header field names e.g.; To:, From:, and Via:

   In the limited contact mode it was assumed that every message was
   acknowledged before the next message was sent, i.e. a dedicated
   channel was available. This gives a slightly better compression than
   if piggy-backing on SIP messages travelling in the opposite direction
   is used, since this gives a slower dictionary expansion.

   The results in terms of compression factors (size uncompressed/size
   compressed) are given in Table 1. The over all compression factors
   were 3.3 for the limited contact mode and 4.6 for the full contact
   mode.

   Message #        Originating source       Compression factor
                                             Limited   Full
       1                  Client               1.5      1.5
       2                  Proxy                1.5      5.6
       3                  Proxy                1.9      3.1
       4                  Client               3.5      4.9
       5                  Proxy                5.2      6.4
       6                  Client               5.7      5.7
       7                  Proxy                6.8      8.1
       8                  Proxy                7.4      8.3
       9                  Proxy                6.9      7.0
       10                 Client               7.2      7.4
       11                 Proxy                7.1      7.8
       12                 Proxy                6.6      7.9
       13                 UAC                  7.8      7.8

   Table 1.

   As can be seen from the table, compression is more efficient in the
   full contact mode. This is due to the fact that the dictionaries grow
   faster since both sent and received messages are used.


11. Conclusions

   This draft has presented the compression scheme ROGER for application
   signaling protocols. The scheme is simple to implement and shows
   promising results for compression of the ASCII based protocols
   SIP/SDP, and can be expected to have a similar performance on other
   ASCII based protocols such as RTSP.






Hannu, Christoffersson, Svanbro, Forsgren                      [Page 27]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


   Three modes of implementation exists; No contact mode, Limited
   contact mode, and Full contact mode. The mode should be chosen at the
   time of implementation. It should be noted that Full contact mode can
   be used in all of the defined scenarios without any modifications.
   Requirements on the layers/protocols where to run ROGER are listed in
   the draft.
   This draft also presents a new profile in the ROHC framework.


12. Security considerations

   In general encryption and compression do not go very well. More
   specifically, messages that are encrypted are not possible to
   compress efficiently. It is of course possible to run a loss less
   compression algorithm like ROGER on an encrypted message, but the
   compression will most likely not decrease the size of the message.


13. IANA considerations

   An implementation of ROGER, might need some IANA involvement
   depending on the layers/protocols that ROGER is implemented with.

   E.g. if ROGER is to be a part of the ROHC framework some ROHC profile
   identifiers must be reserved by the IANA.


14. Acknowledgements

   Thanks to Arto Mahkonen, Ericsson LMF, Lars-Erik Jonsson and Mats
   Nordberg, Ericsson Erisoft, for their valuable input to this work.


15. Intellectual property rights considerations

   Ericsson has filed patent applications that might possibly have
   technical relations to this contribution.
   See further: http://www.ietf.org/ietf/IPR/ERICSSON-General 


16. Author's Addresses

     Hans Hannu               Tel: +46 920 20 21 84
     Ericsson Erisoft AB
     Lulea, Sweden            EMail: Hans.Hannu@epl.ericsson.se

     Jan Christoffersson      Tel: +46 920 20 28 40
     Ericsson Erisoft AB
     Lulea, Sweden            EMail: Jan.Christoffersson@epl.ericsson.se






Hannu, Christoffersson, Svanbro, Forsgren                      [Page 28]

INTERNET-DRAFT   RObust GEneric message size Reduction    July 06, 2001


     Krister Svanbro          Tel: +46 920 20 20 77
     Ericsson Erisoft AB
     Lulea, Sweden            EMail: Krister.Svanbro@epl.ericsson.se

     Stefan Forsgren          Tel: +46 920 20 23 39
     Ericsson Erisoft AB
     Lulea, Sweden            EMail: Stefan.Forsgren@epl.ericsson.se


16. References

   [APP]       H. Hannu, J. Christoffersson and K. Svanbro, Application
               signaling over cellular links, Internet Draft (work in
              progress), March 2001.
              <draft-hannu-rohc-signaling-cellular-01.txt>

   [CELL]      L. Westberg and M. Lindqvist, Realtime traffic over
               cellular access networks, Internet Draft (work in
               progress), June 2001.
               <draft-westberg-realtime-cellular-04.txt>

   [HTTP]      R. Fielding, et. al., Hypertext Transfer Protocol ű
               HTTP/1.1. RFC 2616, June 1999.

   [IP]        J. Postel, Internet Protocol, RFC 791, September 1981.

   [LZSS]      J.A. Storer and T.G. Szimanski, Data Compression via
               Textual Substitutions. Journal of the ACM 29, 1982.

   [ROHC]      C. Bormann, Et. al., RObust Header Compression, Internet
              Draft (work in progress), February 2001.
               <draft-ietf-rohc-rtp-09.txt>

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

   [SDP]       M. Handley and V. Jacobson, SDP: Session Description
               Protocol. RFC 2327, April 1998.

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

   [TCP]       J. Postel, Transmission Control Protocol, RFC 793,
               September 1981.

   [UDP]       J. Postel, User Datagram Protocol, RFC 761, August 1980.


   This Internet-Draft expires in January 2002.






Hannu, Christoffersson, Svanbro, Forsgren                      [Page 29]