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

Versions: (draft-ietf-rohc-rtp-rocco) 00 01 02 03 04 05 06 07 08 RFC 3095

Network Working Group              Carsten Bormann (ed.), TZI/Uni Bremen
INTERNET-DRAFT                                                        xx
Expires: December 2000                                                xx
                                          Carsten Burmeister, Matsushita
                                              Christopher Clanton, Nokia
                                      Mikael Degermark, Lulea University
                                           Hideaki Fukushima, Matsushita
                                                    Hans Hannu, Ericsson
                                             Lars-Erik Jonsson, Ericsson
                                              Rolf Hakenberg, Matsushita
                                                      Tmima Koren, Cisco
                                                         Khiem Le, Nokia
                                                      Zhigang Liu, Nokia
                                            Akihiro Miyazaki, Matsushita
                                               Krister Svanbro, Ericsson
                                               Thomas Wiebke, Matsushita
                                                    Haihong Zheng, Nokia

                                                           June 29, 2000



                    RObust Header Compression (ROHC)
                      <draft-ietf-rohc-rtp-00.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 product of the IETF ROHC WG. Comments should be
   directed to its mailing list, rohc@cdt.luth.se.



Bormann (ed.)                                                   [Page 1]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



Abstract

   Existing header compression schemes do not work well when used over
   links with significant error rates, especially when the round-trip
   time of the link is long. For many bandwidth limited links where
   header compression is essential, such characteristics are common.

   A header compression framework and a highly robust and efficient
   header compression scheme is introduced in this document, adaptable
   to the characteristics of the link over which it is used and also to
   the properties of the packet streams it compresses.










































Bormann (ed.)                                                   [Page 2]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


Table of contents

   1.  Introduction..................................................4
   2.  Terminology...................................................6
   3.  Background....................................................9
        3.1.  Header compression fundamentals........................9
        3.2.  Existing header compression schemes....................9
        3.3.  Requirements on a new header compression scheme.......10
        3.4.  Classification of header fields.......................11
   4.  Header compression framework.................................
        4.1.  Operating assumptions.................................
        4.2.  Dynamicity............................................
        4.3.  Compression and decompression states..................
        4.4.  Different modes of operation..........................
        4.5.  Encoding methods......................................
               4.5.1.  Least Significant Bits (LSB) encoding........
               4.5.2.  Least Significant Part (LSP) encoding........
               4.5.3.  LSB or LSP encoding with extended range......
        4.6.  Requirements on lower layers..........................
   5.  The protocol.................................................
        5.1.  Data structures.......................................
               5.1.1.  Per-channel parameters.......................
               5.1.2.  Per-CID parameters, profiles.................
               5.1.3.  Contexts.....................................
        5.2.  Packet types..........................................
               5.2.1   Packets from compressor to decompressor......
               5.2.2.  Feedback from decompressor to compressor.....
               5.2.3.  Parameters needed for mode transition........
        5.3.  Operation in unidirectional mode......................
               5.3.1.  Compressor states and logic..................
               5.3.2.  Decompressor states and logic................
        5.4.  Operation in bi-directional optimistic mode...........
               5.4.1.  Compressor states and logic..................
               5.4.2.  Decompressor states and logic................
        5.5.  Operation in bi-directional reliable mode.............
               5.5.1.  Compressor states and logic..................
               5.5.2.  Decompressor states and logic................
        5.6.  Mode transitions......................................
               5.6.1.  From Unidirectional to Optimistic mode.......
               5.6.2.  From Optimistic to Reliable mode.............
               5.6.3.  From Reliable to Optimistic mode.............
               5.6.4.  From Optimistic to Unidirectional mode.......
        5.7.  Packet formats
               5.7.1.  Static information packets, initialization...
               5.7.2.  Dynamic information packets..................
               5.7.3.  Compressed packets...........................
               5.7.4.  Extensions to compressed headers.............
               5.7.5.  Feedback packets.............................
        5.8.  Encoding of field values..............................
               5.8.1.  LSP encoding of field values.................
               5.8.2.  LSB encoding of field values.................



Bormann (ed.)                                                   [Page 3]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


               5.8.3.  Timer-based timestamp decompression..........
        5.9.  Header compression CRCs, coverage and polynomials.....
               5.9.1.  STATIC packet CRC............................
               5.9.2.  DYNAMIC packet CRC...........................
               5.9.3.  COMPRESSED packet CRCs.......................
   6.  Implementation issues........................................
        6.1.  Reverse decompression.................................
        6.2.  Pre-verification of CRCs..............................
        6.3.  New reconstruction attempts with LSB and LSP encoding.
   7.  Further work.................................................
   8.  Implementation status........................................
   9.  Security considerations......................................
   10. Acknowledgements.............................................
   11. Intellectual property considerations.........................
   12. References...................................................
   13. Authors' addresses...........................................

   Appendix A.  Detailed classification of header fields
        A.1.  General classification
               A.1.1.  IPv6 header fields
               A.1.2.  IPv4 header fields
               A.1.3.  UDP header fields
               A.1.4.  RTP header fields
               A.1.5.  Summary for IP/UDP/RTP
        A.2.  Analysis of change patterns of header fields
               A.2.1.  IPv4 Identification
               A.2.2.  IP Traffic-Class / Type-Of-Service
               A.2.3.  IP Hop-Limit / Time-To-Live
               A.2.4.  UDP Checksum
               A.2.5.  RTP CSRC Counter
               A.2.6.  RTP Marker
               A.2.7.  RTP Payload Type
               A.2.8.  RTP Sequence Number
               A.2.9.  RTP Timestamp
               A.2.10. RTP Contributing Sources (CSRC)
        A.3.  Header compression strategies
               A.3.1.  Do not send at all
               A.3.2.  Transmit only initially
               A.3.3.  Transmit initially, update occasionally
               A.3.4.  Be prepared to update or send as-is
               A.3.5.  Guarantee continuous robustness
               A.3.6.  Transmit as-is in all packets
               A.3.7.  Establish and be prepared to update delta


   (Editor's note: The TOC has not been updated.

   I have marked text I consider questionable by making it italic, and
   text that I think simply should be deleted by striking it through.)





Bormann (ed.)                                                   [Page 4]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


1.  Introduction

   During the last five years, two communication technologies in
   particular have become commonly used by the general public: cellular
   telephony and the Internet. Cellular telephony has provided its users
   with the revolutionary 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.

   Today, IP telephony is gaining momentum thanks to improved technical
   solutions. It seems reasonable to believe that in the years to come,
   IP will become a commonly used way to carry telephony. Some future
   cellular telephony links might also be based on IP and IP telephony.
   Cellular phones may have IP stacks supporting not only audio and
   video, but also web browsing, email, gaming, etc.

   One of the scenarios we are envisioning might then be the one in
   Figure 1.1, where two mobile terminals are communicating with each
   other. Both are connected to base stations over cellular links, and
   the base stations are connected to each other through a wired (or
   possibly wireless) network. Instead of two mobile terminals, there
   could of course be one mobile and one wired terminal, but the case
   with two cellular links is technically more demanding.


   Mobile            Base                      Base            Mobile
   Terminal          Station                   Station         Terminal


         |  ~   ~   ~  \ /                       \ /  ~   ~   ~   ~  |
         |              |                         |                  |
      +--+              |                         |               +--+
      |  |              |                         |               |  |
      |  |              |                         |               |  |
      +--+              |                         |               +--+
                        |                         |
                        |=========================|

            Cellular              Wired               Cellular
            Link                  Network             Link

        Figure 1.1 : Scenario for IP telephony over cellular links

   It is obvious that the wired network can be IP-based. With the
   cellular links, the situation is less clear. IP could be terminated
   in the fixed network, and special solutions implemented for each
   supported service over the cellular link. However, this would limit



Bormann (ed.)                                                   [Page 5]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   the flexibility of the services supported. If technically and
   economically feasible, a solution with pure IP all the way from
   terminal to terminal would have certain advantages. However, to make
   IP-all-the-way a viable alternative, a number of problems have to be
   addressed, especially regarding bandwidth efficiency.

   For cellular phone systems, it is of vital importance to use the
   scarce radio resources in an efficient way. A sufficient number of
   users per cell is crucial, otherwise deployment costs will be
   prohibitive [CELL]. The quality of the voice service should also be
   as good as in today's cellular systems. It is likely that even with
   support for new services, lower quality of the voice service is
   acceptable only if costs are significantly reduced.

   A problem with IP over cellular links when used for interactive voice
   conversations is the large header overhead. Speech data for IP
   telephony will most likely be carried by RTP [RTP]. A packet will
   then, in addition to link layer framing, have an IP [IPv4] header (20
   octets), a UDP [UDP] header (8 octets), and an RTP header (12 octets)
   for a total of 40 octets. With IPv6 [IPv6], the IP header is 40
   octets for a total of 60 octets. The size of the payload depends on
   the speech coding and frame sizes used and may be as low as 15-20
   octets.

   From these numbers, the need for reducing header sizes for efficiency
   reasons is obvious. However, cellular links have characteristics that
   make header compression as defined in [IPHC,CRTP,PPPHC] perform less
   than well. The most important characteristic is the lossy behavior of
   cellular links, where a bit error rate (BER) as high as 1e-3 must be
   accepted to keep the radio resources efficiently utilized [CELL]. In
   severe operating situations, the BER can be as high as 1e-2. The
   other problematic characteristic is the long round-trip time (RTT) of
   the cellular link, which can be as high as 100-200 milliseconds
   [CELL]. A viable header compression scheme for cellular links must be
   able to handle loss on the link between the compression and
   decompression point as well as loss before the compression point.

   Bandwidth is the most costly resource in cellular links. Processing
   power is very cheap in comparison. Implementation or computational
   simplicity of a header compression scheme is therefore of less
   importance than its compression ratio and robustness.













Bormann (ed.)                                                   [Page 6]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


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.

   BER

    Bit Error Rate. Cellular radio links have a rather high BER. In
    this document BER is usually given as a probability, but one also
    needs to consider the error distribution as bit errors are not
    independent. In our simulations we use a channel with a certain
    BER, and the error distribution is according to a realistic channel
    [WCDMA].

   Cellular links

    Wireless links between mobile terminals and base stations. The BER
    and the RTT are rather high in order to achieve an efficient system
    overall.

   Compression efficiency

    The performance of a header compression scheme can be described
    with three parameters, compression efficiency, robustness and
    compression reliability. The compression efficiency is determined
    by how much the header sizes are reduced by the compression scheme.

   Compression reliability

    The performance of a header compression scheme can be described
    with three parameters, compression efficiency, robustness and
    compression reliability. The compression reliability is a measure
    for how well the scheme ensures that the decompressed headers are
    not erroneous and the possibility to avoid damage propagation from
    the decompressor.

   Context

    The context is the state which the compressor uses to compress a
    header and which the decompressor uses to decompress a header. The
    context basically contains the uncompressed version of the last
    header sent (compressor) or received (decompressor) over the link,
    except for fields in the header that are included "as-is" in
    compressed headers or can be inferred from, e.g., the size of the
    link-level frame. The context can also contain additional
    information describing the packet stream, for example the typical
    inter-packet increase in sequence numbers or timestamps.






Bormann (ed.)                                                   [Page 7]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   Context damage

    When the context of the decompressor is not consistent with the
    context of the compressor, header decompression will fail. This
    situation can occur when the context of the decompressor has not
    been initialized properly or when packets have been lost or damaged
    between compressor and decompressor. Packets which cannot be
    decompressed due to inconsistent contexts are said to be lost due
    to context damage.   Packets that are incorrectly reconstructed due
    to context damage are said to have suffered damage propagation.


   Context repair mechanism

    To avoid excessive context damage, a context repair mechanism is
    needed. Context repair mechanisms can be based on explicit requests
    for context updates, periodic updates sent by the compressor, or
    methods for local repair at the decompressor side.

   FER

    Frame Error Rate. The FER considered in this document includes the
    frames lost on the channel between compressor and decompressor and
    frames lost due to context damage. FER is here defined to be
    identical to packet loss rate.

    (Editor: A much better definition would be to reserve FER for the
    error rate we get from lower layers and use PER for the error rate
    we generate/hand up.)

   Header compression profile

    A header compression profile is a specification of how to compress
    the headers of a certain kind of packet stream over a certain kind
    of link. Compression profiles provide the details of the header
    compression framework introduced in this document. The profile
    concept makes use of profile identifiers to separate different
    profiles which are used when setting up the compression scheme. All
    variations and parameters of the header compression scheme are
    handled by different profile identifiers, which makes the number of
    profiles rather large. This can act as a deterrent when first
    studying the concept, but is a real strength for several reasons.
    One advantage of this merging of parameters into one is that new
    parameters can be added by the endpoints without affecting the
    negotiation requirements on the link in between. Another benefit of
    the concept is that different combinations of functionality might
    be implemented with different methods, meaning that the scheme can
    be optimized regardless of what functionality is enabled. Finally,
    it should be noted that even if there are a large number of
    profiles, only a small number of them can/will be implemented over
    a specific link (IPv4 and IPv6 profiles will for example probably



Bormann (ed.)                                                   [Page 8]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


    not coexist). Most profiles usable in a certain environment will
    probably also be almost identical from an implementation point of
    view.


   Header compression CRC

    A CRC (Cyclic Redundancy Checksum) computed by the compressor and
    included in each compressed header. Its main purpose is to provide
    a way for the decompressor to reliably verify the correctness of
    reconstructed headers. What values the CRC is computed over depends
    on the packet type it is included in; typically it covers most of
    the original header fields.

   Pre-HC links

    Pre-HC links are all links a packet has traversed before the header
    compression point. If we consider a path with cellular links as
    first and last hops, the Pre-HC links for the compressor at the
    last link are the first cellular link plus the wired links in
    between.

   Robustness

    The performance of a header compression scheme can be described
    with three parameters, compression efficiency, robustness and
    compression reliability. A robust scheme tolerates errors on the
    link over which header compression takes place without losing
    additional packets, introducing additional errors, or using more
    bandwidth.

   RTT

    Round Trip Time - The time it takes to send a packet back and forth
    over the link.

   Simplex link

    A simplex (or unidirectional) link is a point to point link without
    a return channel. Over simplex links, header compression must rely
    on periodic refreshes since feedback from the decompressor can not
    be sent to the compressor. For simplex links, a header compression
    CRC is mandatory to guarantee correct decompression.

   Spectrum efficiency

    Radio resources are limited and expensive. Therefore they must be
    used efficiently to make the system economically feasible. In
    cellular systems this is achieved by maximizing the number of users
    served within each cell, while the quality of the provided services
    is kept at an acceptable level. A consequence of efficient spectrum



Bormann (ed.)                                                   [Page 9]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


    use is a high rate of errors (frame loss and residual bit errors),
    even after channel coding with error correction.

   Timestamp delta

    The timestamp delta is the increase in the timestamp value between
    two consecutive packets.















































Bormann (ed.)                                                  [Page 10]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


3.  Background

   This chapter provides a background to the subject of header
   compression. The fundamental ideas are described together with
   descriptions of existing header compression schemes, their drawbacks
   and requirements and motivation for new header compression solutions.


3.1.  Header compression fundamentals

   The main reason why header compression can be done at all is the fact
   that there is lots of redundancy between header fields, both within
   the same packet header but especially between consecutive packets
   belonging to the same packet stream. By sending static field
   information only initially and utilizing dependencies and
   predictability for other fields, the header size can be significantly
   reduced for most packets.

   In general, header compression methods maintain a context, which is
   essentially  the uncompressed version of the last header sent over
   the link, at both compressor and decompressor. Compression and
   decompression are done relative to the context. When compressed
   headers carry differences from the previous header, each compressed
   header will update the context of the decompressor. In this case,
   when a packet is lost between compressor and decompressor, the
   context of the decompressor will be brought out of sync since it is
   not updated correctly. A header compression method must have a way to
   repair the context, i.e. bring it into sync, after such events.


3.2.  Existing header compression schemes

   The original header compression scheme, CTCP [VJHC], was invented by
   Van Jacobson. CTCP compressed the 40 octet IP+TCP header to 4 octets.

   The CTCP compressor detects transport-level retransmissions and sends
   a header that updates the context completely when they occur. This
   repair mechanism does not require any explicit signaling between
   compressor and decompressor.

   CRTP [CRTP, IPHC] by Casner and Jacobson is a header compression
   scheme that compresses 40 octets of IPv4/UDP/RTP headers to a minimum
   of 2 octets when no UDP checksum is present. If the UDP checksum is
   present, the minimum CRTP header is 4 octets. CRTP cannot use the
   same repair mechanism as CTCP since UDP/RTP does not retransmit.
   Instead, CRTP uses explicit signaling messages from decompressor to
   compressor, called CONTEXT_STATE messages, to indicate that the
   context is out of sync. The link roundtrip time will thus limit the
   speed of this context repair mechanism.





Bormann (ed.)                                                  [Page 11]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   On lossy links with long roundtrip times, such as most cellular
   links, CRTP does not perform well. Each lost packet over the link
   causes several subsequent packets to be lost since the context is out
   of sync during at least one link roundtrip time. This behavior is
   documented in [CRTPC]. For voice conversations such long loss events
   will degrade the voice quality. Moreover, bandwidth is wasted by the
   large headers sent by CRTP when updating the context. [CRTPC] found
   that CRTP performed much worse than ideally for a lossy cellular
   link. It is clear that CRTP alone is not a viable header compression
   scheme for cellular links.

   To avoid losing packets due to the context being out of sync, CRTP
   decompressors can attempt to repair the context locally by using a
   mechanism known as TWICE. Each CRTP packet contains a counter which
   is incremented by one for each packet sent out by the CRTP
   compressor. If the counter increases by more than one, at least one
   packet was lost over the link. The decompressor then attempts to
   repair the context by guessing how the lost packet(s) would have
   updated it. The guess is then verified by decompressing the packet
   and checking the UDP checksum - if it succeeds, the repair is deemed
   successful and the packet can be forwarded or delivered. TWICE has
   got its name from the observation that when the compressed packet
   stream is regular, the correct guess is to apply the update in the
   current packet twice. [CRTPC] found that even with TWICE, CRTP
   doubled the number of lost packets. TWICE improves CRTP performance
   significantly. However, there are several problems with using TWICE:

   1) It becomes mandatory to use the UDP checksum:

      - the minimal compressed header size increases by 100% to 4
        octets.

      - most speech codecs developed for cellular links tolerate errors
        in the encoded data. Such codecs will not want to enable the UDP
        checksum, since they want damaged packets to be delivered.

      - errors in the payload will make the UDP checksum fail when the
        guess is correct (and might make it succeed when it is wrong).

   2) Loss in an RTP stream that occurs before the compression point
      will make updates in CRTP headers less regular. Simple-minded
      versions of TWICE will then perform badly. More sophisticated
      versions would need more repair attempts to succeed.


3.3.  Requirements on a new header compression scheme

   The major problem with CRTP is that it is not sufficiently robust
   against packets being damaged between compressor and decompressor. A
   viable header compression scheme must be less fragile. This increased
   robustness must be obtained without increasing the compressed header



Bormann (ed.)                                                  [Page 12]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   size; a larger header would make IP telephony over cellular links
   economically unattractive.

   A major cause of the bad performance of CRTP over cellular links is
   the long link roundtrip time, during which many packets are lost when
   the context is out of sync. This problem can be attacked directly by
   finding ways to reduce the link roundtrip time. Future generations of
   cellular technologies may indeed achieve lower link roundtrip times.
   However, these will probably always be rather high [CELL]. The
   benefits in terms of lower loss and smaller bandwidth demands if the
   context can be repaired locally will be present even if the link
   roundtrip time is decreased. A reliable way to detect a successful
   context repair is then needed.

   One might argue that a better way to solve the problem is to improve
   the cellular link so that packet loss is less likely to occur. It
   would of course be nice if the links were almost error free, but such
   a system would not be able to support a sufficiently large number of
   users per cell and would thus be economically infeasible [CELL].

   One might also argue that the speech codecs should be able to deal
   with the kind of packet loss induced by CRTP, in particular since the
   speech codecs probably must be able to deal with packet loss anyway
   if the RTP stream crosses the Internet. While the latter is true, the
   kind of loss induced by CRTP is difficult to deal with. It is usually
   not possible to hide a loss event where well over 100 ms worth of
   sound is completely lost. If such loss occurs frequently at both ends
   of the path, the speech quality will suffer.

   A detailed description of the requirements specified for ROHC may be
   found in [REQ].


3.4.  Classification of header fields

   As mentioned earlier, header compression is possible due to the fact
   that there is much redundancy between header field values within
   packets, but especially between consecutive packets. To utilize these
   properties for header compression, it is important to understand the
   behavior of the various header fields. To do this, all header fields
   have been classified in detail in appendix A. The fields are first
   classified on a high level and then some of them are studied more in
   detail. Finally, the appendix concludes with recommendations about
   how the various fields should be handled by header compression
   algorithms. The main conclusion that can be drawn is that most of the
   header fields can easily be compressed away since they are never or
   seldom changing. Only 5 fields with a total size of about 10 octets
   are rather difficult to compress and must be handled in a
   sophisticated way by the compression scheme. Those fields are:

    - IPv4 Identification (16 bits)



Bormann (ed.)                                                  [Page 13]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


    - UDP Checksum (16 bits)
    - RTP Marker (1 bit)
    - RTP Sequence Number (16 bits)
    - RTP Timestamp (32 bits)

   It is rather obvious that these fields then will have a large impact
   on how a header compression scheme is designed.  More detail about
   this should be found in Appendix A.














































Bormann (ed.)                                                  [Page 14]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



4.  Header compression framework


4.1.  Operating assumptions

   TBW


4.2.  Dynamicity

   TBW


4.3.  Compression and decompression states

   TBW: Compression and decompression states, how they interact with
   each other. They must not be correlated. High level description
   without transitions described.

      The compressor starts in the lowest compression state and
   gradually transitions to higher compression states.  The general
   principle is the compressor will always operate in the highest
   possible compression state, under the constraint that the compressor
   has sufficient confidence that the decompressor has the information
   necessary to decompress a header compressed according to that state.
   In the reliable mode, that confidence comes from receipt of ACKs from
   the decompressor.  Otherwise, that confidence comes from sending the
   information a certain number of times, and, if a back channel is
   available, from not receiving NAKs (negative acknowledgements).

      The compressor may also transition back to a lower compression
   state when necessary.

      For IP/UDP/RTP compression, the three compressor states are the
   Initialization/Refresh, First Order, and Second Order.  A brief
   description of each is given in the subsections below.


4.3.1.  Initialization/Refresh (IR) State

      In this state, the compressor essentially sends IR headers. The
   information sent in a refresh may be static and non-static fields in
   uncompressed form (full refresh), or just non-static fields in
   uncompressed form (non-static refresh or dynamic refresh). The
   compressor enters this state at initialization, upon request from
   decompressor, or upon Refresh Time-out. The compressor leaves the IR
   state when it is confident that the decompressor has correctly
   received the refresh information.





Bormann (ed.)                                                  [Page 15]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


4.3.2.  First Order (FO) State

      Subsequently to the IR state, the compressor operates in the FO
   state when the header stream does not conform to a uniform pattern,
   or when the compressor is not confident that the decompressor has
   acquired the parameters of the uniform pattern. In this state, the
   compressor essentially sends FO headers.  In the case of speech with
   silence suppression turned on, a new talk spurt following a silence
   interval will result in the RTP TS incrementing by more than the
   regular TS increment.  Consequently, the header stream does not
   conform to the uniform pattern, and the compressor is in the FO
   state. The compressor will leave this state and transition to the SO
   state when the current header conforms to a string, and the
   compressor is confident the decompressor has acquired the parameters
   of the uniform pattern.


4.3.3.  Second Order (SO) State

      The compressor enters this state when the header to be compressed
   belongs to a uniform pattern, and the compressor is sufficiently
   confident that the decompressor has also acquired the parameters of
   the uniform pattern. In the SO state, the compressor sends SO
   headers, which mainly consist of a sequence number.  While in the SO
   state, the decompressor does a simple extrapolation based on
   information it knows about the pattern of change of the header fields
   and the sequence number contained in the SO header in order to
   regenerate the uncompressed header. The compressor leaves this state
   to go back to FO state when the header no longer conforms to the
   uniform pattern.



4.4.  Different modes of operation.

   TBW: The difference between states and modes.

   TBW: - Unidirectional mode
        - Bi-directional optimistic mode

4.4.3.  Bi-directional reliable mode

   (Essentially Unedited Text from ACE.  This is probably too long for
   chapter 4.)

      An ACK packet contains a sequence number that uniquely identifies
   the compressed header packet that is being ACKed.  ACKnowledgements
   have four main functions:






Bormann (ed.)                                                  [Page 16]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      - To inform the compressor that Refresh information has been
   received.  In that case, the compressor knows that the decompressor
   has acquired the information necessary to decompress FO headers.
   This means the compressor can reliably transition to the next higher
   compression state, the FO state.  This kind of ACK is referred to as
   an IR-ACK.


      - To inform the compressor that FO information has been received;
   in that case, the compressor knows that the decompressor has acquired
   the information necessary to decompress SO headers.  This means the
   compressor can reliably transition to the next higher compression
   state, SO state; this kind of ACK is referred to as an FO-ACK.


      - To inform the compressor that a header with a specific sequence
   number n has been received; in that case, the compressor knows that
   the decompressor can determine the sequence number without any
   ambiguity (caused, e.g., by counter wrap-around) up to header number
   n + seq_cycle, where seq_cycle is the counter cycle (determined by
   the number of bits, k, in the sequence number).  This kind of ACK is
   referred to as an SO-ACK.


      - When information is sent as in-band signaling, to confirm that
   the in-band signaling information has been received

      The control of transition from IR to FO to SO states by ACKs
   ensures that there is no context desynchronization, and therefore no
   error propagation.  That is, a compressed header that is not received
   in error can always be correctly decompressed, because
   synchronization is never lost.

      Reception of ACKs by the compressor can also be used to increase
   compressor header field encoding efficiency.  Compression is more
   efficient because the compressor just has to send the necessary
   information (but no more) to ensure correct decompression of the
   current header.  In general, the minimal information that the
   compressor needs to send depends on what information the decompressor
   already knows.  The information known at the decompressor is
   indicated to the compressor in the decompressor's ACK transmission.


      An enhancement to the acknowledgement procedure can be used to
   reduce FO ACK traffic on the feedback channel; this traffic can be
   quite high if there is significant round trip delay between
   compressor and decompressor.  In this case, several FO headers would
   be sent before the compressor can receive an ACK, and normally, one
   ACK would be sent by the decompressor for each FO header received.





Bormann (ed.)                                                  [Page 17]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      The basic idea is that whenever the decompressor receives a packet
   and needs to send an ACK to the compressor, it just sends the ACK
   once (or twice if there is no default 'pattern' agreed on by the
   compressor and decompressor) and waits for some round trip time (as
   opposed to sending ACKs in response to each, e.g., FO packet on the
   feedback channel).  After the round trip time, if the decompressor
   can confirm that the compressor received the ACK (evidenced by
   receipt of an SO packet at the decompressor), it continues normal
   decompression.  Otherwise, it will send the ACK again and the process
   repeats.

      The only potential negative to this approach is if the ACK sent by
   the decompressor is lost.  In that case, progression to the next
   higher compression state by the compressor is delayed until the next
   ACK is correctly received (at least one round trip time).


      The decompressor uses as reference for decompression only those
   headers which it is sufficiently confident of the correct
   decompression (secure reference). A secure reference must be chosen
   from the headers received with an OK CS. Until a new secure reference
   is chosen, all subsequent headers are decompressed with respect to
   the current secure reference. A major advantage of this approach is
   that an undetected error which affects correct decompression of
   header m will not affect decompression of subsequent headers. For
   example, if header # 3 is an FO used as a secure reference, and
   header # 5 is an SO with an undetected error, the decompression of
   header # 6 will be based solely on header # 3 and not affected by
   header # 5.  In other words, an undetected error will affect only the
   current header, just like when headers are not compressed.



4.5.  Encoding methods

   The analysis of header field changes in appendix A excluded changes
   due to loss and/or reordering before the header compression point.
   Such changes will have an impact on the regularity of the RTP
   sequence number, the RTP timestamp value and, for IPv4, the IP ID
   value. However, as described in A.2, both the RTP timestamp and the
   IP ID value (if sequentially assigned) are expected to follow the RTP
   sequence number for most packets. The most important task is then to
   communicate RTP sequence number information in an efficient way. This
   chapter describes the encoding methods used in a general way. How the
   methods are applied to fields in different compressed headers is
   described in the packet format chapter.


4.5.1.  Least Significant Bits (LSB) encoding





Bormann (ed.)                                                  [Page 18]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   A commonly used method for updating fields whose values are always
   subject to small changes (usually positive) is Least Significant Bits
   (LSB) encoding. For example, an increase of up to 16 could be handled
   with only 4 bits with LSB encoding (if decreases are not expected).
   This method is used for many different fields in the ROHC packet
   headers defined in this document. If a field is labeled "<fieldname>
   LSB", it means that the field contains only the least significant
   bits of the corresponding original field.


4.5.2.  Least Significant Part (LSP) encoding

   One restriction with LSB encoding is that whole bits are needed,
   meaning that only 2, 4, 8, 16, 32, ... code-points could be used. In
   some cases, especially when several mechanisms are integrated for
   efficiency reasons, it would be desirable to have a method that could
   make use of any number of available code-points. To signal one
   special event one could either use one single bit or, if the event is
   not to be signaled in parallel with other information, as one bit
   pattern for several bits. That would leave more bit patterns for
   other usage.

   Assume that we have 4 special events to signal and 5 bits available.
   Taking 2 bits for these events, then there would be 3 bits (8 code-
   points) left for other usage. If we instead reserved 4 of the code-
   points represented by all 5 bits, there would instead be 32-4=28
   code-points left for other usage. The only disadvantage would be that
   the bits cannot be used for both purposes at the same time.

   What would be desirable is to do LSB encoding of code-points instead
   of whole bits. Therefore the method called Least Significant Part
   (LSP) encoding has been introduced. LSP encoding of size (number of
   code-points) M for a value N is defined as:

     LSP:M(N) = N modulo M

   An example showing the LSP encoding and decoding of a counter S(n)
   with M code-points is used below to illustrate the LSP principle.
   S'(n) is the decoded value corresponding to the original S(n) value.
   With S'(n-1), we denote the last correctly decompressed value.

     Input sequence: S(n)
     Encoded sequence: LSP:M(S(n)) = S(n) modulo M
     Decoded sequence: S'(n) = S'(n-1) - LSP:M(S'(n-1)) + LSP:M(S(n)) =
                               S'(n-1) - S(n-1) modulo M + S(n) modulo M

   To handle modulo wrap-around, an additional verification is inserted.
   If the decoded value S'(n) is smaller than S'(n-1)-R, S'(n) is
   increased with M (reordering of order R is then handled with this
   encoding).




Bormann (ed.)                                                  [Page 19]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   When applying LSP encoding, there are thus two parameters that must
   be set:

      M - The number of code-points to use (modulo value)
      R - The reordering order to handle

   A similar mechanism as for modulo wrap-around should also be used to
   handle full-field wrap-around.


4.5.3.  LSB or LSP encoding with extended range

   If needed, it could be good to extend the range covered by the LSB or
   LSP encoding. For the LSB case, it is simple to send only the next
   more significant bits. For the LSP, what must be done is to rewrite
   the definition of LSP so that it defines an additional parameter.

   The LSP definition from previous chapter can instead be expressed as:

     LSP:M(N) = N - INT:M(N)*M      [ INT:M(N) = (N - LSP:M(N)) / M) ]

   And in that case, INT:M(N) is the integer part left after division.
   If additional bits can be transmitted to increase the range covered,
   this can be done by sending the least significant bits (LSB) of this
   integer part, INT:M(N). The example from previous chapter will then
   change into:

     Input sequence: S(n)
     Encoded sequence: LSP:M(S(n)) = S(n) modulo M
                       INT:M(S(n)) = (S(n)-LSP:M(S(n))) / M
     Decoded sequence: S'(n) = S'(n-1) - LSP:M(S'(n-1)) * M
                                       + LSP:M(S(n)) * M
                                       - LSB(INT:M(S'(n-1))) * M
                                       + LSB(INT:M(S(n))) * M

4.5.4.  VLE - Variable Length Encoding

   (Editor: This needs to be renamed to _window-based LSB encoding_ or
   maybe some better term.)

      An alternative approach to encoding irregular changes in header
   fields is to send the 'k' least significant bits of the original
   header field value.

      Clearly, it is desirable for the compressor to minimize this
   number of bits.  Due to the possible loss of packets on the channel
   between compressor and decompressor (CD-CC), the compressor does not
   know which packet will be used as the reference by the decompressor,
   and hence, does not know how many LSBs need to be sent.





Bormann (ed.)                                                  [Page 20]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      Variable Length Encoding (VLE) solves this problem.  The basic
   algorithm employs a 'sliding window', maintained by the compressor,
   which is advanced when the compressor has sufficient confidence that
   the compressor has certain information.  The confidence may be
   obtained by various means, e.g., an ACK from the decompressor if
   operating in RPP.  In the case of NRP a sliding window of fixed size,
   e.g. M (described later) may be used.  In either case, the value of k
   determined depends on the current values in the sliding window.
   Details of the operation follow below.

4.5.4.1.  VLE Basics

      Basic concepts of VLE are:

      * The decompressor uses one of the decompressed header values as a
   reference value, v_ref.  The reference may be chosen by various
   means- one approach might be to select only headers whose correct
   reconstruction is verified by inclusion of a checksum with the
   compressed header ("secure" reference).

      * The compressor maintains a sliding window of the values (VSW)
   which may be chosen as a reference by the decompressor.  It also
   maintains the maximum value (v_max) and the minimum value (v_min) of
   VSW.

      * When the compressor has to compress a value v, it calculates the
   range r = max(|v - v_max|, |v - v_min|).  The value of k needed is k
   = ceiling(log2(2 * r + 1)), i.e., the compressor sends the
   ceiling(log2(2 * r +1)) LSBs of v as the encoded value.

      * The compressor adds v into the VSW and updates the v_min and
   v_max IF the value v could potentially be used as a reference by the
   decompressor.

      * The decompressor chooses as the decompressed value the one that
   is closest to v_ref and whose k LSB equals the compressed value that
   has been received.

      It is obvious that we need to move forward (or shrink) the sliding
   window to prevent k from increasing too much.  To do that, the
   compressor only needs to know which values in VSW have been received
   by the decompressor.  In the case of RPP, that information is carried
   in the ACKs.  In the case of NRP, the VSW is moved without ACK, if
   there are a maximum number of entries, 'M', already present in VSW.
   M is defined in the compressor logic section and further elaborated
   upon in the "Implementation Hints" appendix.

      The VLE concept can be applied to RTP Timestamp, RTP Sequence
   Number, IP-ID header fields, etc.





Bormann (ed.)                                                  [Page 21]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


4.5.4.2.  One-Sided Variable Length Coding (OVLE)

      The VLE encoding scheme is very general and flexible, as it can
   accommodate arbitrary changes (positive, negative) from one value to
   the next.  When VLE is applied to a field that is monotonic (e.g.
   RTP SN), there is a loss in efficiency, because k, the number of bits
   is defined by the condition

      (2p+1) < 2 to the kth(p=|current value-reference value|).

      On the other hand, if the variation is known to be monotonic, the
   required k is smaller, as it has to satisfy only

           p < 2 to the kth.

      One-Sided Variable Length Encoding (OVLE) is based on the idea to
   use a k that satisfies the latter condition, when the field to be
   compressed is monotonic (increasing or decreasing).  When the field
   is almost always monotonic (quasi-monotonic), OVLE compression can be
   used when the field is behaving monotonically, and 'regular' VLE used
   when it is not.

      The savings over VLE is 1 bit, and since that saving is achieved
   most of the time, it translates into a 1 bit savings in the average
   overhead.  Alternatively, the number of bits can be kept the same,
   but the frequency of ACKs can be reduced by a factor of 2.



4.5.5.  Timer-Based Compression of RTP Timestamp

   (Editor: This needs to be aligned with 5.8.3!)

      A useful observation is that the RTP timestamps when generated at
   the source closely follow a linear pattern as a function of the time
   of day clock, particularly for the case when speech is being carried
   in the RTP payload.

      For example, if the time interval between consecutive speech
   samples is 20 msec, then the RTP time stamp of header n (generated at
   time n*20 msec) = RTP time stamp of header 0 (generated at time 0) +
   TS_stride * n, where TS_stride is a constant dependent on the voice
   codec.  In what follows, n is referred to as the 'packed' RTP TS.

      Consequently, the RTP TS in headers coming into the decompressor
   also follow a linear pattern as a function of time, but less closely,
   due to the delay jitter between the source and the decompressor. In
   normal operation (no crashes or failures), the delay jitter is
   bounded, to meet the requirements of conversational real-time
   traffic.  Thus, it is possible for the decompressor to obtain an
   approximation of the packed RTP TS of the current header (the one to



Bormann (ed.)                                                  [Page 22]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   be decompressed), by adding the time elapsed since a reference header
   to the packed RTP TS of that reference header. The decompressor then
   refines this approximation with the additional information received
   in the compressed header. The compressed header carries the k least
   significant bits of the packed RTP TS.  The required value of k to
   ensure correct decompression is a function of the jitter between the
   source and decompressor. The compressor can estimate the jitter and
   determine k, or alternatively it can have a fixed k,
      and filter out the packets with excessive jitter.  Once the
   decompressor has the packed RTP TS, it can convert to the original
   RTP TS.

      The advantages to this approach are many:


      * The size of the compressed RTP TS is constant and small. In
   particular, it does NOT depend on the length of the silence interval.
   This is in contrast to other RTP TS compression techniques, which
   require a variable number of bits dependent on the duration of the
   preceding silence interval. It is very important to be able to
   efficiently compress the RTP TS, as it is one of the essential
   changing fields (see Appendix A).

      * No synchronization is required between the timer process and the
   decompressor process.

      * Robustness to errors: the partial RTP TS information in the
   compressed header is self contained and only needs to be combined
   with the decompressor timer to yield the full RTP TS value.  Loss or
   corruption of a header will not invalidate subsequent compressed
   headers.


      As an example, consider the scenario in which a long silence
   interval has just ended, and the header compressor scheme is
   preparing to send an FO header to decompressor to adjust for the
   unexpected change in RTP timestamp.  The compressor knows that the
   packet which has just arrived is the first packet of a new talkspurt
   as opposed to following a lost packet because the RTP SN increments
   by only one.  Note that we need not assume any special behavior of
   the input to the compressor (i.e. the scheme tolerates reordering, or
   more generally, non-increasing RTP timestamp behavior observed prior
   to the compressor).

      At the end of the silence interval, the compressor sends in the FO
   compressed header the k least significant bits of

      p_TS_current = (current RTP time stamp - TS0)/TS_stride.

      p_TS_current is the "packed" representation of the current time;
   it has granularity of TS stride, which is the RTP timestamp increment



Bormann (ed.)                                                  [Page 23]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   observed during e.g. a VoIP session (e.g. 160 for a 20 mS voice
   codec).

      TS0 is an arbitrary timestamp offset.

      The compressor runs the following algorithm to determine k.

      STEP 1:  calculate Network_Jitter (Current_header, j) as

           | (T_current - T_j) - (p_TS_current - p_TS_j) |

      for all packets in a sliding window, TSW.  TSW contains several
   pairs (T_j, p_TS_j) of values corresponding to the packets sent that
   may be used as a reference, including the last packet which was
   ACKed.  In the case of RPP, TWS is moved when an ACK with some
   indication is received from the decompressor. In the case of NRP
   mode, the TSW is moved without ACK if there are a maximum number of
   entries, 'M', present in TSW.  I.e., the sliding window is managed
   just like for the case of VLE.

      T_current is the current wall clock time at the compressor, and
   T_j is the wall clock time at which the packet j in the sliding
   window was received by the compressor.  Both T_current and T_j are in
   units of time interval (e.g. 20 ms) equivalent to TS_stride.

      p_TS_current and p_TS_j are the packed RTP timestamp times of the
   packets, determined from the actual RTP header.

      STEP 2:  compute Max_Network_Jitter, where

      Max_Network_Jitter = Max{Network_Jitter(current, j)},for all
   headers j in TSW

      Note that Max_Network_Jitter is positive.


      STEP 3:  k is then calculated as

         k = ceiling(log2(2 * J + 1), where

            J = Max_Network_Jitter + Max_CD_CC_Jitter + 2.

      Max_CD_CC_Jitter is the maximum possible CD-CC jitter expected on
   the CD-CC.  Such a maximum depends only on the characteristics of the
   CD- CC, and is expected to be reasonably small in order to have good
   quality for real-time services.

      The factor + 2 is to account for the quantization error caused by
   the timers at the compressor and decompressor, which can be +/- 1.





Bormann (ed.)                                                  [Page 24]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


4.6.  Requirements on lower layers

   This chapter lists general ROHC requirements on an underlying link
   layer. See also the ROHC lower layer requirements document [LLG].

   Framing

     Framing, which makes it possible to separate different packets, is
     the most important link layer functionality.

   Length

     Most link layers can indicate the length of the packet, and this
     information has therefore been removed from the packet headers.
     This means that it now MUST be given by the link layer.

   Error protection

     A reliable link layer CRC covering at least the header part of the
     packet is assumed. The CRC SHOULD ensure that packets with errors
     in the header part are never delivered.

   Negotiation

     In addition to the packet handling mechanisms above, the link
     layer MUST also provide a way to carry on the negotiation of
     header compression parameters.



























Bormann (ed.)                                                  [Page 25]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



5.  The protocol


5.1.  Data structures


5.1.1.  Per-channel parameters


5.1.2.  Per-CID parameters, profiles


5.1.3.  Contexts


5.2.  Packet types

   This chapter defines the various packet types that are used by the
   ROHC scheme. It also lists some parameters that are needed in the
   various packet headers to carry out transition between the three
   modes of operation.


5.2.1.  Packets from compressor to decompressor

   The ROHC scheme defines three different packet types for the
   information sent from compressor to decompressor. The header formats
   for these packet types may vary but their meaning will always be the
   same. The three packet types defined are:

     FH (Full Header)  : In these packets, all information needed to
                         establish the decompressor context is sent.

     FO (First Order)  : Only a limited amount of context information is
                         sent in a FO packet and no STATIC information.
                         However, successful decompression of subsequent
                         packets requires that the information sent in
                         an FO packet is correctly transferred.

     SO (Second Order) : The SO packets are small and (almost)
                         independent packets. Subsequent packets are not
                         depending on the SO packet for successful
                         decompression.

   TBW: How these packet types are used, their relation to the three
   compression states with the same names etc...


5.2.2.  Feedback packets from decompressor to compressor




Bormann (ed.)                                                  [Page 26]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   In addition to the packet types used from compressor to decompressor,
   feedback packets are also defined to use from decompressor to
   compressor. The feedback packet formats may vary and there may also
   be special feedback packet types defined. However, these three
   feedback packet types must always be supported to control state and
   mode transition:

     ACK         : Acknowledge a successful decompression of a packet,
                   which means that the context is up to date.

     NACK        : Indicates that decompression has failed.

     STATIC-NACK : Indicates that decompression has failed due to an
                   invalid (or never established) STATIC context.

   TBW: How these packet types are used etc...


5.2.3.  Parameters needed for mode transition

   TBW:

   All feedback packets of the types defined above must carry the
   sequence number of the packet that it corresponds to and a parameter
   telling the desired compression mode to work in (U=Unidirectional,
   O=Optimistic, R=Reliable).


5.3.  Operation in unidirectional mode

   TBW: General description of the unidirectional mode


5.3.1.  Compression states and logic

   Below is the state machine for the compressor in unidirectional mode.
   Details of each state, the transitions between states and compression
   logic is given subsequent to the figure.


              Optimistic approach         Optimistic approach
             +------>------>------+      +------>------>------+
             |                    |      |                    |
             |                    v      |                    v
    +----------+                +----------+                +----------+
    | FH State |                | FO State |                | SO State |
    +----------+                +----------+                +----------+
      ^      ^                    |      ^                    |      |
      |      |      Timeout       |      |  Timeout / Update  |      |
      |      +------<------<------+      +------<------<------+      |
      |                                                              |



Bormann (ed.)                                                  [Page 27]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      |                           Timeout                            |
      +------<------<------<------<------<------<------<------<------+


   TBW: Descriptions of timers, optimistic approach, transitions and the
   packets used. Text from ROCCO draft may be reused.



5.3.2.  Decompression states and logic

                                      FH
                 +-->------>------>------>------>------>--+
                 |                                        |
       FO,SO     |                 SO            FH,FO    |   FH,FO,SO
      +-->--+    |             +-->--+      +--->----->---+    +-->--+
      |     |    |             |     |      |             |    |     |
      |     v    |             |     v      |             v    |     v
    +--------------+         +----------------+         +--------------+
    |  No Context  |         | Static Context |         | Full Context |
    +--------------+         +----------------+         +--------------+
       ^                         |        ^                         |
       |  Invalid decompression  |        |  Invalid decompression  |
       +-----<------<------<-----+        +-----<------<------<-----+


   TBW: CRC failure, repeated reconstruction's, decompressor sliding
   window, timer-based decompression, transition logic

   No feedback messages are sent to the compressor when working in
   unidirectional mode.


5.4.  Operation in bi-directional optimistic mode

   TBW: Description of this mode


5.4.1.  Compression states and logic

   Below is the state machine for the compressor in bi-directional
   optimistic mode. Details of each state, the transitions between
   states and compression logic is given subsequent to the figure.

                         Optimistic approach / ACK
      +------>------>------>------>------>------>------>------>------+
      |                                                              |
      |      Optimistic appr. / ACK      Optimistic appr. / ACK      |
      |      +------>------>------+      +------>------>------+      |
      |      |                    |      |                    |      |
      |      |                    v      |                    v      v



Bormann (ed.)                                                  [Page 28]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


    +----------+                +----------+                +----------+
    | FH State |                | FO State |                | SO State |
    +----------+                +----------+                +----------+
      ^      ^                    |      ^                    |      |
      |      |    STATIC-NACK     |      |    NACK / Update   |      |
      |      +------<------<------+      +------<------<------+      |
      |                                                              |
      |                         STATIC-NACK                          |
      +------<------<------<------<------<------<------<------<------+


   TBW: Descriptions of optimistic approach, transitions and the packets
   used.


5.4.2.  Decompression states and logic

   The decompression states and the state transition logic are the same
   as for the unidirectional case (see section 5.3.2). What differs is
   the feedback logic, which states what feedback messages to send due
   to different events when operating in the various states.

   In NC state: - When a FH packet is correctly decompressed, send an
                  ACK with the mode parameter set to O
                - When an FO or SO packet is received or decompression
                  of a FH packet has failed, send a STATIC-NACK with
                  the mode parameter set to O

   In SC state: - When a FH packet is correctly decompressed, send an
                  ACK with the mode parameter set to O
                - When an FO packet is correctly decompressed,
                  optionally send an ACK with the mode parameter set to
                  O
                - When a SO packet is received, send a NACK with the
                  mode parameter set to O
                - When decompression of an FO or FH packet has failed,
                  send a STATIC-NACK with the mode parameter set to O

   In FC state: - When a FH packet is correctly decompressed, send an
                  ACK with the mode parameter set to O
                - When an FO packet is correctly decompressed,
                  optionally send an ACK with the mode parameter set to
                  O
                - When an SO packet is correctly decompressed, no
                  feedback should be sent
                - When decompression of an SO, FO or FH packet has
                  failed, send a NACK with the mode parameter set to O







Bormann (ed.)                                                  [Page 29]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


5.5.  Operation in bi-directional reliable mode

5.5.1.  Compression states and logic

   Below is the state machine for the compressor in bi-directional
   reliable mode. Details of each state, the transitions between states
   and compression logic is given subsequent to the figure.

                                    ACK
      +------>------>------>------>------>------>------>------+
      |                                                       |
      |               ACK                         ACK         |   ACK
      |      +------>------>------+      +------>------>------+  +->-+
      |      |                    |      |                    |  |   |
      |      |                    v      |                    v  |   v
    +----------+                +----------+                +----------+
    | FH State |                | FO State |                | SO State |
    +----------+                +----------+                +----------+
      ^      ^                    |      ^                    |      |
      |      |    STATIC-NACK     |      |    NACK / Update   |      |
      |      +------<------<------+      +------<------<------+      |
      |                                                              |
      |                         STATIC-NACK                          |
      +------<------<------<------<------<------<------<------<------+


   TBW: Descriptions of transitions and the packets used.



5.5.2.  Decompression states and logic

   The decompression states and the state transition logic are the same
   as for the unidirectional case (see section 5.3.2). What differs is
   the feedback logic, which states what feedback messages to send due
   to different events when operating in the various states.

   In NC state: - When a FH packet is correctly decompressed, send an
                  ACK with the mode parameter set to R
                - When an FO or SO packet is received or decompression
                  of a FH packet has failed, send a STATIC-NACK with
                  the mode parameter set to R

   In SC state: - When an FO or FH packet is correctly decompressed,
                  send an ACK with the mode parameter set to R
                - When an SO packet is received, send a NACK with the
                  mode parameter set to R
                - When decompression of an FO or FH packet has failed,
                  send a STATIC-NACK with the mode parameter set to R





Bormann (ed.)                                                  [Page 30]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   In FC state: - When an FO or FH packet is correctly decompressed,
                  send an ACK with the mode parameter set to R
                - When an updating SO packet is correctly decompressed,
                  periodically send an ACK with the mode parameter set
                  to R
                - When decompression of an SO, FO or FH packet has
                  failed, send a NACK with the mode parameter set to R


5.6.  Mode transitions

   The decision to move from one compression mode to another is taken by
   the decompressor and the possible mode transitions are shown in the
   figure below. How the transitions are performed is described in the
   subsequent chapters.

                            +---------------------+
                            | Unidirectional mode |
                            +---------------------+
                               ^               |
                               |               |
                               |               v
                            +---------------------+
                            |   Optimistic mode   |
                            +---------------------+
                               ^               |
                               |               |
                               |               v
                            +---------------------+
                            |    Reliable mode    |
                            +---------------------+


5.6.1.  From Unidirectional to Optimistic mode

   As long as there is a feedback channel available, the decompressor
   can at any moment decide to initiate transition from unidirectional
   to bi-directional Optimistic mode. All feedback packets can be used
   with the mode parameter set to O=Optimistic and the decompressor can
   then directly start working in Optimistic mode.

   ACK (O)         : Is sent to transit after a successful
                     decompression. The compressor can, when receiving
                     this packet, move directly to SO state if no
                     update is needed compared to the acknowledged
                     packet.

   NACK (O)        : Is sent to transit after a decompression failure
                     if any preceding packet has been correctly
                     decompressed. The compressor must, when receiving




Bormann (ed.)                                                  [Page 31]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


                     this packet, go to FO state to update the
                     decompressor context.

   STATIC-NACK (O) : Is sent to transit after a decompression failure
                     when decompression has never succeeded. The
                     compressor must, when receiving this packet, start
                     from FH state to establish the static part of the
                     context.


5.6.2.  From Optimistic to Reliable mode

   Transition from Optimistic to Reliable mode is only allowed after at
   least one packet has been correctly decompressed, which means that
   the static part of the context is established. Either the ACK(R) or
   the NACK(R) feedback packet is used to initiate the transition and
   the compressor MUST always run in FO state during transition. The
   transition procedure is described below:


               Comnpressor                     Decompressor
              ----------------------------------------------
                    |                               |
                    |        ACK(R)/NACK(R) +-<-<-<-|  Transition
                    |       +-<-<-<-<-<-<-<-+       |  initiated
                    |-<-<-<-+                       |
    Go to FO state  |                               |
                    |->->->-+   FO(SN0,R)           |
                    |       +->->->->->->->-+       |
                    |->-..                  +->->->-|  Decompressor
                    |->-..                          |  transits to
                    |           ACK(SN0,R)  +-<-<-<-|  Reliable mode
                    |       +-<-<-<-<-<-<-<-+       |
    Transition      |-<-<-<-+                       |
    completed       |                               |
                    |->->->-+ SO (Reliable mode)    |
                    |       +->->->->->->->-+       |
                    |                       +->->->-|
                    |                               |

   As long as the decompressor has not received an FO packet with the
   mode transition parameter set to R, it must stay in Optimistic mode.
   The compressor must stay in FO state until it has received an ACK for
   an FO packet sent with the mode transition parameter set to R
   (indicated by the sequence number).

   Since transition from Unidirectional to Optimistic mode do not
   require any handshakes, it is possible to transit directly from
   Unidirectional to Reliable mode, but only if at least one packet has
   been successfully decompressed indicating a correct static context at
   the decompressor.



Bormann (ed.)                                                  [Page 32]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000





5.6.3.  From Reliable to Optimistic mode

   Either the ACK(O) or the NACK(O) feedback packet is used to initiate
   the transition from Reliable to Optimistic mode and the compressor
   MUST always run in FO state during transition. The transition
   procedure is described below:


               Comnpressor                     Decompressor
              ----------------------------------------------
                    |                               |
                    |        ACK(O)/NACK(O) +-<-<-<-|  Transition
                    |       +-<-<-<-<-<-<-<-+       |  initatied
                    |-<-<-<-+                       |
    Go to FO state  |                               |
                    |->->->-+   FO(SN0,O)           |
                    |       +->->->->->->->-+       |
                    |->-..                  +->->->-|  Decompressor
                    |->-..                          |  transits to
                    |           ACK(SN0,O)  +-<-<-<-|  Optimistic mode
                    |       +-<-<-<-<-<-<-<-+       |
    Transition      |-<-<-<-+                       |
    completed       |                               |
                    |->->->-+ SO (Optimistic mode)  |
                    |       +->->->->->->->-+       |
                    |                       +->->->-|
                    |                               |

   As long as the decompressor has not received an FO packet with the
   mode transition parameter set to O, it must stay in Reliable mode.
   The compressor must stay in FO state until it has received an ACK for
   a FO packet sent with the mode transition parameter set to O
   (indicated by the sequence number).


5.6.4.  From optimistic to unidirectional mode

   TBW: (idea text provided at the moment)

   Initiate at compressor side by sending FO/FH packets with NO_FEEDBACK
   flag set. When ack of that FO/ FH is received with mode-flag set to
   U:
      * for optimistic mode, go to unidirectional.
      * for reliable mode, go to FO state and start transition procedure
        to optimistic mode, but with the FO mode parameter set to U.
        When procedure has completed, go to unidirectional mode.
   In both cases, SO packets in the forward direction indicates to the
   decompressor that the transition has completed.



Bormann (ed.)                                                  [Page 33]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



   Transition could also be initiated by the decompressor by sending U-
   marked feedback. Decompressor could stop sending feedback when it
   receives periodic refreshes from compressor.


5.7.  Packet formats

   Table 5.1 describes which packet formats are used.

   NOTE: These packet formats do not include the parameters needed for
   mode transition, those must be added for the scheme to work.

   The first five columns profile state parameters that affect the
   choice of packet types:

   IPv    This is the IP version for which the profile is designed.
          Possible values for this column are 6 and 4.

   CID    This column gives the number of concurrent packet streams
          that are supported by the header compression profile through
          context identifiers (CIDs).

   Chk    This column indicates whether the profile supports packet
          streams with the UDP checksum (E)nabled or D(isabled).

   ID     For profiles supporting IPv4, this column indicates which
          behavior of the IPv4 Identification field the profile is
          optimized for. Possible values in this column are:

          (S)EQUENTIAL           These profiles can handle all kind of
                                 Identification assignment methods but
                                 will be less efficient than RANDOM
                                 profiles if the assignment truly is
                                 random. If the value is sequentially
                                 assigned, no extra overhead is added
                                 for Identification.

          (R)ANDOM               These profiles are recommended if it is
                                 known that random assignment is used.
                                 The Identification field will be
                                 included "as-is" which means that the
                                 header size will increase by two
                                 octets.

   TbT    Timer-based Timestamp decompression. Requires a timer at the
          decompressor side to estimate timestamp jumps. Compressor
          never sends more than a few bits of timestamp LSB with these
          profiles. Can be (E)nabled or (D)isabled (see chapter 5.5.3).

   S      S gives the minimal header Size for the profile.



Bormann (ed.)                                                  [Page 34]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



   The next five columns indicate how each profile is implemented. This
   includes header formats for STATIC (STA, see chapter 5.7.1), DYNAMIC
   (DYN, see chapter 5.7.2) and COMPRESSED (COM, see chapter 5.7.3)
   packets, and also what EXTENSION (EXT, see chapter 5.7.4) formats are
   used with the COMPRESSED packets. The CRC column tells the coverage
   of the header compression CRC: uncompressed (H)eader or the same
   coverage as for the UDP (C)hecksum (see chapter 5.8.).














































Bormann (ed.)                                                  [Page 35]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000




    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | I |  C  | C | I | T |  | S |  | S | D |    C    | E | C |
    | P |  I  | h | D | b |  |   |  | T | Y |    O    | X | R |
    | v |  D  | k |   | T |  |   |  | A | N |    M    | T | C |
    +===+=====+===+===+===+  +===+  +===+===+=========+===+===+
    | 6 |  1  | E | - | E |  | 2 |  | 1 | 1 |    1    | A | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 6 |  1  | E | - | D |  | 2 |  | 1 | 1 |    1    | A | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 6 | 256 | E | - | E |  | 3 |  | 2 | 2 |    2    | A | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 6 | 256 | E | - | D |  | 3 |  | 2 | 2 |    2    | A | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 |  1  | D | S | E |  | 1 |  | 3 | 3 | 5/17, 9 | D | H |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 |  1  | D | S | D |  | 1 |  | 3 | 3 | 5/17,13 | B | H |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 |  1  | D | R | E |  | 3 |  | 3 | 3 | 7/19,11 | C | H |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 |  1  | D | R | D |  | 3 |  | 3 | 3 | 7/19,15 | A | H |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 |  1  | E | S | E |  | 2 |  | 3 | 5 |    1    | D | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 |  1  | E | S | D |  | 2 |  | 3 | 5 |    1    | B | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 |  1  | E | R | E |  | 4 |  | 3 | 5 |    3    | C | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 |  1  | E | R | D |  | 4 |  | 3 | 5 |    3    | A | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 | 256 | D | S | E |  | 2 |  | 4 | 4 | 6/18,10 | D | H |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 | 256 | D | S | D |  | 2 |  | 4 | 4 | 6/18,14 | B | H |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 | 256 | D | R | E |  | 4 |  | 4 | 4 | 8/20,12 | C | H |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 | 256 | D | R | D |  | 4 |  | 4 | 4 | 8/20,16 | A | H |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 | 256 | E | S | E |  | 3 |  | 4 | 6 |    2    | D | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 | 256 | E | S | D |  | 3 |  | 4 | 6 |    2    | B | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 | 256 | E | R | E |  | 5 |  | 4 | 6 |    4    | C | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+
    | 4 | 256 | E | R | D |  | 5 |  | 4 | 6 |    4    | A | C |
    +---+-----+---+---+---+  +---+  +---+---+---------+---+---+

               Table 5.1 : Packet format table





Bormann (ed.)                                                  [Page 36]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   The packet types defined in chapter 5.2 are implemented with 4
   different packet formats: STATIC, DYNAMIC, COMPRESSED and FEEDBACK.

   To identify the packet format used, 4 bit patterns for the initial 5
   bits of the first octet (not including a potential CID field) in all
   packets are reserved. These patterns are:

     STATIC       11111
     DYNAMIC      1110*    (both 11100 and 11101 are reserved for this)
     FEEDBACK     11110

   The other 28 (32-4) bit patterns indicate a COMPRESSED packet format
   and the usage of these patterns are explained further on.

   This section defines the header formats of the four ordinary packet
   formats STATIC, DYNAMIC, COMPRESSED and FEEDBACK together with
   descriptions of when and how to use them. A subsections is also
   dedicated to the EXTENSION formats of COMPRESSED headers.




































Bormann (ed.)                                                  [Page 37]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


5.7.1.  Static information packets, initialization

   The STATIC packet type is a packet containing no payload but only the
   header fields that are expected to be constant throughout the
   lifetime of the packet stream (classified as STATIC in appendix A). A
   packet of this kind MUST be sent once as the first packet from
   compressor to decompressor and also when requested by the
   decompressor (see chapter 5.4.5). If the D-bit is set, a DYNAMIC
   packet (without CID) is attached to the STATIC packet to create a
   complete context initialization packet. The STATIC packet formats are
   shown below for IPv6 and IPv4, respectively. Note that some fields
   are only present in some of the STATIC packet types.


   IPv6 (45-46 octets): STATIC1, STATIC2:

          0   1   2   3   4   5   6   7
        +...+...+...+...+...+...+...+...+
        :   Context Identifier  (CID)   :   only present in STATIC2
        +---+---+---+---+---+---+---+---+
        | 1   1   1   1   1 | D | - | - |
        +---+---+---+---+---+---+---+---+
        |                               |
        +          Flow Label           +
        |                               |
        +               +---+---+---+---+
        |               | - | - | P | E |
        +---+---+---+---+---+---+---+---+
        |                               |
        /        Source Address         /   16 octets
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        /      Destination Address      /   16 octets
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        +          Source Port          +
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        +       Destination Port        +
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        /             SSRC              /   4 octets
        |                               |
        +---+---+---+---+---+---+---+---+
        |    Header Compression CRC     |   see chapter 5.9.1.
        +---+---+---+---+---+---+---+---+




Bormann (ed.)                                                  [Page 38]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000




   IPv4 (18-19 octets): STATIC3, STATIC4:

          0   1   2   3   4   5   6   7
        +...+...+...+...+...+...+...+...+
        :   Context Identifier  (CID)   :   only present in STATIC4
        +---+---+---+---+---+---+---+---+
        | 1   1   1   1   1 | F | P | E |
        +---+---+---+---+---+---+---+---+
        |                               |
        /        Source Address         /   4 octets
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        /      Destination Address      /   4 octets
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        +          Source Port          +
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        +       Destination Port        +
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        /             SSRC              /   4 octets
        |                               |
        +---+---+---+---+---+---+---+---+
        |    Header Compression CRC     |   see chapter 5.9.1.
        +---+---+---+---+---+---+---+---+


   All fields except for the initial five bits, the padding (-) and the
   Header Compression CRC are the ordinary IP, UDP and RTP fields
   (F=IPv4 May Fragment, P=RTP Padding, E=RTP Extension).

   The number of STATIC packets sent on each occasion should be limited.
   If the decompressor receives DYNAMIC or COMPRESSED headers without
   having received a STATIC packet, the decompressor MUST send a
   STATIC_FAILURE_FEEDBACK packet.


5.7.2. Dynamic information packets

   The DYNAMIC packet type has a header containing all changing header
   fields in their original, uncompressed form, and carries a payload
   just like ordinary COMPRESSED packets. This packet type is used after
   the initial STATIC packet to set up the decompressor context for the
   first time, and also whenever the header field information cannot be



Bormann (ed.)                                                  [Page 39]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   encoded in EXTENDED_COMPRESSED packets. DYNAMIC packets could be used
   due to significant field changes or upon INVALID_CONTEXT_FEEBACK.
   All fields except for the initial four bits, the Timestamp Delta, and
   the Header Compression CRC are ordinary IP, UDP and RTP fields. The
   Timestamp Delta is the current delta between RTP timestamps in
   consecutive RTP packets. Initially this value SHOULD be set to 160.

   The packet formats are shown below for IPv6 and IPv4, respectively.
   Note that some fields are only present in some of the DYNAMIC packet
   types.


   IPv6 (13-16 octets + CSRC List of 0-60 octets): DYNAMIC1, DYNAMIC2:


          0   1   2   3   4   5   6   7
        +...+...+...+...+...+...+...+...+
        :   Context Identifier  (CID)   :  only in DYNAMIC2
        +---+---+---+---+---+---+---+---+
        | 1   1   1   0 |  CSRC Counter |
        +---+---+---+---+---+---+---+---+
        |         Traffic Class         |
        +---+---+---+---+---+---+---+---+
        |           Hop Limit           |
        +---+---+---+---+---+---+---+---+
        |                               |
        +         UDP Checksum          +
        |                               |
        +---+---+---+---+---+---+---+---+
        | M |       Payload Type        |
        +---+---+---+---+---+---+---+---+
        |                               |
        +        Sequence Number        +
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        /           Timestamp           /  4 octets
        |                               |
        +---+---+---+---+---+---+---+---+
        :                               :
        :           CSRC List           :  0-15 x 4 octets
        :                               :
        +---+---+---+---+---+---+---+---+
        |                               |
        +        Timestamp Delta        +
        |                               |
        +---+---+---+---+---+---+---+---+
        |    Header Compression CRC     |  see chapter 5.9.2.
        +---+---+---+---+---+---+---+---+
        /            Payload            /
        +---+---+---+---+---+---+---+---+



Bormann (ed.)                                                  [Page 40]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   IPv4 (15-18 octets + CSRC List of 0-60 octets): DYNAMIC3, DYNAMIC4,
                                                   DYNAMIC5, DYNAMIC6:

          0   1   2   3   4   5   6   7
        +...+...+...+...+...+...+...+...+
        :   Context Identifier  (CID)   :  only in DYNAMIC4 and DYNAMIC6
        +---+---+---+---+---+---+---+---+
        | 1   1   1   0 |  CSRC Counter |
        +---+---+---+---+---+---+---+---+
        |        Type Of Service        |
        +---+---+---+---+---+---+---+---+
        |                               |
        +        Identification         +
        |                               |
        +---+---+---+---+---+---+---+---+
        |         Time To Live          |
        +---+---+---+---+---+---+---+---+
        :                               :
        +         UDP Checksum          +  only in DYNAMIC5 and DYNAMIC6
        :                               :
        +---+---+---+---+---+---+---+---+
        | M |       Payload Type        |
        +---+---+---+---+---+---+---+---+
        |                               |
        +        Sequence Number        +
        |                               |
        +---+---+---+---+---+---+---+---+
        |                               |
        /           Timestamp           /  4 octets
        |                               |
        +---+---+---+---+---+---+---+---+
        :                               :
        :           CSRC List           :  0-15 x 4 octets
        :                               :
        +---+---+---+---+---+---+---+---+
        |                               |
        +            TS Delta           +
        |                               |
        +---+---+---+---+---+---+---+---+
        |    Header Compression CRC     |  see chapter 5.9.2.
        +---+---+---+---+---+---+---+---+
        /            Payload            /
        +---+---+---+---+---+---+---+---+


   Each time a DYNAMIC packet is sent, several subsequent packets SHOULD
   also be DYNAMIC packets to ensure a successful update even when
   packets are lost. Context updates both with DYNAMIC and COMPRESSED
   packets could also be acknowledged with CONTEXT_UPDATED_FEEDBACK.





Bormann (ed.)                                                  [Page 41]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


5.7.3.  Compressed packets

   The COMPRESSED packet type is the most commonly used packet and is
   designed to handle ordinary changes as efficiently as possible.

   When changes are regular, all information is carried in the base
   header. When desired, it is possible to send additional information
   in extensions to the COMPRESSED base-header.

   The COMPRESSED base-header formats are shown below. Note that some
   fields are only present in some of the COMPRESSED packet types.

   Defines packet types: COMPRESSED1..COMPRESSED4:

        0   1   2   3   4   5   6   7
      +...+...+...+...+...+...+...+...+
      :   Context Identifier  (CID)   : only in COMPRESSED type 2 and 4
      +---+---+---+---+---+---+---+---+
      |   Sequence LSP#   |           |    # see chapter 5.8.2
      +---+---+---+---+---+       +---+
      |   Header Compression CRC* | X |    * see chapter 5.9.3
      +---+---+---+---+---+---+---+---+
      :                               :
      +        Identification         + only in COMPRESSED type 3 and 4
      :                               :
      +...+...+...+...+...+...+...+...+
      :                               :
      /           Extension           / only present if X=1
      :                               :
      +---+---+---+---+---+---+---+---+
      /            Payload            /
      +---+---+---+---+---+---+---+---+



   Defines packet types: COMPRESSED5..COMPRESSED8:

        0   1   2   3   4   5   6   7
      +...+...+...+...+...+...+...+...+
      :   Context Identifier  (CID)   : only in COMPRESSED 6 and 8
      +---+---+---+---+---+---+---+---+
      | 0 | Sequence LSB# |    CRC*   |    # see chapter 5.8.1
      +---+---+---+---+---+---+---+---+    * see chapter 5.9.3
      :                               :
      +        Identification         + only in COMPRESSED 7 and 8
      :                               :
      +---+---+---+---+---+---+---+---+
      /            Payload            /
      +---+---+---+---+---+---+---+---+





Bormann (ed.)                                                  [Page 42]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000




   Defines packet types: COMPRESSED9..COMPRESSED12:

        0   1   2   3   4   5   6   7
      +...+...+...+...+...+...+...+...+
      :   Context Identifier  (CID)   : only in COMPRESSED 10 and 12
      +---+---+---+---+---+---+---+---+
      | 1   0 |          CRC*         |    * see chapter 5.9.3
      +---+---+---+---+---+---+---+---+
      | Sequence LSB# |  STS LSB# | X |    # see chapter 5.8.1
      +---+---+---+---+---+---+---+---+
      :                               :
      +        Identification         + only in COMPRESSED 11 and 12
      :                               :
      +...+...+...+...+...+...+...+...+
      :                               :
      /           Extension           / only present if X=1
      :                               :
      +---+---+---+---+---+---+---+---+
      /            Payload            /
      +---+---+---+---+---+---+---+---+





   Defines packet types: COMPRESSED13..COMPRESSED16:

        0   1   2   3   4   5   6   7
      +...+...+...+...+...+...+...+...+
      :   Context Identifier  (CID)   : only in COMPRESSED 14 and 16
      +---+---+---+---+---+---+---+---+
      | 1   0 | M |      STS LSB#     |    # see chapter 5.8.1
      +---+---+---+---+---+---+---+---+
      | Sequence LSB# |    CRC*   | X |    * see chapter 5.9.3
      +---+---+---+---+---+---+---+---+
      :                               :
      +        Identification         + only in COMPRESSED 15 and 16
      :                               :
      +...+...+...+...+...+...+...+...+
      :                               :
      /           Extension           / only present if X=1
      :                               :
      +---+---+---+---+---+---+---+---+
      /            Payload            /
      +---+---+---+---+---+---+---+---+







Bormann (ed.)                                                  [Page 43]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   Defines packet types: COMPRESSED17..COMPRESSED20:

        0   1   2   3   4   5   6   7
      +...+...+...+...+...+...+...+...+
      :   Context Identifier  (CID)   : only in COMPRESSED 18 and 20
      +---+---+---+---+---+---+---+---+
      | 0 | C |     Sequence LSB#     |    # see chapter 5.8.1
      +---+---+---+---+---+---+---+---+
      :              CRC*             : only present if C=1
      +...+...+...+...+...+...+...+...+    * see chapter 5.9.3
      :                               :
      +        Identification         + only in COMPRESSED 19 and 20
      :                               :
      +---+---+---+---+---+---+---+---+
      /            Payload            /
      +---+---+---+---+---+---+---+---+


   The coverage of the Header Compression CRC is described in chapter
   5.6.3. In that chapter, the CRC polynomials to use are also defined.

   The interpretations of the Sequence and STS (Scaled TimeStamp) fields
   for different packet formats are given in section 5.8.































Bormann (ed.)                                                  [Page 44]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


5.7.4.  Extensions to compressed headers

   Less regular changes in the header fields or updates of decompressor
   contexts require an extension in addition to the base header. When
   there is an extension present in the COMPRESSED packet, this is
   indicated by the extension bit (X) being set. Extensions are of
   variable size depending on the information needed to be transmitted.
   However, the first three extension bits are used as an extension Type
   field for all extension formats. The extension can carry an M-bit, a
   t-bit, a SEQ EXT LSB field (called SEQ*), a (S)TS (EXT) LSB field
   (called TS*), an ID LSB field and a bit mask for additional fields.
   The M-bit is the RTP marker bit and the (S)TS (EXT) LSB is timestamp
   information sent with the least significant bits (the most
   significant bits are then expected to be unchanged compared to
   context). The timestamp information could either be the LSB of the
   (S)caled (T)ime(S)tamp value (if indicated with the t-bit unset) or
   the LSB of the absolute timestamp value. For profiles with a
   timestamp field in the compressed base header, the timestamp
   information is sent as an extended range to that field. The SEQ EXT
   LSB is extended range for the RTP sequence number. How extended range
   works is described in chapter 5.5.1 and 5.5.2. The t-bit is sent when
   timestamp is not scaled, otherwise it is always scaled with the
   timestamp delta. The ID LSB is the LSB of the IP Identification
   value. Various bit mask patterns are possible and can consist of
   S,H,C,D,T and I. The interpretations of these bits are given at the
   end of this chapter.

   The guiding principle for choosing the extension type is to find the
   smallest header type that can communicate the information needed.

   For the profiles defined in this document, four different extension
   sets are used, called A, B, C and D. Set A and C are for IPv6 and do
   not handle the IPv4 identification field, which set B and D do. Set A
   and B handle timestamp information which set C and D do not. All
   possible extensions are shown below with indications of which sets
   and types the extensions correspond to. For instance, B3 means that
   in extension set B, the extension is used with type value 3
   (indicated in the type field).

   The defined extension types are shown below:

                   0             7
              - - +-+-+-+-+-+-+-+-+
    A0, B0,       |0 0 0|   SEQ*  |
    C0, D0    - - +-+-+-+-+-+-+-+-+


                   0             7
              - - +-+-+-+-+-+-+-+-+
    A1, B1        |0 0 1|M|  TS*  |
              - - +-+-+-+-+-+-+-+-+



Bormann (ed.)                                                  [Page 45]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000




                                                 1
                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    A2            |0 1 0|M|          TS*          |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                                 1 1             2
                   0             7 8             5 6             3
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    A3            |0 1 1|M|t|                 TS*                 |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   0             7
              - - +-+-+-+-+-+-+-+-+ - -
    A4            |1 0 0|M|H|D|T|t|
              - - +-+-+-+-+-+-+-+-+ - -

                                                 1
                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
    A5            |1 0 1|M|C|H|S|D|      TS*      |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -

                                                 1 1             2
                   0             7 8             5 6             3
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
    A6            |1 1 0|M|C|H|S|D|t|             TS*             |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -

                                                 1
                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
    A7            |1 1 1|M|C|H|S|D|T|t|    SEQ*   |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -

                                                 1
                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    B2            |0 1 0|M|      TS*      |  SEQ* |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                                 1
                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    B3            |0 1 1|M|  TS*  |     ID LSB    |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Bormann (ed.)                                                  [Page 46]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000





                   0             7
              - - +-+-+-+-+-+-+-+-+
    B4, D4        |1 0 0|M| ID LSB|
              - - +-+-+-+-+-+-+-+-+


                   0             7
              - - +-+-+-+-+-+-+-+-+ - -
    B5            |1 0 1|M|H|D|T|I|
              - - +-+-+-+-+-+-+-+-+ - -

                                                 1               2
                   0             7 8             5               3
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    B6            |1 1 0|M|t|         TS*         |     ID LSB    |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                                 1
                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
    B7            |1 1 1|M|C|H|S|D|T|I|t|   SEQ*  |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -

                                                 1
                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    C1, D1        |0 0 1|M|         SEQ*          |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                                 1
                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
    C2, D2        |0 1 0|M|C|H|S|       SEQ*      |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -


                   0             7
              - - +-+-+-+-+-+-+-+-+ - -
    C3, D3        |0 1 1|M|C|H|S|-|
              - - +-+-+-+-+-+-+-+-+ - -


                   0             7 8             5
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    D5            |1 0 1|M|        ID LSB         |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Bormann (ed.)                                                  [Page 47]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


                                                 1 1             2
                   0             7 8             5 6             3
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
    D6            |1 1 0|M|C|H|S|-|              ID               |
              - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -


   Bit masks indicating additional fields have the following meaning:

   C - Traffic (C)lass / Type Of Service
   H - (H)op Limit / Time To Live
   S - Contributing (S)ources - CSRC
   D - Timestamp (D)elta
   T - (T)imestamp LSB
   I - (I)dentification LSB

   If any of these fields are included, they will appear in the order as
   listed above and the format of the fields will be as described below.

   C - Traffic Class / Type Of Service

       The field contains the value of the original IP header field.

                8 bits
       - - +-+-+-+-+-+-+-+-+ - -
           |   TC / TOS    |
       - - +-+-+-+-+-+-+-+-+ - -


   H - Hop Limit / Time To Live

       The field contains the value of the original IP header field.

                8 bits
       - - +-+-+-+-+-+-+-+-+ - -
           |   HL / TTL    |
       - - +-+-+-+-+-+-+-+-+ - -


   S - Contributing Sources

       The CSRC field is built up of:

       - a counter of the number of CSRC items present (4 bits)
       - an unused field (4 bits)
       - the CSRC items, 1 to 15 (4-60 octets)

                1 octet    +     4 to 60 octets
       - - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+ - -
           | Count | Unused|      CSRC Items       |
       - - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+ - -



Bormann (ed.)                                                  [Page 48]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000




   D - Timestamp Delta

       The Timestamp Delta field is a one-octet field. We want to
       communicate Timestamp Delta values corresponding to 80 ms.
       Therefore, the Timestamp Delta value communicated is not the
       actual number of samples, but the number of samples divided by
       8. Thus, only Timestamp Delta values evenly divisible by 8 can
       be communicated in the Timestamp Delta field of an extension. On
       the other hand, the maximum value is 255*8 = 2040 (255 ms at
       8000 Hz). Delta values larger than 2040 or delta values not
       evenly divisible by 8 must be communicated in a DYNAMIC packet.

                 8 bits
       - - +-+-+-+-+-+-+-+-+ - -
           |Timestamp Delta|
       - - +-+-+-+-+-+-+-+-+ - -

       Note that when the Timestamp Delta is changed, Timestamp LSB
       field MUST also be included not downscaled with the delta.


   T - Timestamp LSB

       The field contains the 16 least significant bits of the RTP
       timestamp, scaled if t-bit not set. May be sent as extended
       range for some profiles.

                        16 bits
       - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
           |              TS*              |
       - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -


   I - Identification

       The field contains the IP Identification.

                        16 bits
       - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |              ID               |
       - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   When information of any kind is sent in an extension, the
   corresponding information SHOULD also be sent in some subsequent
   packets (either as Extensions or in DYNAMIC packets).





Bormann (ed.)                                                  [Page 49]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


5.7.5.  Feedback packets

   Feedback packets are used by the decompressor to provide various
   types of feedback to the compressor. That could include active
   feedback to assure error free performance or passive feedback (in
   case of invalidated context) to request a context update from the
   compressor. The feedback mechanisms defined here leave a lot to the
   implementation regarding how to use feedback. The general feedback
   packet format is shown below:

                                   0   1   2   3   4   5   6   7
                                 +...+...+...+...+...+...+...+...+
    FEEDBACK (GENERAL)           :   Context Identifier  (CID)   :
                                 +---+---+---+---+---+---+---+---+
                                 | 1   1   1   1   0 |    Type   |
                                 +---+---+---+---+---+---+---+---+

   Note that The CID field is present only for profiles using STATIC
   packet format 2 or 4, which are profiles supporting multiple packet
   streams. The Type field tells what kind of feedback the packet
   corresponds to and the feedback types defined are the following:


                                   0   1   2   3   4   5   6   7
                                 +...+...+...+...+...+...+...+...+
    STATIC_FAILURE_FEEDBACK      :   Context Identifier  (CID)   :
                                 +---+---+---+---+---+---+---+---+
                                 | 1   1   1   1   0 | 0   0   0 |
                                 +---+---+---+---+---+---+---+---+

   The STATIC_FAILURE_FEEDBACK packet tells the compressor that the
   static part of the decompressor context is invalid, and that an
   update of that part is required. Reasons for sending such feedback
   could be that no STATIC packet has been received at all, or that
   decompression has failed even when DYNAMIC packets are decompressed.


                                   0   1   2   3   4   5   6   7
                                 +...+...+...+...+...+...+...+...+
    INVALID_CONTEXT_FEEDBACK     :   Context Identifier  (CID)   :
                                 +---+---+---+---+---+---+---+---+
                                 | 1   1   1   1   0 | 0   0   1 |
                                 +---+---+---+---+---+---+---+---+
                                 |   Last Sequence Number LSB    |
                                 +---+---+---+---+---+---+---+---+

   The INVALID_CONTEXT_FEEDBACK packet SHOULD be sent to signal an
   invalid decompressor context, indicated by failing decompression of
   COMPRESSED packets.





Bormann (ed.)                                                  [Page 50]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


                                   0   1   2   3   4   5   6   7
                                 +...+...+...+...+...+...+...+...+
    NO_PACKETS_FEEDBACK          :   Context Identifier  (CID)   :
                                 +---+---+---+---+---+---+---+---+
                                 | 1   1   1   1   0 | 0   1   0 |
                                 +---+---+---+---+---+---+---+---+
                                 |   Last Sequence Number LSB    |
                                 +---+---+---+---+---+---+---+---+

   The NO_PACKET_FEEDBACK packet can be used by the decompressor to
   signal that packets have not been received for some time. It is not
   always possible for the decompressor to notice such events, and it is
   therefore up to the implementers to decide whether and when to use
   this feedback packet.


                                   0   1   2   3   4   5   6   7
                                 +...+...+...+...+...+...+...+...+
    LONGEST_LOSS_FEEDBACK        :   Context Identifier  (CID)   :
                                 +---+---+---+---+---+---+---+---+
                                 | 1   1   1   1   0 | 0   1   1 |
                                 +---+---+---+---+---+---+---+---+
                                 |   Last Sequence Number LSB    |
                                 +---+---+---+---+---+---+---+---+
                                 |    Length of longest loss     |
                                 +---+---+---+---+---+---+---+---+

   The LONGEST_LOSS_FEEDBACK packet can be used by the decompressor to
   inform the compressor about the length of the longest loss event that
   has occurred on the link between compressor and decompressor. It is
   not always possible for the decompressor to provide this information,
   and it is therefore up to the implementers to decide whether and when
   to use this feedback packet.


                                   0   1   2   3   4   5   6   7
                                 +...+...+...+...+...+...+...+...+
    CONTEXT_UPDATED_FEEDBACK     :   Context Identifier  (CID)   :
                                 +---+---+---+---+---+---+---+---+
                                 | 1   1   1   1   0 | 1   0   0 |
                                 +---+---+---+---+---+---+---+---+
                                 |   Last Sequence Number LSB    |
                                 +---+---+---+---+---+---+---+---+

   The CONTEXT_UPDATED_FEEDBACK packet can be used to signal that an
   update of some header fields has been correctly received, either in a
   DYNAMIC packet or in an EXTENDED_COMPRESSED packet. It is optional to
   use this active feedback mechanism and the compressor MUST NOT expect
   such packets initially. First after reception of one such packet, the
   compressor can expect to get this feedback from the decompressor.




Bormann (ed.)                                                  [Page 51]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


5.8.  Encoding of field values

   The source increases the RTP sequence number by one for each packet
   sent. However, due to losses and reordering before the compression
   point, the changes seen by the compressor may vary. This would
   especially be the case if we consider the scenario in Figure 1.1
   where there are cellular links at both ends of the path. That is one
   reason why sequence number changes need special treatment, but
   another reason is that both timestamps and IP identification for most
   packets can be recreated with a combination of history and sequence
   number knowledge. The profiles defined in this document handle the
   sequence number, timestamp and identification values with LSB
   encoding, except for some profiles that use LSP encoding for the
   sequence number. For timestamp, some profiles also use the principle
   with timer-based decompression. This chapter describes how the
   different encoding methods are applied to the various field values.


5.8.1.  LSB encoding of field values

   LSB encoding is used for sequence number, timestamp and
   identification encoding as described in chapter 4.5.1. The sequence
   numbers, included in all compressed headers, can be sent with
   extended range in extension headers. This is also the case with the
   timestamp value when not using timer-based TS reconstruction (see 5.7
   and 5.7.8). With timer-based timestamp decompression, the amount of
   timestamp LSB that is sent is always limited to the size of the field
   in the compressed header. Note that in most headers, the timestamp
   value is sent as STS LSB (scaled timestamp LSB), which means that it
   is the least significant bits of the timestamp, scaled down with the
   timestamp delta (STS LSB = LSB of [TS / TS Delta]).


5.8.2.  LSP encoding of field values

   LSP, as described in chapter 4.5.2, is used for sequence numbers in
   the "Sequence LSP" field of COMPRESSED1..COMPRESSED4 headers. For
   those headers, there are 28 code-points left for sequence information
   because 4 are reserved for packet type identification. An LSP of size
   28 is therefore used with the following encoding:

     CODE(n) = LSP:28(n)

   The sequence range can be extended with extra bits in extension
   headers, as described in chapter 4.5.3. The "SEQ EXT LSB" field must
   for the case of extended LSP consist of the LSB of the integer
   quotient.

   The reordering parameter for LSP MUST be set to 2 meaning that first
   and second order reordering can be handled by the encoding.




Bormann (ed.)                                                  [Page 52]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



5.8.3.  Timer-based timestamp decompression

   The RTP timestamp field is one of the header fields that may change
   dynamically on a per packet basis. For audio services, the timestamp
   value can be inferred from the encoded RTP sequence number value
   during talk spurts. When the encoded sequence number is incremented
   by N, the timestamp value is incremented by N * Timestamp-Delta-
   value. However, when a talk spurt has faded into silence and a new
   talk spurt starts, the timestamp value will take a leap compared to
   the sequence number. To communicate this leap in the timestamp value,
   some additional action has to be taken. In chapter 5.7.4, extension
   headers are defined that can transfer this leap in the timestamp
   value. That increases, however, the average header size. This chapter
   describes an optional method used by some profiles (see the TbT
   column of table 5.1) to reconstruct the timestamp value, requiring
   only a fixed number of added bits for timestamp leaps. The method
   makes use of timers or a local wall clock at the decompressor.

   To initialize the header compression and the timer-based timestamp
   reconstruction, the absolute value of the timestamp together with the
   sequence number must be transferred from compressor to decompressor
   at the beginning of the compression session. A default timestamp
   delta is also transferred. This is done through the transmission of a
   DYNAMIC header. For speech codecs with 8 kHz sampling frequency and
   20 ms frame sizes, for example, the timestamp delta will be 8000*0.02
   = 160. The decompressor then knows that the timestamp will increase
   by 160 for each packet containing 20 ms of speech. Hence, by using a
   local clock and by measuring packet arrival times, the decompressor
   can estimate the timestamp change compared to the previous packet.
   If, for example, a speech period has been succeeded by a silence
   period at the time T0 and a new speech period starts at the time
   T0+dT, it can be assumed that the timestamp has changed by:

      round(dT/(time for one speech frame)) * (timestamp delta)


   The packet time interval (or codec frame size in time) may be
   determined through the a priori knowledge that most speech codecs
   have constant frame sizes of 10, 20 or 30 ms, or through measurements
   on packet arrival times.

   The decompressor can then get an estimate of the timestamp change,
   add this change to the previous value and replace the least
   significant bits with those received in the compressed header. This
   should give the correct timestamp value.

   It is very important to verify the correctness of a timer-based
   timestamp decompression. However, this is automatically done in ROCCO
   with the header compression CRC verification.




Bormann (ed.)                                                  [Page 53]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


5.9.  Header compression CRCs, coverage and polynomials

   This chapter contains a description of how to calculate the different
   CRCs used in the packet headers defined in this document.


5.9.1. STATIC packet CRC

   The CRC in the STATIC header is calculated over the whole STATIC
   packet except for the header compression CRC itself. Therefore, the
   header compression CRC field MUST be set to 0 before the CRC
   calculation.

   The CRC polynomial to be used in STATIC packets is:

     C(x) = 1 + x + x^2 + x^8


5.9.2.  DYNAMIC packet CRC

   The CRC in the DYNAMIC packet is calculated over the original
   IP/UDP/RTP header. Before the calculation of the CRC, the IPv4 header
   checksum and the UDP checksum have to be set to 0. This makes it
   possible to recalculate the checksums after the decompression.
   Calculation over the full IP/UDP/RTP headers ensures that the
   decompressed IP/UDP/RTP header is a correct header.

   The CRC polynomial to be used in DYNAMIC packets is:

     C(x) = 1 + x + x^2 + x^8


5.9.3.  COMPRESSED packet CRCs

   COMPRESSED1..COMPRESSED4

   The header compression CRC in COMPRESSED header types 1 to 4 is
   calculated over the same headers as the CRC in the DYNAMIC packet,
   except for profiles which use replacement of the UDP checksum, I.e.
   except for profiles 1-4 and 13-16. In profiles 1-4 and 13-16, the
   header compression CRC also covers the payload covered by the UDP
   checksum.

   The polynomial to be used is:

     C(x) = 1 + x + x^4 + x^5 + x^9 + x^10








Bormann (ed.)                                                  [Page 54]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   COMPRESSED5..COMPRESSED8 and COMPRESSED13..COMPRESSED16

   In COMPRESSED header types 5 to 8 and 13 to 16 the header compression
   CRC is calculated over the same headers as the CRC in the DYNAMIC
   packet, but with a different polynomial:

     C(x) = 1 + x + x^3

   COMPRESSED9..COMPRESSED12

   In COMPRESSED header types 9 to 12 the header compression CRC is
   calculated over the same headers as the CRC in the DYNAMIC packet,
   but with a different polynomial:

     C(x) = 1 + x + x^3 + x^4 + x^6

   COMPRESSED17..COMPRESSED20

   In COMPRESSED header types 17 to 20 the header compression CRC is
   calculated over the same headers as the CRC in the DYNAMIC packet,
   but with a different polynomial:

     C(x) = ????


5.10 State transitions using keyword packets

   (Editor: This section is separate because I believe merging it in is
   not just an editorial exercise.)

5.10.1 The concept of keyword based state transitions

   The main purpose of this algorithm is to enable the compressor to
   employ the optimistic approach (for uni- or bi-directional links) as
   described in greater detail in sections 5.3.1 and 5.3.2.

   For an optimistic approach the compressor decides when it wants to
   proceed from FO to SO state. Basically the transition will be made
   after the compressor thinks the FO packets are received correctly and
   the valid context is established. However this is an optimistic and
   not a reliable approach. The compressor might proceed to SO state and
   send SO packets, while the decompressor lost packets and is still in
   FO state. Therefore a mechanism is needed to detect this case.

   This section describes in greater detail the mechanism of using
   keyword packets to transit securely from FO to SO state.

5.10.1.1 Keyword field, update and non-update packet

   The algorithm is based on the concept that some packets update the
   context, namely update packets, while others do not update the



Bormann (ed.)                                                  [Page 55]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   context at all, namely non-update packets. All packets indicate the
   context state that is referenced and therefore needed to decompress
   the packet correctly.

   The main idea how this is done is the definition of a keyword field.
   The packets with the same keyword field value, reference the same
   context state. The context state to be used is defined by sending a
   update packet, i.e. a packet that has a new keyword value and which
   contents update the context to the new context state. The following
   packets are called non-update packets, because they do not update the
   context.

   Hence, if a non-update packet gets lost, the receiver is nevertheless
   able to decompress the following packets.

5.10.1.2 Refreshing the context by sending update packets

   From time to time it will be necessary to update the context. There
   are mainly two reasons to do so.

   First, while compressing and transmitting the compressed non-update
   packets, the LSB encoded values may increase and need more coded bits
   in the compressed header. If the header size exceeds a certain
   threshold, a new keyword should be sent in an update packet. This
   enables the compressor to use less LSB in the following non-update
   packets. E.g. after a while the number of LSB to encode the RTP
   sequence number will grow. If this value exceeds 6 bits, it might be
   useful to send an update packet, because the information would not
   fit into an one-byte header packet any more. After the successful
   update the compressor is able to send one-byte header packets again.

   This means that the compressor is still in SO state and thus sends SO
   packets. The corresponding update packets that are sent are also SO
   packets, because they still rely on the previous update. This also
   means that the update packets are small, i.e. only two bytes in size.

   Second, if a value had changed and seems to be stable now, a new
   update packet should be sent. This means a transition from SO to FO
   state happened. It is not possible to use SO packets any more,
   because some fields can not be calculated from the RTP sequence
   number any more. It is not necessary to send update packets in FO
   state. The problem would be, that changed value would have to be
   transmitted in all following packets. This means that FO packets have
   to be send all the time, i.e. the compressor stays in FO state. To
   get into SO state, the compressor has to use the optimistic approach,
   which says that if he thinks the decompressor has established the new
   context he switches to SO state. To update the context at the
   decompressor, update packets have to be sent.

   E.g. after a silent period the timestamp changes by another value
   than the default difference timestamp. From this on it is not



Bormann (ed.)                                                  [Page 56]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   possible for the decompressor to calculate the timestamp from the RTP
   sequence number. The compressor is in FO state and either sends the
   LSB of the timestamp in every packet, or updates the context, to
   enable a later transition to SO state again.

5.10.1.3 Minimizing the loss probability of update packets (safe
transition from FO to SO state)

   This section describe the transition from FO to SO state in greater
   detail and gives algorithms that support a save transition.

   It is useful to send several update packets with the same keyword
   value to establish a new context state for both sides, before going
   to SO state. The LSB encoded values are transmitted as usual in those
   packets, while one has to take care that the original values of the
   fields that changed irregularly are transmitted in every of those
   update packets. The use of this mechanism reduces the context state
   loss probability, because only one of those update packets has to be
   received correctly.

   Sending several update packets with the same keyword could be done
   either successively or in any kind of sparse mode, e.g. as described
   in [ref to sparse mode description, TBD].

5.10.1.4 Restrict the use of new keywords

   The number of different keywords is limited by the number of bits
   used for the keyword field. Here only one bit is used, which leads to
   two different keywords. To ensure that consecutive packet loss of a
   few packets does not lead to wrong decompression, the use of new
   keyword values must be limited.

   It is only allowed to send a new keyword in an update packet, if N
   non-update packets were sent since the last keyword change. The value
   N should be set according to the expected longest loss event. This
   restriction is possible, because one never is forced to send an
   update packet. It is always possible to send all information in a
   non-update packet. This might lead to a decreased efficiency for
   short times, because the compressor stays longer in FO state, but if
   the keywords are used properly, this should only very seldom happen.

   To use the keyword properly means that it is only changed if the
   compressor is rather sure that the values will remain constant for
   the next packets. An example of a non-properly used keyword change is
   the definition of a new default delta timestamp value (in an update
   packet), just because it changed for one packet. This might be due to
   a silent period and might change back to the original value in the
   next packet again.

   If the compressor follows this restriction, more than N consecutive
   packets have to be lost, before the decompressor would not detect the



Bormann (ed.)                                                  [Page 57]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   loss of the update packet. To avoid even this situation a time-out
   might be applied, after which the decompressor will only accept new
   update packets or Full Header packets.

5.10.1.5 Loss of update packets

   Only if the update packets are transmitted correctly, the receiver is
   able to decompress any incoming compressed header (i.e. the receiver
   is then in SO state). Therefore if the update packets are transmitted
   multiple times, the probability that none of this packets is
   received, is very low. However, packet loss may occur while
   transmitting update packets. In case none of the update packets was
   received and the decompressor received a packet with a new keyword
   that is not an update packet, it must send a message to the
   compressor, to ask for a packet with a header that re-establishes its
   context. This is always an update packet or a Full Header packet.

5.10.1.6 The use of LSB encoding in the context of this algorithm

   The packets that follow an update packet, are encoded by transmitting
   the Least Significant Bits (LSB) of regular changing fields (e.g. RTP
   Sequence Number). In some cases it might not be necessary to transmit
   the regular changing fields at all, e.g. if the timestamp can be
   calculated from the sequence number it is not transmitted. The
   packets also contain the original values of fields that did change
   since the last update, but are usually assumed to be constant (e.g.
   RTP Marker bit, RTP Payload Type).

   A problem in using LSBs is the wrap-around. Because only some bits of
   the original value is transmitted, it has to be ensured, that the
   decompression is correct. If other bits than the transmitted bits
   have changed, the decompressor must be able to compute this.

   To solve this problem Variable Length Encoding (VLE) as described in
   [ref to VLE] is used.

5.10.1.7 Adaptation to the environment

   The compressor has a lot of freedom in the compression algorithm.
   Even though the use of new keywords is restricted, the compressor
   decides when the keywords should be changed. Two strategies are
   possible, which are a trade-off between compression efficiency and
   robustness against packet loss. One possibility is to send a new
   keyword as often as needed and possible. E.g. the keyword is changed,
   if the header size exceeds 1 byte. Another possibility is to sent new
   keywords less frequent. While on the one hand the compression
   efficiency might be better in the first case, the second possibility
   is more robust and less susceptible for packet loss.

   Using this freedom the compressor may adapt the compression to the
   environment (i.e. the experienced BER or RTT). Another parameter of



Bormann (ed.)                                                  [Page 58]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   the environment that should be taken into consideration is the
   assignment of the IPv4 Identification value. While it is possible to
   have a totally random IP Identification, it might also be possible
   that it is increased for every packet by a fixed value (sequential IP
   ID). Different sets of packet types, used for different environments
   might lead to a better performance. This paper defines two different
   packet type sets. The packet formats are optimised for different
   environments. If the IP ID is assigned sequentially, increasing by a
   fixed value for each packet, the header compression mechanism should
   take advantage of it. Anyway, because we cannot assume this
   behaviour, another set of packet formats is defined, which is
   optimised for non sequential IPv4 Identification values.

   The two sets of packet formats are called packet-profiles in the
   remainder of this document.

5.10.1.8 Dealing with Residual Bit Error Rate

   A requirement from the lower layers that this header compression
   scheme works above, is that the residual bit error rate should be
   kept to a minimum. However bit errors might occur in compressed
   packet. To avoid a damage propagation (see [requirements document]
   for the definition of damage propagation) the update packets are
   protected by a CRC, which is calculated over the uncompressed header.
   Detailed information about the CRC and its usage can be found in
   section [CRC usage]. Because only the update packets update the
   context on which the non-update packets rely, damage propagation is
   prevented, by protecting only the update packets.

5.10.3 Packet-Profile 1, optimized for sequential IPv4 Identification

   This section shows five different packets that are used to transmit
   the data and signal errors from the receiver to the sender. The
   packet formats are optimised for the use in an environment, where the
   IPv4 Identification is assigned sequentially for the compressed
   packet stream. The format of the packets is described and it is
   explained in detail how the decompressor is able to regenerate the
   complete header from the given information. The exact compression
   behaviour is implementation specific, but it has to be ensured, that
   any decompressor is able to regenerate the complete header in the
   described way.


5.10.3.1 Full Header packet

   The Full Header packet is sent at the beginning of the session to
   establish a valid context, i.e. to switch from Init- to FO state. It
   is only sent another time if requested by the receiver or a severe
   error occurred. The receiver must request a Full Header packet only
   if the initial packet was lost, or a severe error occurred, that
   cannot be solved by a Compressed Packet.



Bormann (ed.)                                                  [Page 59]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



   To ensure the correct reception of the fields that are only
   transmitted in this packet type, it might be useful to use this
   packet type for several succeeding packets. The next packet type to
   use is always an update packet, which contains a new keyword. The
   decompressor will discard any other received packet and sent a
   context state feedback, until it receives an update packet to
   establish a valid context (the keyword is part of the context).

   The format of this packet's header is quite similar to the original
   IP/UDP/RTP header. However, as described in other header compression
   papers, such as CRTP [7], the length fields of the IP and UDP packets
   are redundant. They are usually signalled by the link layer. This
   enables us to use these fields to signal the header compression
   specific session context identifier (CID)as follows:


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C-L|                           |   First length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     (CID)     |     (CID)     |   Second length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   C-L (CID Length):
     00 - no CID
     01 - 8 bit
     10 - 16 bit

   The selection of 0, 8 or 16 bit CIDs enables the compressor to set-up
   enough sessions while keeping the overhead to a minimum.

   Packet type identification might not be done by the link layer. In
   this case another byte is added before the original full header:

   +-+-+-+-+-+-+-+-+
   |1|1|1|0|-|-|-|-|    Packet Type Identification
   +-+-+-+-+-+-+-+-+
   :  RTP/UDP/IP   :
   :    packet     :

5.10.3.2 Basic-Compressed packet

   FO packets are always of this type. Only if no extensions are
   transmitted, this is an SO packet. This is useful either to enlarge
   the number of RTP sequence number bits, or to send an update packet
   out of SO state.

   The header of the Basic-Compressed packet is divided into a basic
   header that is transmitted for every packet of this type and header



Bormann (ed.)                                                  [Page 60]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   extensions that are only used if necessary. Update and non-update
   packets can be sent in Basic-Compressed packet format. The type is
   identified by the new keyword flag, which is set for update packets.

5.10.3.2.1 Basic header

   The basic header's format is as follows:
     0   1   2   3   4   5   6   7
   +...+...+...+...+...+...+...+...+
   :      MSB of Session CID       :  if 16 bit CID is used
   +...+...+...+...+...+...+...+...+
   :      LSB of Session CID       :  if 16 or 8 bit CID is used
   +---+---+---+---+---+---+---+---+
   | 1 | 1 | 0 |KW |NKW| M | E | S |
   +---+---+---+---+---+---+---+---+
   :         LSB of RTP SN         :
   +...+...+...+...+...+...+...+...+
   :         MSB of RTP SN         :  if S==1
   +...+...+...+...+...+...+...+...+
   :                               :
   :           Extension(s)        :  if E==1
   :                               :
   +...+...+...+...+...+...+...+...+
   :                               :
   +           UDP Checksum        +  if non-zero in context
   :                               :
   +...+...+...+...+...+...+...+...+
   :              CRC              :
   +---+---+---+---+---+---+---+---+
   |           RTP Data            |
   :                               :
   CID:
   The first two bytes can be used for the session CIDs.

   KW (Keyword):
   The Keyword field must be present in every packet. To detect loss of
   update packets, it must be changed at each renewal.

   NKW (New Keyword Indication):
   If this bit is set, the compressor defines this packet as an update
   packet. The context state after decompressing this packet is stored
   and referenced in the following packets. Several successive update
   packets should be sent, each containing the relevant information, to
   ensure the reception at the decompressor. This bit also indicates the
   presence of the CRC.

   M (RTP Marker):
   The M-bit represents the original RTP Marker.
   E (Extension):
   This bit indicates that at least one extension is used. The different
   possible extensions, that are used to transmit information about



Bormann (ed.)                                                  [Page 61]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   irregular changes in the header fields, are described in detail in
   the following sections.

   S (RTP Sequence Number Indication):
   This bit indicates if the LSB of the RTP Sequence Number or the
   original value follows directly.
      S=0: 8 bit LSB RTP Sequence Number
      S=1: 16 bit RTP Sequence Number

   UDP Checksum:
   If the UDP Checksum is enabled, this field contains the 16-bit
   Checksum, else it is not present.

   CRC:
   This 8 bit CRC is calculated over the uncompressed header. It is used
   to verify the correct transmission of the compressed packet.

5.10.3.2.2 Changing Field Extension

   This extension is sent every time some header fields changed in an
   irregular way and cannot be calculated from the RTP Sequence Number.
   This might be the case e.g. for the RTP Timestamp after a silent
   period, or for the IPv4 Time To Live value. If the NKW-bit is set
   (i.e. the packet is an update packet), the fields transmitted in this
   extension define the new context state to be referenced by the
   following packets. Several successive update packets should be sent,
   each containing the relevant fields, to ensure the reception at the
   decompressor.

   The format of the Changing Field Extension is defined below:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 0 |  ID   |TS |TOS|TTL|PT | E |
   +---+---+---+---+---+---+---+---+
   .                               .
   .   (LSB) IPv4 Identification   .  if ID > 0
   .                               .
   +...+...+...+...+...+...+...+...+
   .                               .
   .      (LSB) RTP Timestamp      .  if TS == 1
   .                               .
   +...+...+...+...+...+...+...+...+
   :      IPv4 Type of Service     :  if TOS == 1
   +...+...+...+...+...+...+...+...+
   :      IPv4 Time To Live        :  if TTL == 1
   +...+...+...+...+...+...+...+...+
   :      RTP Payload Type     : - :  if PT == 1
   +...+...+...+...+...+...+...+...+

   The first bit (0) indicates the extension that is used.



Bormann (ed.)                                                  [Page 62]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   ID (IPv4 Identification Indication):
   This bit indicates if the original IPv4 Indication value is
   transmitted in the IPv4 Identification field or the LSB of the
   Identification or nothing.
      ID=0: No IPv4 Identification
      ID=1: 8 bit LSB IPv4 Identification
      ID=2: 16 bit IPv4 Identification
      ID=3: not used

   TS (RTP Timestamp Indication):
   This bit indicates if the RTP Timestamp is transmitted. If it is set
   to one, one of the following fields are used in the (LSB) RTP
   Timestamp field:

      +---+---+---+---+---+---+---+---+
      | 0 |                           |
      +---+  15 LSB of RTP Timestamp  +
      |                               |
      +---+---+---+---+---+---+---+---+

      +---+---+---+---+---+---+---+---+
      | 1 | 0 |                       |
      +---+---+                       +
      |                               |
      +      22 LSB of RTP Timestamp  +
      |                               |
      +---+---+---+---+---+---+---+---+

      +---+---+---+---+---+---+---+---+
      | 1 | 1 | 0 |                   |
      +---+---+---+                   +
      |                               |
      +      29 LSB of RTP Timestamp  +
      |                               |
      +                               +
      |                               |
      +---+---+---+---+---+---+---+---+

      +---+---+---+---+---+---+---+---+
      | 1 | 1 | 1 | 0 | -   -   -   - |
      +---+---+---+---+---+---+---+---+
      |                               |
      +                               +
      |                               |
      +        RTP Timestamp          +
      |                               |
      +                               +
      |                               |
      +---+---+---+---+---+---+---+---+
   TOS (IPv4 Type Of Service Indication):




Bormann (ed.)                                                  [Page 63]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   This bit indicates the transmission of the IPv4 Type Of Service value
   in the IPv4 Type Of Service field.

   TTL (IPv4 Time To Live Indication):
   This bit indicates the transmission of the IPv4 Time To Live value in
   the IPv4 Time To Live field.

   PT (RTP Payload Type Indication):
   This bit indicates the transmission of the RTP Payload Type value in
   the RTP Payload Type field.

   E (Extension):
   This bit indicates that another extension follows this one.

5.10.3.2.3 Default Delta Extension

   The compressor will follow the changes in the RTP Timestamp values
   and the IPv4 Identification values, relative to the changes in the
   RTP Sequence Number values. To do this a delta value according to the
   following equation might be used:

   dTS = (TS(n)-TS(n-1)) / (SN(n)-SN(n-1)), with

      dTS     : delta Timestamp
      TS(n)   : Timestamp of current packet
      TS(n-1) : Timestamp of previous packet
      SN(n)   : Sequence Number of current packet
      SN(n-1) : Sequence Number of previous packet

   If the compressor detects that for several packets the delta
   timestamp or delta identification value is the same, this delta value
   can be used to calculate the timestamp or identification from the
   sequence number. To do so, the decompressor has to be informed about
   this default delta value. The compressor uses this extension to
   signal default delta timestamp (ddTS) or default delta identification
   (ddID) values to the decompressor. This extension should be sent in
   update packets only. If it is used, a change extension, containing
   the timestamp or respectively the identification field must be sent
   as well.

   The format of the Default Delta Extension is given below:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1 | 0 | - | - | ddTL  | ddIDL |
   +---+---+---+---+---+---+---+---+
   :              ddTS             :   if ddTL > 0
   +...+...+...+...+...+...+...+...+
   :              ddTS             :   if ddTL > 1
   +...+...+...+...+...+...+...+...+
   :              ddTS             :   if ddTL > 2



Bormann (ed.)                                                  [Page 64]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   +...+...+...+...+...+...+...+...+
   :              ddID             :   if ddIDL > 0
   +...+...+...+...+...+...+...+...+
   :              ddID             :   if ddIDL > 1
   +...+...+...+...+...+...+...+...+

   The first four bits identify this extension.

   ddTL (default delta Timestamp Length):
   This field indicates the length of the default delta Timestamp field:
      ddTL=0: no default delta Timestamp field present
      ddTL=1: 1 byte
      ddTL=2: 2 byte
      ddTL=3: 3 byte

   ddIDL (default delta Identification Length):
   This field indicates the length of the default delta Identification
   field:
      ddIDL=0: no default delta Identification field present
      ddIDL=1: 1 byte
      ddIDL=2: 2 byte
      ddIDL=3: not used

5.10.3.3 One-Byte-Header or Two-Byte-Header packet

   Packets of these two types are always non-update packets. Since they
   only contain parts of the RTP sequence number they can only be sent
   in SO state and therefore they are SO packets. They reference the
   last update packet and carry the same keyword value.


   If the compressor communicated the default delta values to the
   decompressor and all changes are regular, the decompressor should be
   able to recalculate the identification and timestamp value from the
   sequence number. Hence it is not necessary to transmit these values
   in all packets.

   The One-Byte-Header or Two-Bytes-Header packets cannot be used if
   other fields than the sequence number, timestamp and identification
   changed. The timestamp and identification also have to change
   according to the following equations:

   TS(n) = TS(n-1) + (SN(n) - SN(n-1)) * ddTS
   ID(n) = ID(n-1) + (SN(n) - SN(n-1)) * ddID

      ddTS    : default delta Timestamp
      ddID    : default delta Identification
      TS(n)   : Timestamp of current packet
      TS(n-1) : Timestamp of previous packet
      SN(n)   : Sequence Number of current packet
      SN(n-1) : Sequence Number of previous packet



Bormann (ed.)                                                  [Page 65]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      ID(n)   : Identification of current packet
      ID(n-1) : Identification of previous packet

   In this state the compressor might use the One-Byte-Header or Two-
   Byte-Header packet. These packets contain only the LSB of the RTP
   Sequence Number and the keyword, which is enough information for the
   decompressor to regenerate the original header.

   The packet format for the One-Byte-Header packet is given below:

     0   1   2   3   4   5   6   7
   +...+...+...+...+...+...+...+...+
   :      MSB of Session CID       :  if 16 bit CID is used
   +...+...+...+...+...+...+...+...+
   :      LSB of Session CID       :  if 16 or 8 bit CID is used
   +---+---+---+---+---+---+---+---+
   | 0 |KW |LSB RTP Sequence Number|
   +---+---+---+---+---+---+---+---+

   The packet format for the Two-Byte-Header packet is given below:

     0   1   2   3   4   5   6   7
   +...+...+...+...+...+...+...+...+
   :      MSB of Session CID       :  if 16 bit CID is used
   +...+...+...+...+...+...+...+...+
   :      LSB of Session CID       :  if 16 or 8 bit CID is used
   +---+---+---+---+---+---+---+---+
   | 1 | 0 |KW |                   |
   +---+---+---+
   |      LSB RTP Sequence Number  |
   +---+---+---+---+---+---+---+---+

   The decision which of these packets is to be used should be done
   according the context RTP sequence number. The not transmitted MSB of
   the RTP sequence number must not change.


5.10.3.4 Context State packet

   This header compression mechanism is aimed to perform good, even if
   used over an unreliable channel. Hence bit errors can occur quite
   frequently and packets will get lost. If the lost packet was a non-
   update packet, this does not effect the decompressor at all, but
   reception of a non-update packet with a new keyword, without
   receiving an corresponding update packet invalidates the
   decompressor's context. From this moment on any compressed packet,
   even if it was received correctly, cannot be decompressed, until the
   context is updated correctly again.

   To minimize the probability of this situation, several successive
   update packets should be sent (with the same keyword). But even all



Bormann (ed.)                                                  [Page 66]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   of these packets might get lost. Hence a mechanism is needed to
   inform the compressor about a lost context, to request an update
   packet.

   To request a context update, the decompressor must send immediately
   after detecting an invalid context, a Context State packet. This
   packet contains the last correctly received keyword and RTP Sequence
   Number. The compressor knows at reception of such a Context State
   packet, what information it has to send in the update extension, to
   update the decompressor's context correctly.

   Another error, that could occur, is the loss of the first packet,
   i.e. the Full Header packet. Since most of the header information,
   e.g. addresses and ports, are transmitted only in this packet, it is
   essential for the decompressor to establish a valid context to
   receive this packet. If the decompressor receives a Compressed
   packet, with a new session CID, that was not initialized, by a Full
   Header packet, this Full Header packet must have been lost. In this
   case the decompressor must request a new Full Header packet, by the
   means of the Context State packet.

   The format of the Context State packet is as follows:

   +...+...+...+...+...+...+...+...+
   :      MSB of Session CID       :  if 16 bit CID is used
   +...+...+...+...+...+...+...+...+
   :      LSB of Session CID       :  if 8 or 12 bit CID is used
   +---+---+---+---+---+---+---+---+
   |FHL|KW |                       |
   +---+---+---+---+---+---+---+---+
   :                               :
   +      RTP Sequence Number      +  if FHL == 0
   :                               :
   +...+...+...+...+...+...+...+...+

   CID:
   The first two bytes can be used for the session CID.

   FHL (Full Header Lost):
   If this bit is set to one, the first Full Header packet was lost, no
   context was established and a new Full Header packet is requested. If
   it is set to zero a context update is required and the RTP Sequence
   Number of the last correctly decompressed packet is transmitted as
   well.


5.10.4 Packet-Profile 2, optimized for non-sequential IPv4
Identification

   This section shows five different packets that are used to transmit
   the data from the sender to the receiver and signal errors from the



Bormann (ed.)                                                  [Page 67]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   receiver to the sender. The packet formats are optimised for the use
   in an environment, where the IPv4 Identification is not assigned
   strictly sequentially for the compressed packet stream. The
   identification value is expected to increase by a small random number
   (e.g. smaller than 64). The format of the packets is described and it
   is explained in detail how the decompressor is able to regenerate the
   complete header from the given information. The exact compression
   behaviour is implementation specific, but it has to be ensured, that
   any decompressor is able to regenerate the complete header in the
   described way.

5.10.4.1 Full Header packet

   The Full Header packet is sent at the beginning of the session to
   establish a valid context, i.e. to transit from Init- to FO state. It
   is used exactly as in packet-profile 1 and has the same format (see
   section 5.10.3.1 for details).

5.10.4.2 Basic-Compressed packet

   The header of the Basic-Compressed packet is divided into a basic
   header that is transmitted for every packet of this type and header
   extensions that are only used if necessary. As described for the
   previous packet-profile, this packet can be used for update packets
   (new-keyword flag set to one) or non-update packets. As described
   before if no extensions are used, this packet can be sent in SO state
   and therefore actually is an SO packet. Else it is an FO packet.

5.10.4.2.1 Basic header

   The basic header's format is as follows:

     0   1   2   3   4   5   6   7
   +...+...+...+...+...+...+...+...+
   :      MSB of Session CID       :  if 16 bit CID is used
   +...+...+...+...+...+...+...+...+
   :      LSB of Session CID       :  if 16 or 8 bit CID is used
   +---+---+---+---+---+---+---+---+
   | 1 | 1 | 0 |KW |NKW| M | E |S/I|
   +---+---+---+---+---+---+---+---+
   : Type  :                       :
   +...+...+  Sequence Number &    +  if S/I==1
   :          Identification       :
   +...+...+...+...+...+...+...+...+
   :                               :
   :           Extension(s)        :  if E==1
   :                               :
   +...+...+...+...+...+...+...+...+
   :                               :
   +           UDP Checksum        +  if non-zero in context
   :                               :



Bormann (ed.)                                                  [Page 68]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   +...+...+...+...+...+...+...+...+
   :              CRC              :
   +---+---+---+---+---+---+---+---+
   |           RTP Data            |
   :                               :

   CID:
   The first two bytes can be used for the session CIDs.

   KW (Keyword):
   The Keyword field must be present in every packet. To detect loss of
   update packets, it must be changed at each update.

   NKW (New Keyword Indication):
   If this bit is set, the compressor defines this packet as an update
   packet. The context state after decompressing this packet is stored
   and referenced in the following packets. Several successive update
   packets should be sent, each containing the relevant information, to
   ensure the reception at the decompressor. This bit also indicates the
   presence of the CRC.

   M (RTP Marker):
   The M-bit represents the original RTP Marker.

   E (Extension):
   This bit indicates that at least one extension is used. The different
   possible extensions, that are used to transmit information about
   irregular changes in the header fields, are described in detail in
   the following sections.

   S/I (RTP Sequence Number & Identification Indication):
   This bit signals that the LSB of the RTP Sequence Number and IPv4
   Identification follow directly.

   Type:
   These two bits indicate how the following bytes are used for the
   Sequence Number and Identification:
     Type = 0:
       7 bit RTP Sequence Number
       7 bit IPv4 Identification
     Type = 1:
       6 bit RTP Sequence Number
       16 bit IPv4 Identification
     Type = 2:
       8 bit RTP Sequence Number
       14 bit IPv4 Identification
     Type = 3:
       10 bit RTP Sequence Number
       12 bit IPv4 Identification

   UDP Checksum:



Bormann (ed.)                                                  [Page 69]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   If the UDP Checksum is enabled, this field contains the 16-bit
   Checksum, else it is not present.

   CRC:
   This 8 bit CRC is calculated over the uncompressed header. It is used
   to verify the correct transmission of the compressed packet.

5.10.4.2.2 Changing Field Extension

   This extension is used similar as in packet-profile one and also has
   the same format. For details see section 5.10.3.2.2.

5.10.4.2.3 Default Delta Extension

   This extension is used similar as in packet-profile one and also has
   the same format. For details see section 5.10.3.2.3.

5.10.4.2.4 Two-Byte-Header or Three-Byte-Header packet

   These two packet types can only be used for non-update packets. They
   reference the last update packet and therefore carry the same keyword
   value. These packets can only be sent in SO state and therefore are
   SO packets.

   If the compressor communicated the default delta values to the
   decompressor, the decompressor should be able to recalculate the
   timestamp value from the sequence number. Hence it is not necessary
   to transmit this value in all packets.

   These packets cannot be used if other fields than the sequence
   number, timestamp and identification changed. The timestamp also has
   to change according to the following equations:

   TS(n) = TS(n-1) + (SN(n) - SN(n-1)) * ddTS

      ddTS    : delta Timestamp
      TS(n)   : Timestamp of current packet
      TS(n-1) : Timestamp of previous packet
      SN(n)   : Sequence Number of current packet
      SN(n-1) : Sequence Number of previous packet

   In this state the compressor might use the Two-Byte-Header or Three-
   Byte-Header packet. These packets contain only the LSB of the RTP
   Sequence Number, LSB of IPv4 Identification and the keyword, which is
   enough information for the decompressor to regenerate the original
   header.

   The packet format for the Two-Byte-Header packet is given below:

     0   1   2   3   4   5   6   7
   +...+...+...+...+...+...+...+...+



Bormann (ed.)                                                  [Page 70]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   :      MSB of Session CID       :  if 16 bit CID is used
   +...+...+...+...+...+...+...+...+
   :      LSB of Session CID       :  if 16 or 8 bit CID is used
   +---+---+---+---+---+---+---+---+
   | 0 |KW |LSB RTP Sequence Number|
   +---+---+---+---+---+---+---+---+
   |    LSB IPv4 Identification    |
   +---+---+---+---+---+---+---+---+


   The packet format for the Three-Byte-Header packet is given below:

     0   1   2   3   4   5   6   7
   +...+...+...+...+...+...+...+...+
   :      MSB of Session CID       :  if 16 bit CID is used
   +...+...+...+...+...+...+...+...+
   :      LSB of Session CID       :  if 16 or 8 bit CID is used
   +---+---+---+---+---+---+---+---+
   | 1 | 0 |KW | T |               |
   +---+---+---+---+               +
   |      LSB RTP Sequence Number  |
   +               &               +
   |      LSB IPv4 Identification  |
   +---+---+---+---+---+---+---+---+

   The T-bit indicates how the next bits are used to transport the RTP
   Sequence Number and the IPv4 Identification:
      T=0:
        10 bit RTP Sequence Number
        10 bit IPv4 Identification

      T=1:
        8 bit RTP Sequence Number
        12 bit IPv4 Identification

   The decision which of these packets is to be used should be done
   according to the number of packets already sent after the last update
   packet (or the first update packet of a set of update packets sent
   successively). The not transmitted MSB of these values must not have
   changed.


5.10.4.3 Context State packet

   The use and format of the context state packet is similar to packet-
   profile 1, see section 5.10.3.3 for details.




6.  Implementation issues



Bormann (ed.)                                                  [Page 71]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



   This document specifies mechanisms for the protocol, while much of
   the usage of these mechanisms is left to the implementers to decide
   upon. This chapter is aimed to give guidelines, ideas and suggestions
   for implementing the scheme.


6.1.  Reverse decompression

   This chapter describes an optional decompressor operation to reduce
   discarded packets due to an invalid context.

   Once a context becomes invalid (e.g., in the case when more
   consecutive packet losses than expected has occurred), subsequent
   compressed packets cannot be decompressed correctly with normal
   decompression operation. This decompression operation aims at
   decompressing these packets with a later recovered context. The
   decompressor stores them until the context is validated. After the
   context is updated, the decompressor tries to recover the stored
   packets in the reverse order from the packet updating the context.
   Each time the stored packet is decompressed, its correctness is
   verified using the header compression CRC, which is transmitted in
   each compressed header. Correctly decompressed packets are
   transferred to upper layers in the original order.

   Note that this reverse decompression introduces buffering while
   waiting for the context to be validated and thereby introduces
   additional delay. Thus, it should be used only when some amount of
   delay could be accepted. For example, for video packets belonging to
   the same video frame, the delay of packet arrival time does not cause
   presentation time delay. Delay-insensitive streaming applications can
   also be tolerant to such delay.

   The following illustrates the decompression procedure in some detail:

   1. The decompressor stores compressed packets that cannot be
      decompressed correctly due to an invalid context.

   2. When the decompressor has received a context updating packet and
      the context has been validated, it starts to recover the stored
      packets in reverse order. Decompression is carried out followed
      by the last decompressed packet to its previous packet as if the
      two packets were reordered. After that, decompressor checks the
      correctness of the reconstructed header using the header
      compression CRC.

   3. If the header compression CRC indicates a successful
      decompression, the decompressor stores the complete packet and
      tries to decompress its previous packet. In this way, the stored
      packets are recovered from correctly decompressed packets until
      no compressed packets are left. For each packet, the decompressor



Bormann (ed.)                                                  [Page 72]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      checks the correctness of the decompressed headers using header
      compression CRC.

   4. If the header compression CRC indicates an incorrectly
      decompressed packet, the reverse decompression attempt must be
      terminated and all remaining packets must be discarded.

   5. Finally, the decompressor forwards all the correctly decompressed
      packets to upper layers in the original order.


6.2.  Pre-verification of CRCs

   For reasons of compression efficiency, it is desirable to keep the
   size of the header compression CRC as small as possible. However, if
   the size of the CRC is decreased, the reliability is also decreased
   and erroneous headers could be generated and passed on from the
   decompressor. It would then be desirable to find a method of
   increasing the strength of the CRC without making it larger.

   There is one property of the header compression CRC and its usage
   that can be used to achieve this goal. The CRCs that will occur at
   the decompressor will in most cases follow a pattern well known also
   to the compressor. There are two factors that will affect which CRCs
   are generated and in which order they will occur. If the decompressor
   makes several reconstruction attempts, the first factor affecting the
   CRCs will be the order and properties of the assumptions made for
   each reconstruction attempt. The attempts are in general:

   1:st attempt:    No loss is assumed
   2:nd attempt:    Loss of the preceding packet is assumed
   3:rd attempt:    Loss of the two preceding packets is assumed
   4:th attempt:    Loss of the three preceding packets is assumed
   etc.

   The other factor that will affect the CRCs generated is what has
   really happened to preceding packets, that is, if no loss has
   occurred or if one or several preceding packets have been lost
   between compressor and decompressor.

   Since the compressor knows how the decompressor performs the
   reconstruction attempts, the compressor can PRE-CALCULATE and VERIFY
   the most probable CRC situations. If a CRC is found not to detect an
   erroneous header, then a different packet type with a larger CRC
   (such as the "normal" COMPRESSED packet) should be used instead or
   additional information could be sent (by using EXTENDED_COMPRESSED or
   DYNAMIC packets). To ensure reliability, the important thing is that
   the CRC must fail if the header is not correctly reconstructed.
   Combining the two factors described above gives a list of the most
   probable CRCs that MUST fail.




Bormann (ed.)                                                  [Page 73]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   - If ONE packet WAS lost, attempt one (no loss) MUST fail
   - If TWO packets WERE lost, attempt one (no loss) MUST fail
   - If TWO packets WERE lost, attempt two (one lost) MUST fail
   - If THREE packets WERE lost, attempt one (no loss) MUST fail
   - If THREE packets WERE lost, attempt two (one lost) MUST fail
   - If THREE packets WERE lost, attempt three (two lost) MUST fail
   - etc.

   By doing PRE-CALCULATIONS of the six CRCs that would be the result of
   the events listed above, the CRC can be kept strong enough, even with
   a reduced size, because CRCs likely to fail will be avoided.


6.3.  New reconstruction attempts with LSB and LSP encoding

   ROCCO profiles using LSP encoding can handle 25 consecutive packet
   losses without invalidating the context. LSB or LSP encoding is also
   used for other fields and the range handled is then much larger.
   However, for all LSP or LSB decoding, the range can be extended with
   multiples by making reconstruction attempts (also called "guesses").
   The limiting factors are implementation complexity and time. The
   following example shows how this can be done:

   In chapter 5.3.2, LSP encoding is described. When an LSP encoded
   value for M code-points is decoded to a value S'(n), the original
   header can be reconstructed. If the CRC verification fails, a new
   reconstruction attempt could be made with S'(n)+M as the sequence
   number. If M was a multiple of 2 (LSB encoding), this would be the
   same as changing the value of the lowest MSB bit (i.e. the lowest bit
   NOT transmitted in LSB). More attempts could then be made increasing
   the sequence number by M for each attempt.























Bormann (ed.)                                                  [Page 74]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


7.  Further work

   (Editor: This section is _further work_ in particular as it needs to
   be integrated into the rest of the document.)

7.1.  Compression of IPv6 extension headers

   The ROHC scheme defined in this document currently do not support
   compression of IPv6 extension headers, which is an undesirable
   limitation. Therefore, it is necessary to investigate what is really
   needed from the compression scheme regarding compression of
   extensions, and also to further develop the scheme to include the
   desired extension support.

   1.  Header Compression for IPv6 Extension Header

      The IPv6 extension headers are encoded as a list of items. Each
   item is one of the extension headers. The length of each extension
   header may vary from each other. When more than one extension header
   is used in the same packet, the order of these extension headers is
   recommended in RFC 2460, but not mandatory. Thus, although it is
   unlikely to happen, the order of the extension headers may vary
   during the same session. In addition, one or more extension header
   may be added or removed during the session and the content of each
   extension header may change. Therefore, the IPv6 extension headers
   are classified as a list of items and the item list compression
   mechanism can be applied.

      The compression of IPv6 extension headers at the list level is
   specified in the item list compression scheme in Appendix COMPLIST.
   The compressed value of the extension header list is referred to as a
   compressed extension header list. The compression of IPv6 extension
   headers at the item level, i.e., the compression scheme used for each
   type of extension header, is defined in this subsection. The
   reference extension header used to compress a given extension header
   is the extension header in the reference list that has the same type.
   The compressed value of an extension header is referred to as a
   compressed extension header.

   1.1.  IPv6 Extension Header Types

      The table below summarizes classification of the various IPv6
   extension header fields. HbHH, DOH1, RH, FrH, AH, ESPH, DOH2, BU, BA,
   BR, and HA stand for Hop-by-Hop Options Header, Destination Options
   Header 1, Routing Header, Fragment Header, Authentication Header,
   Encapsulating Security Payload Header, Destination Options Header 2,
   Binding Update, Binding Acknowledgement, Binding Request and Home
   Address respectively.

      +--------+-------------+--------------------------------------+
      | Ext.   | Static      |              Non-static              |



Bormann (ed.)                                                  [Page 75]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      | Header |             +------------------+-------------------+
      | Type   |             |    Essential     |   Non-Essential   |
      +--------+-------------+------------------+-------------------+
      | HbHH   |             |                  | Next Header       |
      |        |             |                  | Hdr Ext Len       |
      |        |             |                  | Options           |
      +--------+-------------+------------------+-------------------+
      | DOH1   |             |                  | Next Header       |
      |        |             |                  | Hdr Ext Len       |
      |        |             |                  | Options           |
      +--------+-------------+------------------+-------------------+
      | RH     |             |                  | Next Header       |
      |        |             |                  | Hdr Ext Len       |
      |        |             |                  | Routing Type      |
      |        |             |                  | Segments Left     |
      |        |             |                  | type-specific data|
      +--------+-------------+------------------+-------------------+
      | RH     |             |                  | Next Header       |
      |        |             |                  | Hdr Ext Len       |
      |        |             |                  | Routing Type      |
      |        |             |                  | Segments Left     |
      |        |             |                  | type-specific data|
      +--------+-------------+------------------+-------------------+
      | FrH    | Reserved    | Identification   | Next Header       |
      |        | Res         | Fragment Offset  |                   |
      |        |             | M flag           |                   |
      +--------+-------------+------------------+-------------------+
      | AH     |             | Sequence Number  | Next Header       |
      |        |             | Authentication   | Payload Len       |
      |        |             | data             | SPI               |
      +--------+-------------+------------------+-------------------+
      | ESPH*  |             | Sequence Number  | SPI               |
      +--------+-------------+------------------+-------------------+
      | DOH2   |             |                  | Next Header       |
      |        |             |                  | Hdr Ext Len       |
      |   +----+-------------+------------------+-------------------+
      |   | BU | Option Type | Sequence Number  | Option Length     |
      |   |    | Reserved    |                  | A, H, R, D        |
      |   |    |             |                  | Prefix Length     |
      |   |    |             |                  | Lifetime          |
      |   |    |             |                  | Sub-Options       |
      |   +----+-------------+------------------+-------------------+
      |   | BA | Option Type | Sequence Number  | Option Length     |
      |   |    |             |                  | Status            |
      |   |    |             |                  | Lifetime          |
      |   |    |             |                  | Refresh           |
      |   |    |             |                  | Sub-Options       |
      |   +----+-------------+------------------+-------------------+
      |   | BR | Option Type |                  | Option Length     |
      |   |    |             |                  | Sub-Options       |
      |   +----+-------------+------------------+-------------------+



Bormann (ed.)                                                  [Page 76]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      |   | HA | Option Type |                  | Option Length     |
      |   |    | Home Address|                  | Sub-Options       |
      +---+----+-------------+------------------+-------------------+

      * note: Only the fields that can be compressed are listed.

   1.2.  Compression of IPv6 Extension Headers at Item Level

      For a given extension header in the extension header list, it can
   be classified as belonging to one of the three transformation cases
   defined in Appendix COMPLIST. Depending on the transformation case,
   the correspondent encoding technique is used. Note that the type-
   specific data field in the c_item with code "10" and "11" is not
   present.

   1.2.1 Special Treatment of Next Header Field

      The next header field in an extension header changes whenever the
   type of the immediately following header changes, e.g., a new
   extension header is inserted after it, the immediate subsequent
   extension header is removed from the list, or the order of several
   extension headers is changed. Thus, in particular, it may not be
   uncommon that for a given extension header, only the next header
   field changes but the remaining fields don't change. Therefore, the
   next header field in each extension header needs to be treated in a
   special way.

      The classification of the transformation case that an extension
   header belongs to should depend on the behavior of the other
   remaining fields except the next header field. In the case that only
   the next header field changes, the extension header should be
   considered as unchanged, and classified as belonging to
   transformation case A. In the other case where both the next header
   field and some remaining fields change, the compression of the
   remaining fields for each type of the extension header is specified
   in section 1.2.2. The special treatment of the change of the next
   header field is defined as follows.

      * In the case that a subsequent extension header is removed from
   the list or the order of several extension headers is changed, the
   new value of the next header field can be obtained from the reference
   extension header list. For example, assume that the reference
   extension header list (ref_list) consists of extension header A, B
   and C (ref_ext_hdr A, B, C), and the current extension header list
   (curr_list) only consists of extension headers A and C (curr_ext_hdr
   A, C). The order and value of the next header field of these
   extension headers are as follows.

        ref_list:
        +--------+-----+    +--------+-----+    +--------+-----+
        | type B |     |    | type C |     |    | type D |     |



Bormann (ed.)                                                  [Page 77]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


        +--------+     |    +--------+     |    +--------+     |
        |              |    |              |    |              |
        +--------------+    +--------------+    +--------------+
         ref_ext_hdr A        ref_ext_hdr B       ref_ext_hdr C

        curr_list:
        +--------+-----+    +--------+-----+
        | type C |     |    | type D |     |
        +--------+     |    +--------+     |
        |              |    |              |
        +--------------+    +--------------+
         curr_ext_hdr A      curr_ext_hdr C

        Comparing the curr_ext_hdr A in curr_list and the ref_ext_hdr A
   in ref_list, the value of next header field is changed from "type B"
   to "type C" because of removal of extension header B.  The new value
   of the next header field in curr_ext_hdr A, i.e., "type C" doesn't
   need to be sent to the decompressor, because when the decompressor
   detects (by observing the list level encoding) that the immediate
   following extension header B is removed from the list, it retrieves
   the next header field in ref_ext_hdr B and use it to replace the next
   header field in the curr_ext_hdr A.

        A similar scheme is used to regenerate the next header field
   when the order of several extension headers is changed.

      * In the case that a new extension header is inserted after an
   existing extension header, the next header field in the new extension
   header carries the type of itself, instead of the type of extension
   header that follows. For example, assume that the reference extension
   header list (ref_list) consists of extension header A and C
   (ref_ext_hdr A, C), and the current extension header list (curr_list)
   consists of extension header A, B and C (curr_ext_hdr A, B, C). The
   order and the value of the next header field of these extension
   headers are as follows.

        ref_list:
        +--------+-----+    +--------+-----+
        | type C |     |    | type D |     |
        +--------+     |    +--------+     |
        |              |    |              |
        +--------------+    +--------------+
         ref_ext_hdr A        ref_ext_hdr C

        curr_list:
        +--------+-----+    +--------+-----+    +--------+-----+
        | type B |     |    | type C |     |    | type D |     |
        +--------+     |    +--------+     |    +--------+     |
        |              |    |              |    |              |
        +--------------+    +--------------+    +--------------+
         curr_ext_hdr A      curr_ext_hdr B      curr_ext_hdr C



Bormann (ed.)                                                  [Page 78]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



        Comparing the curr_list and the ref_list, the value of the next
   header field in extension header A is changed from "type C" to "type
   B".

        In the compressed extension header list, the uncompressed
   curr_ext_hdr B is carried in the uncompressed data field in c_item or
   u_item depending on the list encoding scheme used.  However, instead
   of carrying the type of the next header (type C) in the next header
   field, the type of curr_ext_hdr B (type B) should be carried. When
   the decompressor detects (by observing the list level encoding) that
   a new extension is inserted after curr_ext_hdr A, it will replace the
   old next header field in ref_ext_hdr A with the type of the inserted
   extension header, i.e., type B, which is carried in the next header
   field in the c_item or u_item for extension header B. At the same
   time, the decompressor also replace the next header field in
   curr_ext_hdr B with the old value of the next header field in
   ref_ext_hdr A, i.e., type C.

   1.2.2.  Compression of Each Type of Extension Header

      In general, the encoding scheme used for each IPv6 extension
   header is similar to the scheme used for IPv4 and IPv6 base header,
   although the compressed format for each type of extension header may
   be different for each header. In this section, the format of the
   compressed data field in c_item or uc_item is defined for each type
   of extension header. Note that the non-essential fields discussed in
   the following subsections don't include the next header field.

   1.2.2.1.  Hop-by-Hop Options Header and Destination Options Header 1

      The hop-by-hop options header (HbHH) and the destination option
   header 1(DOH1, the header processed by the first destination that
   appears in the Ipv6 Destination Address field plus subsequent
   destinations listed in the Routing header) are expected to rarely
   change from packet to packet during the session. However, if any
   change happens to any field in these two headers, the correspondent
   compressed extension header is sent.

      The compressed HbHH consists of a bit mask that indicates the
   presence of the changed field, and the corresponding field value. The
   compressed DOH1 has the same structure as the compressed HbHH. The
   meaning of each field in the compressed HbHH is also the same as for
   the compressed DOH1. Therefore, in this subsection, only the
   compressed HbHH is discussed.

      The structure of compressed HbHH is as follows.

                         +---+---
   +:::::::::::::+::::::::::::::::::::::::+




Bormann (ed.)                                                  [Page 79]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      compressed HbHH:   | L | O | Hdr Ext Len | Compressed Option List
   |
                         +---+---
   +:::::::::::::+::::::::::::::::::::::::+

      * L bit indicates the presence of the Hdr Ext Len field that
   carries the value of Hdr Ext Len in the current HbHH.

      * O bit indicates the presence of the Compressed Option List field
   that carries the compressed value of the Options field.

      The Options field in HbHH is encoded as a list of options, and
   each option is considered as an item. The Options field can be
   compressed using the generic item list compression scheme specified
   in Appendix COMPLIST at the list level. At the item level, the format
   of the compressed option depends on the type of the option.

   1.2.2.2.  Routing Header

      The content of the Routing Header (RH) is expected to rarely
   change from packet to packet during the session. However, if any
   change happens to any field in RH, a compressed RH is sent.

      The structure of the compressed RH is as follows.
                     +---------------+:::::::::::::+::::::::::::::+
      compressed RH: | L | T | S | T | Hdr Ext Len | Routing Type |
                     +---------------+:::::::::::::+::::::::::::::+

      :::::::::::::::+:::::::::::::::::::::::::::::::::::::::::::::::::+
       Segments Left | type-specific data (compressed or uncompressed) |
      :::::::::::::::+:::::::::::::::::::::::::::::::::::::::::::::::::+

      The 4-bit bit mask indicates which fields are present.
      * L bit - Hdr Ext Len
      * T bit - Routing Type
      * S bit - Segments Left
      * T bit - type-specific data

      The Hdr Ext Len, Routing Type and Segments Left fields are all
   sent uncompressed. The type-specific data can be sent compressed or
   uncompressed. The type 0 routing header can be compressed using the
   scheme specified below and for any other unknown type of routing
   header, the type-specific data field should be sent uncompressed.

   1.2.2.2.1.  Compression of Type-specific Data Field in Type 0 Routing
   Header

      The type-specific data field in the type 0 routing header consists
   of Reserved field and a list of 128-bit addresses. The Reserved field
   is not expected to change and doesn't need to be sent in the
   compressed type-specific data field. The list of addresses is encoded



Bormann (ed.)                                                  [Page 80]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   as an item list and can be compressed using the scheme defined in
   Appendix COMPLIST. The structure of compressed type-specific data
   fields in the type 0 routing header is as follows.

      compressed type-specific data field in type 0 routing header:
      +---+----------------------------------------+
      | C | compressed / uncompressed address list |
      +---+----------------------------------------+

      C bit indicates the type of the following field. "0" indicates
   that the uncompressed address list is carried in the following field,
   while "1" indicates the compressed address list is carried. The
   decision of which format to use is up to the compressor. An example
   of the criteria could be compression efficiency or processing
   complexity.

      As mentioned before, the address list can be compressed using the
   scheme defined in Appendix COMPLIST. Each address in the address list
   is considered as an item. The insertion and removal scheme defined in
   Appendix COMPLIST can be used to encode the change.

   1.2.2.3.  Fragment Header

      If the fragment header (FrH) is present, its contents are expected
   to change from packet to packet. To address the change, a compressed
   FrH is sent.

      The structure of the compressed FrH is as follows.
                      +-----------------+--------+----------------------
   -----+
      compressed FrH: | Fragment Offset | M flag | compressed
   Identification |
                      +-----------------+--------+----------------------
   -----+

      The Fragment Offset and M flag fields in the compressed FrH are
   copies of the same fields in the original FrH. The compressed
   Identification field carries the compressed value of the
   Identification field in the original FrH, using the Identification
   field in the reference FrH as the reference. The scheme used to
   compress and encode Identification field is VLE as defined in [ACE].
   The format of compressed Identification using VLE is listed as
   follows.

      - "0" + 4-bit LSB
      - "10" + 8-bit LSB
      - "110" + 16-bit LSB
      - "111" + 32-bit LSB

   1.2.2.4.  Authentication Header and Encapsulating Security Payload
   Header



Bormann (ed.)                                                  [Page 81]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



      In the Authentication Header (AH), the SPI field only changes when
   a new security session is established, thus, it is expected to rarely
   change from packet to packet during the session. The Payload Len
   field changes only when SPI changes. Two change cases are listed as
   follow.

      * In the case that the SPI field changes, all the fields in AH may
   change.  For simplicity, an uncompressed AH is sent.

      * In the case that no change happens to the SPI field, the AH is
   not considered as changed. When the decompressor detects from the
   encoding that the AH is not changed, it copies the SPI and Payload
   Len fields from the reference AH. The other two fields in AH -
   sequence number and authentication data, are handled as defined
   below.

        The sequence number field in the AH contains a monotonically
   increasing counter value for a security association. Like IP-ID in
   Ipv4, if one observes only one of the flows, the sequence number in
   AH may appear to be nonlinear due to disruption by other IP flows
   that also use the same security association. If the sequence number
   in the AH linearly increases, it doesn't need to be sent. The
   decompressor regenerates this field by applying linear extrapolation
   (with delta = 1).  Otherwise, a compressed sequence number should be
   sent in a compressed IP/UDP/RTP header. The format of the compressed
   IP/UDP/RTP header containing the compressed sequence number should be
   defined in ROHC. The compression scheme for the sequence number in
   the AH is VLE, as defined in [ACE].

        The authentication data field in AH changes from packet to
   packet and should be sent in every packet. If the uncompressed AH is
   sent, the authentication data field is sent inside the uncompressed
   AH; otherwise, it is sent after the compressed IP/UDP/RTP and IPv6
   extension headers and before the payload.

      If Encapsulating Security Payload Header (ESP) is used, the UDP
   and RTP headers are both encrypted and cannot be compressed. In this
   case, special compressed packet format needs to be defined in ROHC.
   In ESP, the only fields that can be compressed are the SPI and the
   sequence number. If SPI field changes, the uncompressed ESP is sent;
   otherwise, a compressed ESP that carries all the fields except SPI
   and sequence number is sent. The sequence number in ESP has the same
   behavior as the same field in AH, thus, they are compressed in the
   same manner.

   1.2.2.5.  Destination Options Header 2

      The Destination Option Header 2 (DOH2) is for options to be
   processed only by the final destination of the packet. When ESP is
   used to provide security services, the DOH2 is encrypted and cannot



Bormann (ed.)                                                  [Page 82]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   be compressed.  Otherwise, the following compression mechanisms can
   be applied.

      DOH2 contains Hdr Ext Len and Options fields. If any change
   happens to any fields in DOH2, a compressed DOH2 is sent.

      The structure of the compressed DOH2 is as follows.
                       +-------------+-------------------------+
      compressed DOH2: | Hdr Ext Len | compressed options list |
                       +-------------+-------------------------+

      The Hdr Ext Len in the compressed DOH2 is a copy of the same field
   in the original DOH2. The compressed options list field carries the
   compressed value of the options field. Multiple options can be
   included in the options field. Assuming that the number of options in
   the options field in DOH2 is n, the structure of compressed options
   list field is as follows.

                          +------------+------------+-----+------------+
      compressed options: | c_option 1 | c_option 2 | ... | c_option n |
                          +------------+------------+-----+------------+

      The i-th compressed option (c_option i) in the compressed options
   list carries the compressed or uncompressed value of the i-th option
   in the options field in DOH2. The structure of c_option is defined as
   follows.

                +-------------+---+----------------------------------+
      c_option: | Option Type | C | compressed / uncompressed option |
                +-------------+---+----------------------------------+

      * Option Type is the copy of the same field in the uncompressed
   option. Four destination options - Binding Update (BU), Binding
   Acknowledgement (BA), Binding Request (BR) and Home Address (HA) have
   been defined in mobile IPv6.

      * C bit = "0" indicates the all the fields in the option except
   the Option Type are sent, while C bit = "1" indicates the compressed
   option is followed. The decision of sending compressed option or
   uncompressed option as well as the format of the compressed option
   for BU, BA, BR and HA are defined in the following subsections. For
   any other unknown type of options, the uncompressed value is always
   sent.

      Since each of the aforementioned four options follows a certain
   pattern individually, but is not sent in every packet, an individual
   context for each type of option should be established and maintained
   by the compressor and the decompressor. The linkage between these
   individual contexts and the context maintained for IP base header and
   the UDP/RTP header could be the RTP sequence number. In addition, an
   individual compression state is maintained for each option. Unlike



Bormann (ed.)                                                  [Page 83]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   the compression states used for IP base header and RTP/UDP headers,
   only two compression states are defined for these four options -
   original state and compressed state. In the original state, the
   original value of the option is sent, while in the compressed state,
   the compressed value of the option is sent.

   1.2.2.5.1.  Home Address Option (HA) and Binding Request Option (BR)

      At the beginning, the compressor stays in the original state and
   sends uncompressed HAs. When the decompressor receives an
   uncompressed HA, it restores the static fields, i.e., the option Type
   field and the Home Address field, and then acknowledges the received
   packet. After receiving an acknowledgement for the packet that
   carries the HA, the compressor switches to the compressed state for
   HA. When the decompressor receives a compressed HA, it retrieves the
   static fields from storage. The sub-option field (if present) and the
   Option Len field can be obtained from the compressed HA.

      The structure of compressed HA is defined as follows.

                     +---+::::::::::::+::::::::::::+
      compressed HA: | S | Option Len | sub-option |
                     +---+::::::::::::+::::::::::::+

      S bit indicates whether or not sub-option is present. If it is
   present, both the Option Len and sub-option fields should be sent
   uncompressed and the S bit is set to "1". Otherwise, S bit is set to
   "0" and no other fields needs to be sent in the compressed HA. In the
   second case, the decompressor regenerates the Option Len field as 16.

      BR option can also be sent compressed or uncompressed. The
   compression scheme for BR option is similar to that of HA option.
   The structure of compressed BR is the same as the structure of
   compressed HA. The only difference is in the case that the sub-option
   field is not present, the decompressor assigns 0 to the Option Len
   field.

   1.2.2.5.2. Binding Update Option (BU) and Binding Acknowledgement
   Option (BA)

      BU and BA options are not sent in every packet. For example, BU
   option is only sent when the mobile node changes its care-of address
   or it observes that its entry in the binding cache at the
   correspondent node doesn't exist or may expire soon. Since these
   options are not sent frequently, to keep a simple compression and
   decompression logic, these options can be sent uncompressed whenever
   they are present.

      However, to obtain higher compression efficiency, these options
   can be sent compressed at the price of more complicated logic and a
   higher memory requirement.



Bormann (ed.)                                                  [Page 84]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



      To compress the current BU option, a BU that was sent previously
   and has been acknowledged by the decompressor is used as the
   reference.  Since the BU option is not sent in every packet, the
   reference header used to compress the base IPv6 header and the
   UDP/RTP header may not be able to be used as the reference for BU
   option because it may not contain a BU option. Therefore, a separate
   reference needs to be maintained for BU option.

      The reference for BU can be selected based on the acknowledgement.
   When the decompressor receives a packet containing BU, it inserts the
   BU into the sliding window (refer to [ACE]) in the individual BU
   context, and acknowledges the packet. After the compressor receives
   the acknowledgement, it updates the reference to be used for BU.

      When the BU is present in the packet the next time, the new
   reference is used to compress the BU. To identify the reference BU,
   an identifier for BU (BU_ref_id) is needed. The sequence number field
   in BU option increments (not necessary strictly by 1) from packet to
   packet and can be used as the BU_ref_id. The BU_ref_id is carried in
   the compressed BU header.

      When the decompressor receives a compressed BU header, it
   retrieves the reference BU from the sliding window and use it to
   decompress the BU option. The decompressor also shrinks the sliding
   window by removing all the BUs before the reference BU.

      The structure of the compressed BU is as follows.

                     +-----------+---------------+-------------+--------
   -+
      compressed BU: | BU_ref_id | A | H | R | D | L | PL | LT | SP | SC
   |
                     +-----------+---------------+-------------+--------
   -+

      :::::::::::::::+:::::::::::::::+----------------------------+
       Option Length | Prefix Length | Compressed Sequence Number |
      :::::::::::::::+:::::::::::::::+----------------------------+

      :::::::::::::::::::::+:::::::::::::+
       Compressed Lifetime | Sub-Options |
      :::::::::::::::::::::+:::::::::::::+

      The A, H, R, D bits are copied from the original BU. The
   subsequent bit mask indicates the presence of the field that is
   changed.  The mapping of the bit mask and the subsequent changing
   fields is as follows. A "1" in the bit mask means the correspondent
   field is present.

      - L bit:  Option Length



Bormann (ed.)                                                  [Page 85]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      - PL bit: Prefix Length
      - LT bit: Lifetime

      Among the above three fields, only the Lifetime field can be sent
   compressed if it changes. All the other fields should be sent
   uncompressed. The compression scheme used for Lifetime field is VLE
   as defined in [ACE]. The format of compressed Lifetime is the same as
   the format for compressed Identification in Fragment Header, which is
   defined in 1.2.3.3.

      The SP and SC bits are used for compression of the sub-options
   field.  SP bit indicates the presence of sub-options field. If it is
   present, the SC bit indicates whether or not the sub-options field
   can be sent compressed. If the sub-options field in the current BU is
   not the same as the sub-options field in the reference BU, SC bit is
   set to "0" and the uncompressed value of the sub-options field is
   sent. Otherwise, SC bit is set to "1" and sub-options field is not
   sent.

      The sequence number in the BU should be sent all the time. Its
   compressed value is carried in the compressed sequence number field.
   The compression scheme for sequence number is VLE, as defined in
   [ACE].  The format of the compressed sequence number is as follow.

      - "0" + 4-bit LSB
      - "10" + 8-bit LSB
      - "11" + 16-bit LSB

      The compression scheme for BA option is exactly the same as the
   scheme defined for BU option. The format for the compressed BA is as
   follows.

                     +-----------+-----------------+---------+
      compressed BA: | BA_ref_id | L | ST | LT | R | SP | SC |
                     +-----------+-----------------+---------+

      :::::::::::::::+::::::::+----------------------------+
       Option Length | Status | Compressed Sequence Number |
      :::::::::::::::+::::::::+----------------------------+

      :::::::::::::::::::::+::::::::::::::::::::+:::::::::::::+
       Compressed Lifetime | Compressed Refresh | Sub-Options |
      :::::::::::::::::::::+::::::::::::::::::::+:::::::::::::+

      BU_ref_id is used to identify the reference BA. The sequence
   number field in BA option increments (not necessary strictly by 1)
   from packet to packet and can be used as the BA_ref_id.

      The mapping of the bit mask and the subsequent changing fields is
   as follows.




Bormann (ed.)                                                  [Page 86]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      - L bit:  Option Length
      - S bit:  Status
      - LT bit: Lifetime
      - R bit:  Refresh

      Among the above four fields, Lifetime and Refresh fields can be
   sent compressed if they change. The other two fields should be sent
   uncompressed. The compression scheme used for Lifetime field or
   Refresh field is VLE as defined in [ACE]. The format for compressed
   Lifetime and compressed Refresh is the same as the format for
   compressed Identification in Fragment Header, which is defined in
   1.2.3.3.

      The sequence number in BA has the same behavior as the sequence
   number in the BU, thus, it is compressed in the same manner.


7.2.  Efficient compression of CSRC lists

   The Contributing Source (CSRC) List in a RTP header contains the
   Synchronization Source (SSRC) identifiers of the contributing sources
   for the payload in current packet.

   A CSRC list contains at most 15 identifiers, due to the 4-bit size of
   CSRC Count (CC) field in RTP header.  Each 32-bit identifier is
   chosen randomly by the original synchronization source so that it is
   globally unique within an RTP session.

   The compression scheme introduced here will utilize the facts
   mentioned above. To maintain transparency, the order of identifiers
   is preserved during compression. In other words, the CSRC list is
   really compressed as a list, not as a set.


7.2.1.  Data Structure and Algorithm

   The scheme is essentially reference based compression. (Refer to
   Appendix COMPLIST for general discussion on list compression). The
   reference CSRC list (ref_CSRC) could be the CSRC list in the last
   acknowledged RTP header.

   Four encoding formats are provided in this scheme, which are
   differentiated by the Encoding Type (ET) value. The compressor will
   choose the most efficient one based on the change from the ref_CSRC
   to the current CSRC list (cur_CSRC).


7.2.2.  Generic






Bormann (ed.)                                                  [Page 87]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   This format can handle any change from the ref_CSRC to the cur_CSRC.
   However, it should be used only if the change cannot be handled
   efficiently by the formats described in the following sections.

   Below is the format of a compressed CSRC list (comp_CSRC). Note that
   the ref_CSRC is identified by the RTP SN of the RTP header in which
   it was carried.

   +---------+--------+--------+----------+------+----------+
   | ET = 00 | ref_SN | cur_CC | c_item 1 | .... | c_item n |
   +---------+--------+--------+----------+------+----------+

   ET:      2 bits
   ref_SN:  could be uncompressed (16 bits), or compressed (a few LSBs),
            depending on the ROHC compression of RTP SN
   cur_CC:  4 bits, the number of c_items


   Each c_item above has one of the following structures:

   a)
         +---+-----+
         | 0 | pos |
         +---+-----+

   This indicates that an SSRC at position pos in the ref_CSRC is also
   present in cur_CSRC. Note the length of the pos field needs not to be
   sent explicitly, since it can be determined by both compressor and
   decompressor as ceil(log2(k)), where k is the number of SSRCs in the
   ref_CSRC.

   b)

         +---+------+
         | 1 | SSRC |
         +---+------+

   This indicates a new SSRC is present in current CSRC list. Note the
   new SSRC itself is not compressed due to its random nature.

   After receiving a comp_CSRC, the decompressor 1) fetches the ref_CSRC
   from its context, 2) scans the c_item list in the received comp_CSRC
   and builds the cur_CSRC item by item, and 3) copies the value of
   cur_CC into the CC field in the decompressed RTP header.


7.2.3.  Insertion Only

   If the change from the ref_CSRC to cur_CSRC only involves addition of
   new SSRCs (i.e., no order change, no deletion), a more efficient
   format can be used.



Bormann (ed.)                                                  [Page 88]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



   For example, this format is efficient in handling the event that a
   new party or parties join speaker becomes active in a conference
   call.

   +---------+--------+--------+-------+-----+-------+
   | ET = 01 | ref_SN | add_CC | pos 1 | ... | pos n |
   +---------+--------+--------+-------+-----+-------+

   --------+-----+--------+
    SSRC 1 | ... | SSRC n |
   --------+-----+--------+

   ET:      2 bits
   ref_SN:  same as in generic format
   add_CC:  4 bits, the number of new SSRCs present in this comp_CSRC.

   After receiving a comp_CSRC with ET = 01, the decompressor will
   insert the new SSRC_i right before position pos_i in the ref_CSRC.

   Note that the length of pos fields is now equal to ceil(log2(k+1)),
   where k is the number of SSRCs in the ref_CSRC. The extra one is
   needed since the insertion could happen at both the head and the tail
   of the list.


7.2.4.  Deletion Only

   This format is optimized for the case that the change from ref_CSRC
   to the cur_CSRC only involves removal of some SSRC(s) in the
   ref_CSRC. For example, it can be used when a party or parties leave a
   conference call.

   +---------+--------+--------+-------+-----+-------+
   | ET = 10 | ref_SN | del_CC | pos 1 | ... | pos m |
   +---------+--------+--------+-------+-----+-------+

   ET:      2 bits
   ref_SN:  same as in generic format
   del_CC:  the number of SSRCs should be deleted from ref_CSRC.
            length = log2(k), where k is the number of SSRCs in
            the ref_CSRC.

   After receiving such a comp_CSRC, the decompressor will fetch the
   ref_CSRC, then remove each SSRC whose position is listed in the
   comp_CSRC.

   The length of pos fields are determined in the same way as the
   generic format.





Bormann (ed.)                                                  [Page 89]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


7.2.5.  Insertion and Deletion Only

   The following format can handle the case where both insertion and
   deletion of SSRCs happen, but there is no order change.  Note that
   the generic format could be more efficient if the change is
   significant compared with the size of cur_CSRC, and thus should be
   used instead.

   +---------+--------+--------+-------+-----+-------+
   | ET = 11 | ref_SN | del_CC | pos 1 | ... | pos m |
   +---------+--------+--------+-------+-----+-------+

   ---------+-------+-----+-------+--------+-----+--------+
    add_CC  | pos 1 | ... | pos n | SSRC 1 | ... | SSRC n |
   ---------+-------+-----+-------+--------+-----+--------+

   ET:      2 bits
   ref_SN:  same as in generic format
   del_CC:  same as in the deletion only fomrat
   add_CC:  4 bits, the number of new SSRCs

   This case can be considered as two combined transformations. First,
   deletion (section X.2.3) is applied to ref_CSRC as identified by the
   ref_SN. Let's call the resulted CSRC list mid_CSRC. Then, insertion
   (section X.2.2) is applied to mid_CSRC. Therefore, each pos in the
   deletion part refers a position in ref_CSRC, while each pos in the
   insertion part indexes into the mid_CSRC.



7.3.  Tunneling

7.3.1.  Header Compression for IPv4 Tunneling Header

      In order to route the packets to the mobile node that is on a
   foreign link, the home agent of the mobile node may encapsulate the
   original packet into an IP header and tunnel the packet to the care-
   of address of the mobile node. In the case of foreign agent care-of
   address in Mobile IPv4, the tunneling header in each tunneled packet
   will be removed by the foreign agent before transferring it to the
   mobile node through the air interface; therefore there is no need for
   compression of tunneling header.  In the case that mobile node uses
   collocated care-of address, the tunneled packet will be sent to
   mobile station through air interface, and compression needs to be
   applied to the tunneling header.

7.3.1.1.  Mobile IPv4 Tunneling Header Fields Type

      The table below summarizes classification of the various fields
   defined in different tunneling headers used in Mobile IPv4. In the
   column of Encapsulation Scheme (Enc. Scheme), three encapsulation



Bormann (ed.)                                                  [Page 90]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   methods are included - IP in IP Encapsulation (IIE), Minimum
   Encapsulation (ME), Generic Routing Encapsulation (GRE).

   (Editor's note: Harmonize with the way this is described in ROHC
   document)

      +------+------+---------+---------------------------------+
      |Enc.  |Header| Static  |          Non-static             |
      |Scheme|type  |         +-----------+---------------------+
      |      |      |         | Essential |    Non-Essential    |
      +------+------+---------+-----------+---------------------+
      | IIE  |inner |   same as in the table in Appendix A      |
      |      |header|          in ACE Internet Draft            |
      |      +------+-------------------------------------------+
      |      |outer |   same as in the table in Appendix A      |
      |      |header|          in ACE Internet Draft            |
      +------+------+-------------------------------------------+
      | ME   |IP    |   same as in the table in Appendix A      |
      |      |header|          in ACE Internet Draft            |
      |      +------+----------+----------+---------------------+
      |      |Mini. | Protocol |          | S bit               |
      |      |Fw.   |          |          | Header Checksum     |
      |      |header|          |          | Original Dest. Addr.|
      |      |      |          |          | Original Src. Addr. |
      +------+------+----------+----------+---------------------+
      | GRE  |inner |   same as in the table in Appendix A      |
      |      |header|          in ACE Internet Draft            |
      |      +------+-------------------------------------------+
      |      |outer |   same as in the table in Appendix A      |
      |      |header|          in ACE Internet Draft            |
      |      +------+----------+----------+---------------------+
      |      |GRE   | Protocol | Sequence | C, R, K, S, s bits  |
      |      |header| Ver      | number   | Recur               |
      |      |      |          |          | Flags               |
      |      |      |          |          | Checksum            |
      |      |      |          |          | Offset              |
      |      |      |          |          | Key                 |
      |      |      |          |          | Routing             |
      +------+------+----------+----------+---------------------+

7.3.1.2.  Compression of Tunneling Headers in MIPv4

      Three encapsulation schemes have been specified in MIPv4. For
   different encapsulation scheme, the compression methods are different
   from each other.

7.3.1.2.1.  IP in IP Encapsulation in IPv4

      Using IP in IP Encapsulation, the original inner IP header is not
   modified at all and therefore can be compressed as if it is not




Bormann (ed.)                                                  [Page 91]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   encapsulated. The outer header is compressed at the IP level, while
   the inner header is compressed as defined in ROHC.

7.3.1.2.2.  Minimum Encapsulation in IPv4

      With Minimum Encapsulation, the original IP header is modified and
   the Minimal Forwarding Header is inserted between the modified IP
   header and the original IP payload. The modified IP header plus the
   the UDP/RTP headers is compressed as defined in ROHC.

      The compression scheme for the Minimal Forwarding Header is
   similar to the scheme applied to the IP header. The static and
   changing non- essential fields in the Minimum Forwarding Header are
   sent in the Full Header and Refresh state. When any change happens to
   any non-essential field in the Minimum Forwarding Header, a
   compressed header with a bit mask indicating the change should be
   sent.

7.3.1.2.3.  Generic Routing Encapsulation in IPv4

      With Generic Routing Encapsulation, the original IP packet is
   encapsulated in an outer IP header. A GRE header is inserted between
   the inner header and the outer header. The original IP/UDP/RTP header
   is compressed as if there is no encapsulation. The outer IP header is
   compressed at the IP level.

      The compression scheme for the GRE header is similar to the scheme
   applied to the IP header.  All the static and changing non-essential
   fields in the GRE header are sent in the Full Header and refresh
   state. When any change happens to any non-essential field in the GRE
   header, a compressed header with a bit mask indicating the change
   should be sent. If the sequence number in the GRE header is present,
   the scheme to compress sequence number could be VLE, as defined in
   ACE draft.


7.4.  RTCP


   RTCP is the RTP Control Protocol, [RTP]. RTCP is based on periodic
   transmission of control packets to all participants in a session,
   using the same distribution mechanism as for data packets. Its
   primary function is to provide feedback from the data receivers on
   the quality of the data distribution. The feedback information may be
   used for issues related to congestion control functions, and directly
   useful for control of adaptive encodings.

   In an RTP session there will be two types of packet streams; one with
   the RTP-header and application data, and a second stream with the
   RTCP control information. The difference between the streams at the
   transport level is the UDP port numbers, which is plus one for RTCP.



Bormann (ed.)                                                  [Page 92]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   The question is how should ROHC header compressor handle the RTCP
   stream.

a)   One compressor/decompressor entity for both streams and carried on
  the same channel using CIDs to distinguish between them. Although
  they could share some parts of their contexts. Hence, on the RTCP
  stream IP/UDP compression might be utilized.
b)   One compressor/decompressor entity for both streams and carried on
  the same channel, but without using CIDs to distinguish between them.
  To avoid unnecessary extra overhead a packet type, or some other
  method, can be used to tell that this compressed packet carries RTCP
  data and not RTP.
c)   Two compressor/decompressor entities, one for RTP and another one
  for RTCP, and the streams carried on their own channel. This means
  that they will not share the same CID number space.


7.5.  non-RTP UDP traffic

   (Editor's note: This is text from draft-koren-avt-crtp-enhance-01.txt
   to be added to rohc _ not yet consistent with the rest of the
   document)


   2.1 The negative cache stream flag

   Certain streams, known or suspected to not be RTP, can be placed in a
   "negative cache" at the compressor, so only the IP and UDP headers
   are compressed. It is beneficial to notify the decompressor that the
   compressed stream is in the negative cache: for such streams the
   context is shorter - there is no need to include the RTP header, and
   all RTP-related calculations can be avoided.

   In this enhancement, a new flag bit "N" is added to the FULL_HEADER
   packet that initializes a context at the decompressor.  The bit
   occupied by the new flag was previously always set to zero.  If the N
   flag is set to 1, this indicates that no COMPRESSED_RTP packets will
   be transmitted in this context.  This flag is only an optimization
   and the decompressor may choose to ignore it.

   Format of the FULL_HEADER length fields with the negative cache flag:

   For 8-bit context ID:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1| Generation|      CID      |  First length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0        |N|  seq  |  Second length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N=1: negative cache stream



Bormann (ed.)                                                  [Page 93]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000




   For 16-bit context ID:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1| Generation|   0 |N|  seq  |  First length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N=1: negative cache stream

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              CID              |  Second length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   2.2 Reject a new compressed stream

   In a point to point link the two nodes can agree on the number of
   compressed sessions they are prepared to support for this link. In an
   end-to-end scheme a host may have compressed sessions with many hosts
   and eventually may run out of resources.  When the end-to-end tunnel
   is negotiated, the number of contexts needed may not be predictable.
   This enhancement allows the negotiated number of contexts to be
   larger than could be accommodated if many tunnels are established.
   Then, as context resources are consumed, an attempt to set up a new
   context may be rejected.
   The compressor initiates a compression of a stream by sending a
   FULL_HEADER packet. Currently if the decompressor has insufficient
   resources to decompress the new stream, it can send a CONTEXT_STATE
   packet to invalidate the newly compressed stream. The compressor does
   not know the reason for the invalidation: usually this happens when
   the decompressor gets out of synchronization due to packet loss. The
   compressor will most likely reattempt to compress this stream by
   sending another FULL_HEADER.
   This enhancement specifies that the decompressor may reject the
   compression of a stream by sending a REJECT message to the
   compressor. A REJECT message tells the compressor to stop compressing
   this stream.
   The REJECT message is a CONTEXT_STATE message with an additional
   flag:

      Type code = 1 :CONTEXT_STATE for 8-bit CID streams
      Type code = 2 :  CONTEXT_STATE for16-bit CID streams

   Here is the format of CONTEXT_STATE packets with REJECT flags:

                0   1   2   3   4   5   6   7
              +---+---+---+---+---+---+---+---+
              |Type code=1: CS, 8-bit CID |
              +---+---+---+---+---+---+---+---+
              |         context count         |
              +---+---+---+---+---+---+---+---+



Bormann (ed.)                                                  [Page 94]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


              |       session context ID      |
              +---+---+---+---+---+---+---+---+
              | 1 |R=1| 0 | 0 |    sequence   |   R is the REJECT flag
              +---+---+---+---+---+---+---+---+
              | 0 | 0 |       generation      |
              +---+---+---+---+---+---+---+---+
                            . . .
              +---+---+---+---+---+---+---+---+
              |       session context ID      |
              +---+---+---+---+---+---+---+---+
              | 1 |R=1| 0 | 0 |    sequence   |   R is the REJECT flag
              +---+---+---+---+---+---+---+---+
              | 0 | 0 |       generation      |
              +---+---+---+---+---+---+---+---+




                0   1   2   3   4   5   6   7
              +---+---+---+---+---+---+---+---+
              |Type code=2: CS, 16-bit CID|
              +---+---+---+---+---+---+---+---+
              |         context count         |
              +---+---+---+---+---+---+---+---+
              |                               |
              +       session context ID      +
              |                               |
              +---+---+---+---+---+---+---+---+
              | 1 |R=1| 0 | 0 |    sequence   |   R is the REJECT flag
              +---+---+---+---+---+---+---+---+
              | 0 | 0 |       generation      |
              +---+---+---+---+---+---+---+---+
                            . . .
              +---+---+---+---+---+---+---+---+
              |                               |
              +       session context ID      +
              |                               |
              +---+---+---+---+---+---+---+---+
              | 1 |R=1| 0 | 0 |    sequence   |   R is the REJECT flag
              +---+---+---+---+---+---+---+---+
              | 0 | 0 |       generation      |
              +---+---+---+---+---+---+---+---+

   The session CID, sequence and generation are taken from the
   FULL_HEADER.

   The compressor may decide to wait for a while before attempting to
   compress additional streams destined to the rejecting host.






Bormann (ed.)                                                  [Page 95]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


8.  Implementation status

   (Editor: I don't think we need this section.  We might want an
   _implementation notes_ section at one point.)


9.  Security considerations

   Because encryption eliminates the redundancy that header compression
   schemes try to exploit, there is some inducement to forego encryption
   in order to achieve operation over low-bandwidth links. However, for
   those cases where encryption of data (and not headers) is sufficient,
   RTP does specify an alternative encryption method in which only the
   RTP payload is encrypted and the headers are left in the clear. That
   would still allow header compression to be applied.

   A malfunctioning or malicious header compressor could cause the
   header decompressor to reconstitute packets that do not match the
   original packets but still have valid IP, UDP and RTP headers and
   possibly even valid UDP checksums. Such corruption may be detected
   with end-to-end authentication and integrity mechanisms which will
   not be affected by the compression. Further, this header compression
   scheme provides an internal checksum for verification of re-
   constructed headers. This reduces the probability of producing
   decompressed headers not matching the original ones without this
   being noticed.

   Denial-of-service attacks are possible if an intruder can introduce
   (for example) bogus STATIC, DYNAMIC or FEEDBACK packets onto the link
   and thereby cause compression efficiency to be reduced. However, an
   intruder having the ability to inject arbitrary packets at the link
   layer in this manner raises additional security issues that dwarf
   those related to the use of header compression.

   TBW: Header compression and IPsec


10.  Acknowledgements

   When designing this protocol, earlier header compression ideas
   described in [CJHC], [IPHC] and [CRTP] have been important sources of
   knowledge.

   Thanks to Takeshi Yoshimura at NTT DoCoMo for providing the reverse
   decompression chapter (chapter 6.3). Thanks also to Anton Martensson
   for many valuable draft contributions and to Andreas Jonsson (Lulea
   University), who made a great job supporting this work in his study
   of header field change patterns. Thanks also to all others who have
   given comments.





Bormann (ed.)                                                  [Page 96]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


11.  Intellectual property considerations

   (Editor's note: this section will go to www.ietf.org/ipr and be
   replaced by the standard reference to that, but for now it is left in
   the draft to simplify working on it.)

   This proposal in is conformity with RFC 2026.

   Telefonaktiebolaget LM Ericsson and its subsidiaries, in accordance
   with corporate policy, will for submissions rightfully made by its
   employees which are adopted or recommended as a standard by the IETF
   offer patent licensing as follows:

   If part(s) of a submission by Ericsson employees is (are) included in
   a standard and Ericsson has patents and/or patent application(s) that
   are essential to implementation of such included part(s) in said
   standard, Ericsson is prepared to grant - on the basis of reciprocity
   (grant-back) - a license on such included part(s) on reasonable, non-
   discriminatory terms and conditions.

   For the avoidance of doubt this general patent licensing undertaking
   applies to this proposal.


   Nokia has filed patent applications that might possibly have
   technical relation to this contribution.


   Matsushita has filed patent applications that might possibly have
   technical relation to this contribution.
   If part(s) of the contribution by Matsushita employee is (are)
   included in a standard and Matsushita has patents and/or patent
   application(s) that are essential to implementation of such included
   part(s) in said standard, Matsushita is prepared to grant - on the
   basis of reciprocity (grantback) - a license on such included part(s)
   on reasonable, non-discriminatory terms and conditions (in according
   with paragraph 10.3.3 of the RFC 2026).

















Bormann (ed.)                                                  [Page 97]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   12.  References

   [UDP]    Jon Postel, "User Datagram Protocol", RFC 768, August 1980.

   [IPv4]   Jon Postel, "Internet Protocol", RFC 791, September 1981.

   [IPv6]   Steven Deering, Robert Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.

   [RTP]    Henning Schulzrinne, Stephen Casner, Ron Frederick, Van
            Jacobson, "RTP: A Transport Protocol for Real-Time
            Applications", RFC 1889, January 1996.

   [HDLC]   William Simpson, "PPP in HDLC-like framing", RFC 1662, 1994.

   [VJHC]   Van Jacobson, "Compressing TCP/IP Headers for Low-Speed
            Serial Links", RFC 1144, February 1990.

   [IPHC]   Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header
            Compression", RFC 2507, February 1999.

   [CRTP]   Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP Headers
            for Low-Speed Serial Links", RFC 2508, February 1999.

   [PPPHC]  Mathias Engan, Steven Casner, Carsten Bormann, "IP Header
            Compression over PPP", RFC 2509, February 1999.

   [CRTPC]  Mikael Degermark, Hans Hannu, Lars-Erik Jonsson, Krister
            Svanbro, "CRTP over cellular radio links", Internet Draft
            (work in progress), December 1999.
            <draft-degermark-crtp-cellular-01.txt>

   [REQ]   Mikael Degermark, "Requirements for robust IP/UDP/RTP header
           compression", Internet Draft (work in progress), June 2000.
           <draft-ietf-rohc-rtp-requirements-01.txt>

   [LLG]   Krister Svanbro, "Lower Layer Guidelines for Robust Header
           Compression", Internet Draft (work in progress), May 2000.
           <draft-ietf-rohc-lower-layer-guidelines-00.txt>

   [CELL]   Lars Westberg, Morgan Lindqvist, "Realtime traffic over
            cellular access networks", Internet Draft
           (work in progress), May 2000.
            <draft-westberg-realtime-cellular-02.txt>

   [WCDMA] "Universal Mobile Telecommunications System (UMTS);
           Selection procedures for the choice of radio transmission
           technologies of the UMTS (UMTS 30.03 version 3.1.0)".
           ETSI TR 101 112 V3.0.1, November 1997.





Bormann (ed.)                                                  [Page 98]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


13.  Authors' addresses

   Carsten Bormann               Tel: +
                                 Fax: +
                                 EMail:

   Lars-Erik Jonsson             Tel: +46 920 20 21 07
   Ericsson Erisoft AB           Fax: +46 920 20 20 99
   SE-971 28 Lulea, Sweden       EMail: lars-erik.jonsson@ericsson.com


   other authors....










































Bormann (ed.)                                                  [Page 99]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


Appendix A.  Detailed classification of header fields

   Header compression is possible due to the fact that most header
   fields do not vary randomly from packet to packet. Many of the fields
   exhibit static behavior or changes in a more or less predictable way.
   When designing a header compression scheme, it is of fundamental
   importance to understand the behavior of the fields in detail.

   In this appendix, all IP, UDP and RTP header fields are classified
   and analyzed in two steps. First, we have a general classification in
   A.1 where the fields are classified based on stable knowledge and
   assumptions. The general classification does not take into account
   the change characteristics of changing fields because those will vary
   more or less depending on the implementation and on the application
   used. A less stable but more detailed analysis considering the change
   characteristics is then done in A.2. Finally, A.3 summarizes this
   appendix with conclusions about how the various header fields should
   be handled by the header compression scheme to optimize compression
   and functionality.

A.1.  General classification

   On a general level, the header fields are separated into 5 classes:

   INFERRED       These fields contain values that can be inferred from
                  other values, for example the size of the frame
                  carrying the packet, and thus does not have to be
                  handled at all by the compression scheme.

   STATIC         These fields are expected to be constant throughout
                  the lifetime of the packet stream. Static information
                  must in some way be communicated once.

   STATIC-DEF     STATIC fields whose values define a packet stream.
                  They are in general handled as STATIC.

   STATIC-KNOWN   These STATIC fields are expected to have well-known
                  values and therefore do not need to be communicated
                  at all.

   CHANGING       These fields are expected to vary in some way, either
                  randomly, within a limited value set or range, or in
                  some other manner.


   In this section, each of the IP, UDP and RTP header fields is
   assigned to one of these classes. For all fields except those
   classified as CHANGING, the motives for the classification are also
   stated. CHANGING fields are in A.2 further examined and classified
   based on their expected change behavior.




Bormann (ed.)                                                 [Page 100]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


A.1.1.  IPv6 header fields

    +---------------------+-------------+----------------+
    | Field               | Size (bits) |    Class       |
    +---------------------+-------------+----------------+
    | Version             |      4      |  STATIC-KNOWN  |
    | Traffic Class       |      8      |    CHANGING    |
    | Flow Label          |     20      |   STATIC-DEF   |
    | Payload Length      |     16      |    INFERRED    |
    | Next Header         |      8      |  STATIC-KNOWN  |
    | Hop Limit           |      8      |    CHANGING    |
    | Source Address      |    128      |   STATIC-DEF   |
    | Destination Address |    128      |   STATIC-DEF   |
    +---------------------+-------------+----------------+


   Version

     The version field states which IP version the packet is based on.
     Packets with different values in this field must be handled by
     different IP stacks. For header compression, different compression
     profiles must also be used. When compressor and decompressor have
     negotiated which profile to use, the IP version is also known to
     both parties. The field is therefore classified as STATIC-KNOWN.


   Flow Label

     This field may be used to identify packets belonging to a specific
     packet stream. If not used, the value should be set to zero.
     Otherwise, all packets belonging to the same stream must have the
     same value in this field, it being one of the fields defining the
     stream. The field is therefore classified as STATIC-DEF.


   Payload Length

     Information about the packet length (and then also payload length)
     is expected to be provided by the link layer. The field is
     therefore classified as INFERRED.


   Next Header

     This field is expected to have the same value in all packets of a
     packet stream. As for the version number, a certain compression
     profile can only handle a specific next header which means that
     this value is known when profile has been negotiated. The field is
     therefore classified as STATIC-KNOWN.





Bormann (ed.)                                                 [Page 101]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   Source and Destination addresses

     These fields are part of the definition of a stream and must thus
     be constant for all packets in the stream. The fields are therefore
     classified as STATIC-DEF.


   Summarizing the bits corresponding to the classes gives:

    +--------------+--------------+
    | Class        | Size (octets)|
    +--------------+--------------+
    | INFERRED     |       2      |
    | STATIC-DEF   |     34.5     |
    | STATIC-KNOWN |      1.5     |
    | CHANGING     |       2      |
    +--------------+--------------+





































Bormann (ed.)                                                 [Page 102]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


A.1.2.  IPv4 header fields

    +---------------------+-------------+----------------+
    | Field               | Size (bits) |     Class      |
    +---------------------+-------------+----------------+
    | Version             |      4      |  STATIC-KNOWN  |
    | Header Length       |      4      |  STATIC-KNOWN  |
    | Type Of Service     |      8      |    CHANGING    |
    | Packet Length       |     16      |    INFERRED    |
    | Identification      |     16      |    CHANGING    |
    | Reserved flag       |      1      |  STATIC-KNOWN  |
    | May Fragment flag   |      1      |     STATIC     |
    | Last Fragment flag  |      1      |  STATIC-KNOWN  |
    | Fragment Offset     |     13      |  STATIC-KNOWN  |
    | Time To Live        |      8      |    CHANGING    |
    | Protocol            |      8      |  STATIC-KNOWN  |
    | Header Checksum     |     16      |    INFERRED    |
    | Source Address      |     32      |   STATIC-DEF   |
    | Destination Address |     32      |   STATIC-DEF   |
    +---------------------+-------------+----------------+


   Version

     The version field states which IP version the packet is based on
     and packets with different values in this field must be handled by
     different IP stacks. For header compression, different compression
     profiles must also be used. When compressor and decompressor has
     negotiated which profile to use, the IP version is also well known
     to both parties. The field is therefore classified as STATIC-KNOWN.


   Header Length

     As long as there are no options present in the IP header, the
     header length is constant and well known. If there are options, the
     fields would be STATIC, but we assume no options. The field is
     therefore classified as STATIC-KNOWN.


   Packet Length

     Information about the packet length is expected to be provided by
     the link layer. The field is therefore classified as INFERRED.


   Flags

     The Reserved flag must be set to zero and is therefore classified
     as STATIC-KNOWN. The May Fragment flag will be constant for all
     packets in a stream and is therefore classified as STATIC. Finally,



Bormann (ed.)                                                 [Page 103]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


     the Last Fragment bit is expected to be zero because fragmentation
     is NOT expected, due to the small packet size expected. The Last
     Fragment bit is therefore classified as STATIC-KNOWN.


   Fragment Offset

     With the assumption that no fragmentation occurs, the fragment
     offset is always zero. The field is therefore classified as STATIC-
     KNOWN.


   Protocol

     This field is expected to have the same value in all packets of a
     packet stream. As for the version number, a certain compression
     profile can only handle a specific next header which means that
     this value is well known when profile has been negotiated. The
     field is therefore classified as STATIC-KNOWN.


   Header Checksum

     The header checksum protects individual hops from processing a
     corrupted header. When almost all IP header information is
     compressed away, there is no need to have this additional checksum;
     instead it can be regenerate at the decompressor side. The field is
     therefore classified as INFERRED.


   Source and Destination addresses

     These fields are part of the definition of a stream and must thus
     be constant for all packets in the stream. The fields are therefore
     classified as STATIC-DEF.


   Summarizing the bits corresponding to the classes gives:

    +--------------+--------------+
    | Class        | Size (octets)|
    +--------------+--------------+
    | INFERRED     |      4       |
    | STATIC       |    1 bit     |
    | STATIC-DEF   |      8       |
    | STATIC-KNOWN |   3 +7 bits  |
    | CHANGING     |      4       |
    +--------------+--------------+






Bormann (ed.)                                                 [Page 104]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


A.1.3.  UDP header fields

    +------------------+-------------+-------------+
    | Field            | Size (bits) |    Class    |
    +------------------+-------------+-------------+
    | Source Port      |     16      | STATIC-DEF  |
    | Destination Port |     16      | STATIC-DEF  |
    | Length           |     16      |  INFERRED   |
    | Checksum         |     16      |  CHANGING   |
    +------------------+-------------+-------------+


   Source and Destination ports

     These fields are part of the definition of a stream and must thus
     be constant for all packets in the stream. The fields are therefore
     classified as STATIC-DEF.


   Length

     This field is redundant and is therefore classified as INFERRED.


   Summarizing the bits corresponding to the classes gives:

    +------------+--------------+
    | Class      | Size (octets)|
    +------------+--------------+
    | INFERRED   |       2      |
    | STATIC-DEF |       4      |
    | CHANGING   |       2      |
    +------------+--------------+





















Bormann (ed.)                                                 [Page 105]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


A.1.4.  RTP header fields

    +-----------------+-------------+----------------+
    | Field           | Size (bits) |     Class      |
    +-----------------+-------------+----------------+
    | Version         |      2      |  STATIC-KNOWN  |
    | Padding         |      1      |     STATIC     |
    | Extension       |      1      |     STATIC     |
    | CSRC Counter    |      4      |    CHANGING    |
    | Marker          |      1      |    CHANGING    |
    | Payload Type    |      7      |    CHANGING    |
    | Sequence Number |     16      |    CHANGING    |
    | Timestamp       |     32      |    CHANGING    |
    | SSRC            |     32      |   STATIC-DEF   |
    | CSRC            |   0(-480)   |    CHANGING    |
    +-----------------+-------------+----------------+


   Version

     There exists only one working RTP version and that is version 2.
     The field is therefore classified as STATIC-KNOWN.


   Padding

     The use of this field depends on the application, but when payload
     padding is used it is likely to be present in all packets. The
     field is therefore classified as STATIC.


   Extension

     If RTP extensions is used by the application, it is likely to be an
     extension present in all packets (but use of extensions is very
     uncommon). However, for safety's sake this field is classified as
     STATIC and not STATIC-KNOWN.


   SSRC

     This field is part of the definition of a stream and must thus be
     constant for all packets in the stream. The field is therefore
     classified as STATIC-DEF.










Bormann (ed.)                                                 [Page 106]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   Summarizing the bits corresponding to the classes gives:

    +--------------+--------------+
    | Class        | Size (octets)|
    +--------------+--------------+
    | STATIC       |    2 bits    |
    | STATIC-DEF   |      4       |
    | STATIC-KNOWN |    2 bits    |
    | CHANGING     |  7.5(-67.5)  |
    +--------------+--------------+


A.1.5.  Summary for IP/UDP/RTP

   If we summarize this for IP/UDP/RTP we get:

    +----------------+--------------+--------------+
    | Class \ IP ver | IPv6 (octets)| IPv4 (octets)|
    +----------------+--------------+--------------+
    | INFERRED       |       4      |       6      |
    | STATIC         |    2 bits    |    3 bits    |
    | STATIC-DEF     |     42.5     |      16      |
    | STATIC-KNOWN   |   1 +6 bits  |   4 +1 bit   |
    | CHANGING       |  11.5(-71.5) |  13.5(-73.5) |
    +----------------+--------------+--------------+
    | Total          |   60(-120)   |   40(-100)   |
    +----------------+--------------+--------------+



























Bormann (ed.)                                                 [Page 107]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


A.2.  Analysis of change patterns of header fields

   To design suitable mechanisms for efficient compression of all header
   fields, their change patterns must be analyzed. For this reason, an
   extended classification is done based on the general classification
   in A.1, considering the fields which were labeled CHANGING in that
   classification. Different applications will use the fields in
   different ways, which may affect their behavior. When this is the
   case, typical behavior for conversational audio and video will be
   discussed.

   The CHANGING fields are separated into five different subclasses:

   STATIC                These are fields that were classified as
                         CHANGING on a general basis, but are classified
                         as STATIC here due to certain additional
                         assumptions.

   SEMISTATIC            These fields are STATIC most of the time.
                         However, occasionally the value changes but
                         reverts to its original value after a known
                         number of packets.

   RARELY-CHANGING (RC)  These are fields that change their values
                         occasionally and then keep their new values.

   ALTERNATING           These fields alternate between a small number
                         of different values.

   IRREGULAR             These, finally, are the fields for which no
                         useful change pattern can be identified.

   To further expand the classification possibilities without increasing
   complexity, the classification can be done either according to the
   values of the field and/or according to the values of the deltas for
   the field.

   When the classification is done, other details are also stated
   regarding possible additional knowledge about the field values and/or
   field deltas, according to the classification. For fields classified
   as STATIC or SEMISTATIC, the case could be that the value of the
   field is not only STATIC but also well KNOWN a priori (two states for
   SEMISTATIC fields). For fields with non-irregular change behavior, it
   could be known that changes usually are within a LIMITED range
   compared to the maximal change for the field. For other fields, the
   values are completely UNKNOWN.

   Table A.1 classifies all the CHANGING fields based on their expected
   change patterns, especially for conversational audio and video.





Bormann (ed.)                                                 [Page 108]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



    +------------------------+-------------+-------------+-------------+
    |         Field          | Value/Delta |    Class    |  Knowledge  |
    +========================+=============+=============+=============+
    |             Sequential |    Delta    |    STATIC   |    KNOWN    |
    |             -----------+-------------+-------------+-------------+
    | IPv4 Id:    Seq. jump  |    Delta    |      RC     |   LIMITED   |
    |             -----------+-------------+-------------+-------------+
    |             Random     |    Value    |  IRREGULAR  |   UNKNOWN   |
    +------------------------+-------------+-------------+-------------+
    | IP TOS / Tr. Class     |    Value    |      RC     |   UNKNOWN   |
    +------------------------+-------------+-------------+-------------+
    | IP TTL / Hop Limit     |    Value    | ALTERNATING |   LIMITED   |
    +------------------------+-------------+-------------+-------------+
    |               Disabled |    Value    |    STATIC   |    KNOWN    |
    | UDP Checksum: ---------+-------------+-------------+-------------+
    |               Enabled  |    Value    |  IRREGULAR  |   UNKNOWN   |
    +------------------------+-------------+-------------+-------------+
    |                 No mix |    Value    |    STATIC   |    KNOWN    |
    | RTP CSRC Count: -------+-------------+-------------+-------------+
    |                 Mixed  |    Value    |      RC     |   LIMITED   |
    +------------------------+-------------+-------------+-------------+
    | RTP Marker             |    Value    |  SEMISTATIC | KNOWN/KNOWN |
    +------------------------+-------------+-------------+-------------+
    | RTP Payload Type       |    Value    |      RC     |   UNKNOWN   |
    +------------------------+-------------+-------------+-------------+
    | RTP Sequence Number    |    Delta    |    STATIC   |    KNOWN    |
    +------------------------+-------------+-------------+-------------+
    | RTP Timestamp          |    Delta    |      RC     |   LIMITED   |
    +------------------------+-------------+-------------+-------------+
    |                 No mix |      -      |      -      |      -      |
    | RTP CSRC List:  -------+-------------+-------------+-------------+
    |                 Mixed  |    Value    |      RC     |   UNKNOWN   |
    +------------------------+-------------+-------------+-------------+

           Table A.1 : Classification of CHANGING header fields

   The following subsections discuss the various header fields in
   detail. Note that table A.1 and the discussions below do not consider
   changes caused by loss or reordering before the compression point.














Bormann (ed.)                                                 [Page 109]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


A.2.1.  IPv4 Identification

   The Identification field (IP ID) of the IPv4 header is there to
   identify which fragments constitute a datagram when reassembling
   fragmented datagrams. The IPv4 specification does not specify exactly
   how this field is to be assigned values, only that each packet should
   get an IP ID that is unique for the source-destination pair and
   protocol for the time the datagram (or any of its fragments) could be
   alive in the network. This means that assignment of IP ID values can
   be done in various ways, which we have separated into three classes.

   Sequential

      This assignment policy keeps a separate counter for each outgoing
      packet stream and thus the IP ID value will increment by one for
      each packet in the stream. Therefore, the delta value of the
      field is constant and well known a priori. When RTP is used on
      top of UDP and IP, the IP ID value follows the RTP sequence
      number. This assignment policy is the most desirable for header
      compression purposes but its usage is not as common as it should
      be. The reason is that it can be realized only if UDP and IP are
      implemented together so that UDP, which separates packet streams
      by the port identification, can make IP use separate ID counters
      for each packet stream.

   Sequential jump

      This is the most common assignment policy in today's IP stacks.
      The difference from the sequential method is that only one
      counter is used for all connections. When the sender is running
      more than one packet stream simultaneously, the IP ID can
      increase by more than one. The IP ID values will be much more
      predictable and require less bits to transfer than random values,
      and the packet-to-packet increment (determined by the number of
      active outgoing packet streams and sending frequencies) will
      usually be limited.

   Random

      Some IP stacks assign IP ID values using a pseudo-random number
      generator. There is thus no correlation between the ID values of
      subsequent datagrams. Therefore there is no way to predict the IP
      ID value for the next datagram. For header compression purposes,
      this means that the IP ID field needs to be sent uncompressed
      with each datagram, resulting in two extra octets of header. IP
      stacks in cellular terminals SHOULD NOT use this IP ID assignment
      policy.

   It should be noted that the ID is an IPv4 mechanism and is therefore
   not needed at all in IPv6 profiles. For IPv4 the ID could be handled
   in three different ways. Firstly, we have the inefficient but



Bormann (ed.)                                                 [Page 110]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   reliable solution where the ID field is sent as-is in all packets,
   increasing the compressed headers with two octets. This is the best
   way to handle the ID field if the sender uses random assignment of
   the ID field. Secondly, there can be solutions with more flexible
   mechanisms requiring less bits for the ID handling as long as
   sequential jump assignment is used. Such solutions will probably
   require even more bits if random assignment is used by the sender.
   Knowledge about the sender's assignment policy could therefore be
   useful when choosing between the two solutions above. Finally, even
   for IPv4, header compression could be designed without any additional
   information for the ID field included in compressed headers. To use
   such schemes, it must be known that the sender makes use of the pure
   sequential assignment policy for the ID field. That might not be
   possible to know, which implies that the applicability of such
   solutions is very uncertain. However, designers of IPv4 stacks for
   cellular terminals SHOULD use the sequential policy.


A.2.2.  IP Traffic-Class / Type-Of-Service

   The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected
   to be constant during the lifetime of a packet stream or to change
   relatively seldom.


A.2.3.  IP Hop-Limit / Time-To-Live

   The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
   constant during the lifetime of a packet stream or to alternate
   between a limited number of values due to route changes.


A.2.4.  UDP Checksum

   The UDP checksum is optional. If disabled, its value is constantly
   zero and could be compressed away. If enabled, its value depends on
   the payload, which for compression purposes is equivalent to it
   changing randomly with every packet.


A.2.5.  RTP CSRC Counter

   This is a counter indicating the number of CSRC items present in the
   CSRC list. This number is expected to be almost constant on a packet-
   to-packet basis and change by small amount. As long as no RTP mixer
   is used, the value of this field is zero.








Bormann (ed.)                                                 [Page 111]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


A.2.6.  RTP Marker

   For audio the marker bit should be set only in the first packet of a
   talkspurt while for video it should be set in the last packet of
   every picture. This means that in both cases the RTP marker is
   classified as SEMISTATIC with well-known values for both states.


A.2.7.  RTP Payload Type

   Changes of the RTP payload type within a packet stream are expected
   to be rare. Applications could adapt to congestion by changing
   payload type and/or frame sizes, but that is not expected to happen
   frequently.


A.2.8.  RTP Sequence Number

   The RTP sequence number will be incremented by one for each packet
   sent.


A.2.9.  RTP Timestamp

   In the audio case:

      As long as there are no pauses in the audio stream, the RTP
      timestamp will be incremented by a constant delta, corresponding
      to the number of samples in the speech frame. It will thus mostly
      follow the RTP sequence number. When there has been a silent
      period and a new talkspurt begins, the timestamp will jump in
      proportion to the length of the silent period. However, the
      increment will probably be within a relatively limited range.

   In the video case:

      The timestamp change between two consecutive packets will either
      be zero or increase by a multiple of a fixed value corresponding
      to the picture clock frequency. The timestamp can also decrease
      by a multiple of the fixed value if B-pictures are used. The
      delta interval, expressed as a multiple of the picture clock
      frequency, is in most cases very limited.


A.2.10.  RTP Contributing Sources (CSRC)

   The participants in a session, which are identified by the CSRC
   fields, are expected to be almost the same on a packet-to-packet
   basis with relatively few additions or removals. As long as RTP
   mixers are not used, no CSRC fields are present at all.




Bormann (ed.)                                                 [Page 112]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


A.3.  Header compression strategies

   This section elaborates on what has been done in previous sections.
   Based in the classifications, recommendations are given on how to
   handle the various fields in the header compression process. Seven
   different actions are possible and these are listed together with the
   fields to which each action applies.


A.3.1.  Do not send at all

   The fields that have well known values a priori do not have to be
   sent at all. These are:

   - IP Version
   - IPv6 Payload Length
   - IPv6 Next Header
   - IPv4 Header Length
   - IPv4 Reserved Flag
   - IPv4 Last Fragment Flag
   - IPv4 Fragment Offset
   - IPv4 Protocol
   - UDP Checksum (if disabled)
   - RTP Version


A.3.2.  Transmit only initially

   The fields that are constant throughout the lifetime of the packet
   stream have to be transmitted and correctly delivered to the
   decompressor only once. These are:

   - IP Source Address
   - IP Destination Address
   - IPv6 Flow Label
   - IPv4 May Fragment Flag
   - UDP Source Port
   - UDP Destination Port
   - RTP Padding Flag
   - RTP Extension Flag
   - RTP SSRC


A.3.3.  Transmit initially, but be prepared to update occasionally

   The fields that are changing only occasionally must be transmitted
   initially but there must also be a way to update these fields with
   new values if they change. These fields are:

   - IPv6 Traffic Class
   - IPv6 Hop Limit



Bormann (ed.)                                                 [Page 113]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   - IPv4 Type Of Service (TOS)
   - IPv4 Time To Live (TTL)
   - RTP CSRC Counter
   - RTP Payload Type
   - RTP CSRC List


A.3.4.  Be prepared to update or send as-is frequently

   For fields that normally are either constant or whose values can be
   deduced from some other field but frequently diverge from that
   behavior, there must be an efficient way to update the field value or
   send it as-is in some packets. Those fields are:

   - IPv4 Identification (if not sequentially assigned)
   - RTP Marker
   - RTP Timestamp


A.3.5.  Guarantee continuous robustness

   Fields that behave like a counter with a fixed delta for ALL packets,
   the only requirement on the transmission encoding is that packet
   losses between compressor and decompressor must be tolerable. If more
   than one such field exists, all these can be communicated together.
   Such fields can also be used to interpret the values for fields
   listed in the previous section. Fields that have this counter
   behavior are:

   - IPv4 Identification (if sequentially assigned)
   - RTP Sequence Number


A.3.6.  Transmit as-is in all packets

   Fields that have completely random values for each packet must be
   included as-is in all compressed headers. Those fields are:

   - IPv4 Identification (if randomly assigned)
   - UDP Checksum (if enabled)


A.3.7.  Establish and be prepared to update delta

   Finally, there is a field that is usually increasing by a fixed delta
   and is correlated to another field. For this field it would make
   sense to make that delta part of the context state. The delta must
   then be possible to initiate and update in the same way as the fields
   listed in A.3.3. The field to which this applies is:

   - RTP Timestamp



Bormann (ed.)                                                 [Page 114]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


Appendix COMPLIST

   Editor's Note: This is too long and not quite in style to be added to
   encoding section.  Also, I believe this is too complicated.

   1.  Compression of Item List

      An Item List specifies a set of items that is order sensitive. A
   generic structure of an item list is as follows.

                 +--------+--------+--------+--------+
      item list: | item 1 | item 2 | ...... | item n |
                 +--------+--------+--------+--------+

      The items on an item list may or may not have the same structure.
   An example of the first case is the CSRC list in the RTP header or
   the Address list in Type 0 IPv6 Routing Header. An example of the
   second case is IPv6 extension headers. Note that an item itself could
   be a list.

      The compression of a current item list (curr_list) is based on a
   reference item list (ref_list) that is previously sent by the
   compressor and received by the decompressor. The difference between
   the curr_list and ref_list is encoded and sent in the compressed
   list. The reference may be chosen by various means. One approach is
   based on acknowledgement, i.e., the compressor chooses the latest
   item list that is acknowledged by the decompressor as the reference.
   The decompressor retrieves the reference item list, based on which
   items are to be decompressed in the new item list. To identify the
   reference used for the compression, a reference identifier (ref_id)
   needs to be carried inside the compressed list. An example of ref_id
   is RTP sequence number.

   1.1.  Item Compression

      A given item in curr_list can be classified as belonging to one of
   the following transformation cases.

      * Transformation Case A: The given item is also in the ref_list,
   and the content of these two items is the same, while the position in
   the list may or may not have changed.

      * Transformation Case B: There is an item in the ref_list with a
   similar structure, but the contents of these two items are not
   identical. The position in the list may or may not be the same.

      * Transformation Case C: The given item in the curr_list is not in
   the ref_list.






Bormann (ed.)                                                 [Page 115]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


        For the given item in curr_list, the compressor determines which
   transformation case applies. Depending on the transformation case,
   the correspondent encoding technique is used.

      1.2.  List Compression

        Seven encoding schemes are defined below. To identify the
   encoding scheme used for the list compression, an encoding type field
   (ET) is included in the compressed list.

      1.2.1.  Generic Scheme

        The generic encoding scheme addresses the case where the items
   belong to a mixture of transformation cases. For example, item 1 in
   curr_list belongs to transformation case B, item 2 belongs to
   transformation case C, while item 3 belongs to transformation case A.

        Using this scheme, the structure of a compressed item list is
   defined as follows.

        compressed list:
        +----------+--------+--------------+----------+------+----------
   +
        | ET = 000 | ref_id | c_item count | c_item 1 | .... | c_item n
   |
        +----------+--------+--------------+----------+------+----------
   +

        * The encoding type (ET) is "000".

        * The ref_id is defined at the beginning of section 1. One
   example is the RTP sequence number.

        * The c_item count specifies the number of c_items in the c_item
   list (c_item 1, ..., c_item n). The length of c_item count is defined
   based on the context of the application.

        * Each c_item (c_item i) corresponds to one of the item (item i)
   in the curr_list; thus the order of the c_items represents the order
   of the items in the curr_list. The structure of c_item is defined as
   follows.

          Each c_item consists of C_item Code (CC) and C_item Data.

                  +-------------+-------------+
          c_item: | c_item code | c_item data |
                  +-------------+-------------+

          For different c_item codes, the content of the c_item data is
   different. Three types of c_item codes and their respective c_item
   data are defined as follow.



Bormann (ed.)                                                 [Page 116]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



          * C_item Code "0" is used for an item classified as belonging
   to transformation case A. The structure of the c_item is as follows.

                    +----------+-----+
            c_item: | CC = "0" | pos |
                    +----------+-----+

            - The "pos" field indicates the position of the item in the
   ref_list.

            Note that "pos" starts from 0, i.e., the position of the
   first item in the list is 0. Since the "pos" field in the c_item data
   field indicates the position of the item in the ref_list, the length
   of "pos" field depends on the actual number of items in the ref_list.
   Assuming that there are 'k' items in the ref_list, then the number of
   bits used for "pos" field is ceiling(log2(k)). Since k is known to
   both the compressor and decompressor, the length of "pos" field
   doesn't need to be carried in the compressed list.

            When the decompressor receives this c_item, it retrieves the
   item at position "pos" in the ref_list, and copies it into the
   curr_list.

          * C_item Code "10" is used for an item classified as belonging
   to transformation case B. The structure of the c_item is as follows.

                    +-----------+-----+::::::::::::::::::::+------------
   -----+
            c_item: | CC = "10" | pos | type-specific data | compressed
   data |
                    +-----------+-----+::::::::::::::::::::+------------
   -----+

            - The "pos" field is defined as above.

            - The "compressed data" field carries compressed value of
   the item in the curr_list, using the item at position "pos" in the
   ref_list as the reference. The compression technique is dependent on
   the item and should be predefined.

            - The optional "type-specific data" field contains
   additional information used to reconstruct the item list. The
   presence and the content of the "type-specific data" depend on the
   item and should be predefined.

            When the decompressor receives this c_item, it retrieves the
   item at the position "pos" in the ref_list and uses it as the
   reference to decompress the "compressed data". If the item itself is
   a list, the compression scheme described here applies to compress the
   item.



Bormann (ed.)                                                 [Page 117]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



          * C_item Code "11" is used for an item classified as belonging
   to transformation case C or transformation case B in the case that
   the length of the compressed value of an item is even larger than the
   length of the uncompressed value due to too many changes. The
   structure of the c_item is as follows.

                    +-----------+::::::::::::::::::::+------------------
   -+
            c_item: | CC = "11" | type-specific data | uncompressed data
   |
                    +-----------+::::::::::::::::::::+------------------
   -+

            - The optional "type-specific data" field is defined as
   above.

            - The "uncompressed data" field contains the original value
   of the item in the curr_list.

            When the decompressor receives this c_item, it copies the
   uncompressed data field into curr_list.

      1.2.2.  Insertion Only Scheme

        This scheme only addresses the case where all the items are
   classified as belonging to either transformation case A or C.  The
   structure of the compressed item list is as follows.

                         +----------+--------+--------------+-----+
        compressed list: | ET = 001 | ref_id | u_item count | aft |
                         +----------+--------+--------------+-----+
        -----------------+----------+----+----------+
         insertion order | u_item 1 |....| u_item m |
        -----------------+----------+----+----------+

        * The encoding type (ET) is "001".

        * The ref_id is defined as before.

        * The u_item count field carries the number of u_items in the
   following u_item list (u_item 1,., u_item m). The length of u_item
   count is defined based on the context of the application.

        * Each u_item carries the uncompressed value of the new item in
   the curr_list when comparing it with the ref_list.

                  +-------------------+
          u_item: | uncompressed data |
                  +-------------------+




Bormann (ed.)                                                 [Page 118]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


        * The aft field specifies the format used in insertion order
   field.
          0 - bit mask format
          1 - position list format

        * The insertion order field specifies the positions of the
   inserted items. Two formats can be used.

        **  Bit Mask Format: In this format, a bit mask is include.

            To construct the bit mask and the u_item list, the following
   steps are taken.

            *** A list of '0' and an empty u_item list are generated as
   the starting point. The number of '0's in the '0' list equals the
   number of items in the ref_list. The position of each '0' in the '0'
   list corresponds to the position of an item in the ref_list, i.e.,
   the i-th '0' in the '0' list corresponds to the i-th item in the
   ref_list.

            *** Comparing the curr_list with the ref_list, if a new item
   is inserted between the i-th item and the (i+1)-th item in the
   ref_list, a '1' is inserted between the i-th '0' and (i+1)-th '0' in
   the original '0' list. The u_item that carries the new item should be
   added to the end of u_item list. This procedure is repeated until all
   the added items have been processed.

            Assuming the number of items in the ref_list is k, and the
   number of new items is m, then the length of the bit mask is k+m.
   Since k is known to both the compressor and decompressor, and m is
   carried in "u_item count" field, the length of the bit mask can be
   obtained by the compressor and decompressor and doesn't need to be
   carried in the compressed item list.

            When the decompressor receives the bit mask, it scans from
   left to right. When a '0' is observed, the decompressor copies the
   corresponding item in the ref_list into the curr_list; when an '1' is
   observed, the decompressor adds the correspondent u_item into the
   curr_list.

        ** Position List Format: In this format, a list of position
   fields is carried. The structure of this format is as follows.

                           +-------+----+-------+
            position list: | pos 1 |....| pos m |
                           +-------+----+-------+

            The value of Pos i specifies the position of the item in the
   ref_list, before which u_item i should be inserted. If two or more
   u_items have the same position value, they are inserted in the order
   they appear. A u_item is inserted after a previous inserted u_item.



Bormann (ed.)                                                 [Page 119]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



            When the decompressor receives position list, it first
   retrieves all the items in the ref_list. Then for each u_item, it
   inserts it into the ref_list at the position indicated in the
   corresponding pos field in the position list.

            Note that the number of bits used for pos field is
   ceiling(log2(k+1)), where k is the number of items in the ref_list.
   Pos field = "k" means that the correspondent item should be inserted
   to the end of the list.

            Assuming the number of new items is m, then the total length
   of the position list is m * ceiling(log2(k+1)).

          The selection of these formats depends on the encoding
   efficiency.  In the case that the number of item in the ref_list is
   large and only few items are inserted, the position list format is
   favorable; otherwise the bit mask format is more efficient.

      1.2.3.  Removal Only Scheme

        This scheme only addresses the case where certain items exist in
   the ref_list but not in the curr_list. The structure of the
   compressed item list is as follows.

                         +----------+--------+-----+---------------+
        compressed list: | ET = 010 | ref_id | rft | removal order |
                         +----------+--------+-----+---------------+


        * The encoding scheme type (ET) is "010".

        * The ref_id is defined as before.

        * The rft field specifies the format used in removal order
   field.
          0 - bit mask format
          1 - position list format

        * The removal order field specifies the positions of the items
          to be removed. Two formats can be used.

        ** Bit mask format: In this format, a removal bit mask is
   included. A '1' in the i-th bit in the removal bit mask means that
   the i-th item in the ref_list is not included in the curr_list, while
   a '0' means it is still present in the curr_list. Assuming the number
   of items in the ref_list is k, then the length of the removal bit
   mask is k. Since k is known to both the compressor and decompressor,
   the length of the bit mask doesn't need to be carried in the
   compressed list.




Bormann (ed.)                                                 [Page 120]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


        ** Position list format: In this format, a list of position
   fields as well as a count field is included. The structure of this
   format is as follows.

                           +-------+:::::::+::::+:::::::+
            position list: | count | pos 1 |....| pos m |
                           +-------+:::::::+::::+:::::::+

            - The count field carries the number of pos fields in the
   position list. Count field = '0' has the special meaning that all the
   items are removed and no pos field is included.  Assuming the number
   of items in the ref_list is k, then the length of count field is
   ceiling(log2(k)).

            - Each pos field carries the position of an item in the
   ref_list, which no longer exists in the curr_list. The length of the
   pos field is ceiling(log2(k)).

            The length of the position list is (m + 1) *
   ceiling(log2(k)).

          The selection between these two formats depends on the
   encoding efficiency. In the case that the number of items in the
   ref_list is small and/or the number of items removed from the
   ref_list is large, the bit mask format is favorable; otherwise the
   position list format is more efficient.

      1.2.4.  Insertion and Removal Only Scheme

        This scheme accommodates all the transformation cases addressed
   in insertion only and removal only schemes. The structure of the
   compressed item list is as follows.

                         +----------+--------+--------------+-----+
        compressed list: | ET = 011 | ref_id | u_item count | rft |
                         +----------+--------+--------------+-----+
        ---------------+-----+-----------------+----------+----+--------
   --+
         removal order | aft | insertion order | u_item 1 |....| u_item
   m |
        ---------------+-----+-----------------+----------+----+--------
   --+

        * The encoding scheme type (ET) is "011".

        * The ref_id is defined as before.

        * The remaining fields are defined in insertion only scheme and
   removal only scheme. Unlike the insertion order field in the
   insertion only case, the insertion order field in this scheme is
   based on the items left in the ref_list after removal has been



Bormann (ed.)                                                 [Page 121]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   processed. When the decompressor receives such compressed list, it
   applies the removal before the insertion.

      1.2.5.  Content Change Only Scheme

        This scheme only addresses the case where the number of items in
   the list and the ordering are not changed, but the content of one or
   more item is changed. The structure of the compressed item list is as
   follows.

        compressed list:
        +----------+--------+-----+--------------+-----------+----+-----
   ------+
        | ET = 100 | ref_id | cft | change order | uc_item 1 |....|
   uc_item m |
        +----------+--------+-----+--------------+-----------+----+-----
   ------+

        * The encoding type (ET) is "100".

        * The ref_id is defined as before.

        * The cft field specifies the format used in change order field.
          0 - bit mask format
          1 - position list format

        * The change order field specifies the position of the items
   whose content is changed. Two formats can be used.

        ** Bit mask format: In this format, a change bit mask is
   included. A '1' in the i-th bit in the change bit mask means that the
   i-th item in the ref_list is not identical to the i-th item in the
   curr_list, while a '0' means they are the same.  Assuming the number
   of items in the ref_list is k, then the length of the change bit mask
   equals k. Since k is known to both the compressor and the
   decompressor, it doesn't need to be sent in the compressed list.

        ** Position list format: In this format, a list of position
   fields as well as a count field is included.  The structure of this
   format is as follows.

                           +-------+-------+----+-------+
            position list: | count | pos 1 |....| pos m |
                           +-------+-------+----+-------+

            - The count field carries the number of pos fields in the
   position list. Value '0' in count field has the special meaning that
   all the items are changed and no pos field is included.  Assuming the
   number of items in the ref_list is k, then the length of count field
   is ceiling(log2(k)).




Bormann (ed.)                                                 [Page 122]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


            - Each pos field carries the position of an item in the
   ref_list, whose value is not identical with the item at the same
   position in the curr_list.

            The length of position list is (m + 1) * ceiling(log2(k)).

          The selection between these two formats depends on the
   encoding efficiency. In the case that the number of items that have
   content change is small, the bit mask format is favorable; otherwise
   the position list format is more efficient.

        * Each uc_item in the uc_item list corresponds to the item whose
   content is changed when comparing it with the item at the same
   position in the ref_list. Their positions in curr_list is indicated
   in the change order field. When position list format is used in
   change order field and the count field is '0', the order of the
   uc_item is the same as the item order in ref_list. The structure of
   uc_item is as follows.

                   +---+---------------------------------+
          uc_item: | C | compressed or uncompressed data |
                   +---+---------------------------------+

          C bit specifies the format of the compressed or uncompressed
   data field. A '0' in C bit indicates the uncompressed value of the
   item is sent, while a '1' indicates the compressed value of the item
   is carried. The item in the curr_list is compressed using the item at
   the same position in ref_list as the reference. The compression
   technique is dependent on the item and should be predefined.

      1.2.6.  Insertion and Content Change Only Scheme

        This scheme only addresses the case where 1) all the items in
   the ref_list are also in the curr_list, 2) new items are added into
   the curr_list, 3) the relative order of the items that are in both
   ref_list and curr_list remains the same, and 4) the content of one or
   more of these items have been changed. The structure of the
   compressed item list is as follows.

        compressed list:
        +----------+--------+-----+--------------+-----------+----+-----
   -------+
        | ET = 101 | ref_id | cft | change order | uc_item 1 |....|
   uc_item m1 |
        +----------+--------+-----+--------------+-----------+----+-----
   -------+
        -----+-----------------+----------+----+-----------+
         aft | insertion order | u_item 1 |....| u_item m2 |
        -----+-----------------+----------+----+-----------+

        * The encoding type (ET) is "101".



Bormann (ed.)                                                 [Page 123]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000



        * The ref_id is defined at the beginning of section 1.

        * The remaining fields are defined in insertion only scheme and
   content change only scheme. The change order field in this scheme is
   based on the items in the ref_list and the items in the curr_list,
   excluding the new inserted items. When the decompressor receives such
   a compressed list, it applies the content change before the
   insertion.

      1.2.7.  Removal and Content Change Only Scheme

        This scheme only addresses the case where 1) some items in the
   ref_list are not in the curr_list, and 2) the content of one or more
   items that are in both ref_list and curr_list is changed, but the
   relative order of these items remains the same. The structure of the
   compressed item list is as follows.

        compressed list:
        +----------+--------+-----+---------------+-----+--------------+
        | ET = 110 | ref_id | rft | removal order | cft | change order |
        +----------+--------+-----+---------------+-----+--------------+
        -----------+----+-----------+
         uc_item 1 |....| uc_item m |
        -----------+----+-----------+

        * The encoding type (ET) is "110".

        * The ref_id is defined at the beginning of section 1.

        * The remaining fields are defined in the removal only scheme
   and content change only scheme. The change order field in this scheme
   is based on the items in the curr_list and the items in the ref_list
   after the removal is processed. When the decompressor receives such a
   compressed list, it applies the removal before the content change.

      2.  Examples

        The examples below illustrate the operation of item list
   compression under various transformation cases. We assume no type-
   specific data is needed for the decompression.

        Example 1. Insertion and Removal only

        Assuming the items and the order of these items in the curr_list
   and ref_list are as follow.

        curr_list: A, B, C, D

        ref_list:  B, C, X




Bormann (ed.)                                                 [Page 124]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


        Comparing curr_list with ref_list, A and D are added into the
   list and X is removed from the list. No change happens to the order
   and the content for B and C. The format defined in the insertion and
   removal only scheme can be used.

        The compressed item list format for this case is as follow.

                         +----------+--------+--------------+-----+
        compressed list: | ET = 011 | ref_id | u_item count | rft |
                         +----------+--------+--------------+-----+

        ---------------+-----+-----------------+--------------+---------
   -----+
         removal order | aft | insertion order | u_item for A | u_item
   for D |
        ---------------+-----+-----------------+--------------+---------
   -----+

        * ref_id is defined in section 1.

        * The u_item count equals 2.

        * Assuming that the bit mask format is used for removal order,
   then rft equals '0'.

        * The removal order is "001" where the bits from left to right
   correspond to B, C, X respectively. The '1' corresponds to X and
   indicates that X is removed.

        * Assuming that position list format is used for the insertion
   order, then aft equals '1'.

        * The insertion order is "0010". The first 2 bits "00" indicate
   item A is added before the item at position "00" in the ref_list,
   which is B.  The following 2 bits "10" indicate item D is added
   before position "10" in the ref_list after the removal process, which
   is after item B.

        * The u_item for A and u_item for D carry uncompressed A and D
   respectively.

        Example 2. Insertion, Removal, Change of Content and Reordering

        Assuming the items and the order of these items in the curr_list
   and ref_list are as follow.

        curr_list: A, C, B', D

        ref_list:  B, C, X





Bormann (ed.)                                                 [Page 125]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


        Comparing curr_list with ref_list, A and D are added into the
   list and X is removed from the list.  The order of B and C is changed
   and the content of B is changed as well. The generic item list
   compression format is used to carry the change.

                         +----------+--------+--------------+
        compressed list: | ET = 000 | ref_id | c_item count |
                         +----------+--------+--------------+
        ----------+----------+----------+----------+
         c_item A | c_item C | c_item B | c_item D |
        ----------+----------+----------+----------+

        * The c_item count equals 4.

                    +----+------------------------+
        * c_item A: | 11 | A (uncompressed value) |
                    +----+------------------------+

                    +---+----+
        * c_item C: | 0 | 01 |
                    +---+----+

          "01" represents the position of C in the ref_list.

                    +----+----+---------------+
        * c_item B: | 10 | 00 | compressed B' |
                    +----+----+---------------+

          "00" represents the position of B in the ref_list. Compressed
   B' carries the compressed value of B', using B in the ref_list as the
   reference.

                    +----+------------------------+
        * c_item D: | 11 | D (uncompressed value) |
                    +----+------------------------+

      3.  Optimization

        The above description assumed that a given item in the curr_list
   can be uniquely classified as belonging to one transformation case.
   In reality, there are cases where there is more than one way to do
   the classification. An example is given as follows.

        For a given item (item X) in the curr_list, there is no item in
   the ref_list which has an identical content, but one item (item Y) in
   the ref_list has a similar structure to item X, therefore, item X can
   be classified as belonging to either transformation case B or
   transformation case C. An example of this type of list is the CSRC
   list in RTP header.





Bormann (ed.)                                                 [Page 126]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


        The compressor can decide to use the transformation case, for
   which the encoding scheme will yield the highest compression
   efficiency.  For example, in the above example, let's assume item X
   consists of L_x bits.

        * If item X is classified as belonging to transformation case A
   and c_item code "11" is used, the c_item for item X consists of (L_x
   + 2) bits.

        * If item X is classified as belonging to transformation case B
   and c_item code "10" is used, under the assumption that the length of
   the pos field is L_pos and the length of compressed item X when using
   item Y as the reference is D_xy, then the c_item for item X consists
   of (L_pos + D_xy + 2) bits.

          Thus, if (L_pos + D_xy) is larger than L_x, then
   transformation case B is applied; otherwise transformation case A is
   applied.




































Bormann (ed.)                                                 [Page 127]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


Appendix E _ Encoding Examples

E.1.  Basic VLE

      The examples below illustrate the operation of VLE under various
   scenarios.  The field values used in the examples could correspond to
   any fields that we wish to compress.  The examples illustrate the
   scenario where the compressed field has resolution of one bit.

      Example 1: Normal operation (no packet loss prior to compressor,
   no reodering prior to compressor).

      Suppose packets with header fields 279, 280, 281, 282, and 283
   have been sent, and 279 and 283 are fields of potential reference
   packets.

      The current VLE window is {279, 283}.

      and a packet with field value = 284 is received next, VLE computes
   the following values

      New Value   VMax    VMin             r                   # LSBs
         284      283     279    max[|284-279|,|284-283|]=5       4

      The window is unmodified if we assuming the new packet {284} is
   not a potential reference.  The field is encoded using 4 bits in this
   case, and the actual encoded value is the 4 least significant bits of
   284 (10011100) which = 1100.

      Example 2:  Packet Loss prior to compressor.

      Suppose packets with header fields 279, 280, 281, 282, and 283
   have been sent, and 279 and 283 are fields of potential reference
   packets such that the VSW is again {279, 283}.

      If a packet with field value = 290 is received next, VLE computes
   the following values

      New Value  VMax  VMin             r                # LSBs
        290      283   279   max[|290-283|,|290-279|]=11    5

      So the field is encoded using 5 bits.  Actual encoded value is the
   5 LSBs of 290 (100100010) which = 00010.

      If we assume the new value is a potential reference, the new VSW
   is {279, 283, 290}.

      Example 3:  Packet Misordering prior to compressor.






Bormann (ed.)                                                 [Page 128]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


      Suppose packets with header fields 279, 280, 281, 282, and 283
   have been sent, and 279 and 283 are fields of potential reference
   packets such that the VSW is again {279, 283}.

      If a packet with field value = 278 is received next, VLE computes
   the following values

      New Value     VMax    VMin             r                  # LSBs
        278         283     279   max[|278-283|,|278-279|]=5      4

      So the field is encoded using 4 bits.  Actual encoded value is the
   4 LSBs of 278 (10010110) which = 0110.

      If we assume the new value is a potential reference, the new VSW
   is {283, 290, 278}.

      In any case, the VLE encoded fields must be accompanied by some
   bits in order to identify the different possible encoded field sizes.
   Sizes of this bit field can vary depending on the number of different
   sizes one wishes to allow.  The approach in ACE is to allow only a
   few different sizes for byte-aligned header formats.  Huffman coding
   of the length is used to achieve some additional efficiency, based on
   the expected frequency of needing the different sizes.  1 or 2
   additional bits are actually sent in the ACE compressed header.

      The decompressor behavior in all the example cases is the same- it
   uses as a reference a specific decompressed header field value.  The
   header to use might be indicated by the presence of a checksum in the
   compressed header packet, or by other means.  They must by definition
   be one of the values in the compressor's window.

      For example let's assume that the last correctly decompressed
   packet which qualifies as a reference was the packet with header
   field = 291.  Now suppose the encoded field value of 303 (10001111)
   is received and = 01111.  The two values closest values to 291 which
   have LSBs = 01111 are 271 and 303.  303 is closest, therefore it is
   correctly selected as the uncompressed field value.

E.2.  Timer-Based VLE



      As a an example of operation, consider the case of a voice codec
   (20 mS), such that TS_stride = 160.  Assume T_current and
   p_TS_current are 357 and 351, respectively, and that we have sliding
   window TSW which contains the following values 4 entries:

           j           T_j         p_TS_j

           1            9            7
           2            8            6



Bormann (ed.)                                                 [Page 129]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


           3            7            4
           4            3            1

      j above is the packet number.

      In this case we have

      Network_jitter(1)=|(357-9)-(351-7)|=4 (80 mS Network Jitter)
      Network_jitter(2)=|(357-8)-(351-6)|=4  (80 mS Network Jitter)
      Network_jitter(3)=|(357-7)-(351-4)|=3 (60 mS Network Jitter)
      Network_jitter(4)=|(357-3)-(351-1)|=4  (80 mS Network Jitter)

      So Max_Network_Jitter = 4.

      We assume a maximum CD-CC jitter of 2 (40 mS); the total jitter to
   be handled in this case is then

           J = 4 + 2 + 2 = 8 packets (160 mS)

      and k = 5 bits (since 2 * 5 + 1 < 2^5).  The compressor sends the
   5 LSBs of p_TS_current to the decompressor (351 = 101011111, so the
   encoded TS value = 11111).

      When the decompressor receives this value, it first attempts to
   estimate the timestamp by computing the time difference between the
   last reference established and the current packet

            T_current - T_ref, where T_ref is the value of the wall
   clock time at which the reference headers was received by the
   decompressor


      That value is added to p_TS_ref, the packed RTP TS of the
   reference header, to get the estimate.

      Assume that at the decompressor packet #3 is used as the
   reference:


           - T_current = 359
           - T_ref = 7
           - p_TS_ref = 4

      Note:

      T_current is picked here as any value; the difference between it
   and T_ref represents the length of the silence interval as observed
   at the decompressor.  Then:

           T_current - T_ref = 359 - 7 = 352
           p_TS_current(estimate) = 352 + 4 = 356



Bormann (ed.)                                                 [Page 130]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000




      The decompressor searches for the closest value to 356 which has,
   in this case, LSBs = 11111.  The value in this case is 351, the
   original p_TS.


      If instead the compressor were to send the timestamp jump as
   simply the difference in consecutive packed RTP Timestamps, that
   value would be

      p_TS_current - p_TS_ref = 351-4 = 347 = 101011011

      So over twice as many bits would be sent for a silence interval of

           347 (20 mS) = 6.94 seconds

      Due to basic conversational real-time requirements, the cumulative
   jitter in normal operation is expected to be at most only a few times
   T stride for voice.  For this reason, the FO payload formats in
   section 4.3 are optimized (in terms of representing different k-
   length encoded TS values) for the case of k=4 (handles up to 16
   discrepencies in the timestamp).  The remaining formats allow a wide
   range of jitter conditions (outside of just voice) to be handled as
   well.





























Bormann (ed.)                                                 [Page 131]

INTERNET-DRAFT          Robust Header Compression          June 29, 2000


   This Internet-Draft expires December 27, 2000.





















































Bormann (ed.)                                                 [Page 132]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/