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

Versions: 00 draft-ietf-rohc-rtp

Robust Header Compression (RoHC) WG                    Akihiro Miyazaki
Internet Draft                                        Hideaki Fukushima
Document: <draft-ietf-rohc-rtp-kw-00.txt>                 Thomas Wiebke
May 23th, 2000                                           Rolf Hakenberg
Expires: November 23th, 2000                         Carsten Burmeister

                                                             Matsushita


            Robust Header Compression using Keyword-Packets


Status of this Memo

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

   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 to cite them other than as "work in
   progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


1. Abstract

   Header Compression has proven to be essential for using RTP over
   bandwidth limited links. While all of these links have only a
   limited bandwidth, some are additional extremely unreliable, e.g.
   wireless links. It is shown, that existing Header Compression
   schemes, that work well over reliable links, perform very bad, if
   many errors occur.

   This led to the development of a new robust Header Compression
   mechanism, that is introduced in this paper. The core idea is the
   definition of update packets, which are referenced by non-update
   packets. This reduces the interdependency between the packets and
   with this the amount of discarded packets at the decompressor.

   The Header Compression scheme, the used packet formats and the
   decompression algorithm, are described in detail.





Miyazaki             Expires November 23th, 2000                    1

 Header Compression using Keyword Packets                 May 23th, 2000




   Table of Contents

   1.  Abstract
   2.  Conventions used in this document
   3.  Introduction
   4.  The concept of keyword header compression
   4.1   Keyword field, update and non-update packet
   4.2   The use of LSB encoding
   4.3   Refreshing the context by sending update packets
   4.3.1   Minimizing the loss probability of update packets
   4.3.2   Restrict the use of new keywords
   4.4   Loss of update packets
   4.5   Adaptation to the environment
   5.  Profile 1, optimized for sequential IPv4 Identification
   5.1   Full Header packet
   5.2   Basic-Compressed packet
   5.2.1   Basic header
   5.2.2   Changing Field extension
   5.2.3   Default-Delta extension
   5.3   One-Byte-Header or Two-Byte-Header packet
   5.4   Context State packet
   6.  Profile 2, optimized for non-sequential IPv4 Identification
   6.1   Full Header packet
   6.2   Basic-Compressed packet
   6.2.1   Basic header
   6.2.2   Changing Field extension
   6.2.3   Default-Delta extension
   6.3   Two-Byte-Header or Three-Byte-Header packet
   6.4   Context State packet
   7.  Conclusions
   8.  Security considerations
   9.  Intellectual property consideration
   10.  Acknowledgements
   11.  References
   12.  Author's addresses

   Document History

   00  March 01, 2000:   First release.
   01  May 01, 2000:     Two different profiles (sets of packet types)
                         are defined, optimized for different
                         environments. Least Significant Bit (LSB)
                         encoding is used. Some changes in the
                         algorithm.
   00  May 23, 2000:     Submitted as a working group document. Changes
                         include some clarifications of the concept of
                         update packets and their use (Section 4).






Miyazaki             Expires November 23th, 2000                    2

 Header Compression using Keyword Packets                 May 23th, 2000




2. Conventions used in this document

   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 [2].


3. Introduction

   The increasing use of real-time services over the Internet, such as
   voice or video applications, led to a strong demand for a protocol
   to be used to transport data real-time or nearly real-time. The
   Real-time Transport Protocol (RTP) provides the means for such
   services. After the publication as an RFC, more and more
   applications were developed to use RTP.

   Another important development in the last years has been the user's
   demand for mobility, i.e. accessing many services, including video
   and data applications, anytime and anywhere.

   While RTP is commonly used in fixed networks, which is the
   environment it was developed for, using it over mobile networks
   needs some further considerations. A problem that occurs is the
   limited bandwidth in the mobile channel. There is a need to use this
   bandwidth very efficiently to satisfy enough users. Enough users per
   cell are very important to be economically feasible.

   Each of the protocols RTP, UDP and IP adds its own header, which
   sums up to 40 byte in most of the cases, i.e. 12 bytes RTP header, 8
   bytes UDP header and 20 bytes IP version 4 header (If IP version 6
   is used, the amount of overhead is increased by another 20 bytes,
   because of the extended address format).

   To solve the problem of the large amount of overhead header
   compression mechanisms have been developed. CRTP is commonly used
   over reliable links. It compresses the header to a minimum of 2
   bytes. While this works fine over reliable channels, it induces many
   additional errors, when used over unreliable channels. This is
   because the first or second order differences to the previous
   packet, which are efficiently coded, are transmitted. If a packet
   gets lost, due to bit errors over the wireless channel, the
   compressed header of the next packet cannot be decompressed. The
   decompressor must send a request for a packet with a decompressed
   header to resynchronize, but in the meanwhile all received
   compressed packets have to be discarded. This effect is shown in
   detail in [8].

   In this paper we present a header compression mechanism that is more
   robust against packet loss and hence performs better over unreliable
   channels.



Miyazaki             Expires November 23th, 2000                    3

 Header Compression using Keyword Packets                 May 23th, 2000




4. The concept of keyword header compression

   This section describes the concept of the keyword header compression
   proposal and how this concept leads to a better performance, when
   used over unreliable links.


4.1 Keyword field, update and non-update packet

   The problem of CRTP is its interdependency between all packets. If
   one packet gets lost, all following packets, until the next update,
   are lost. This is due to the fact that every packet, that is sent by
   the compressor, updates the context. Hence the context state at the
   decompressor will become invalid, if one of these packets is lost.

   A possibility to solve this problem is to update the context only
   from time to time. However the context that is used has to be
   communicated and it has to be ensured that the decompressor received
   the context correctly.

   The main idea 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 able to
   decompress the following packets.


4.2 The use of LSB encoding

   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).

   The number of LSB to be used, is defined by the value itself. The
   compressor has to ensure that the decompressor is able to decode the
   value correctly. The decoding is done by simply replacing the
   transmitted LSB with the LSB of the context value that is
   referenced.






Miyazaki             Expires November 23th, 2000                    4

 Header Compression using Keyword Packets                 May 23th, 2000




4.3 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.

   Second, if a value had changed and seems to be stable now, a new
   update packet should be sent. Otherwise the changed value would have
   to be transmitted in all following packets. E.g. after a silent
   period, the timestamp changes by another value than the default
   difference timestamp. From this on it is not possible for the
   decompressor to calculate the timestamp from the RTP sequence
   number. Hence the compressor either sends the LSB of the timestamp
   in every packet, or updates the context, to enable the decompressor
   to calculate the timestamp from the RTP sequence number again.


4.3.1 Minimizing the loss probability of update packets

   Because every packet with a new keyword value, which is not an
   update packet must be discarded, the loss probability of the context
   should be minimized. It might be useful to send several update
   packets with the same keyword value to establish a new context state
   for both sides. 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.


4.3.2 Restrict the use of new keywords

   The number of different keywords is limited by the number of bits
   used for the keyword field. In this paper we use only one bit, 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.





Miyazaki             Expires November 23th, 2000                    5

 Header Compression using Keyword Packets                 May 23th, 2000




   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. 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. Maybe there will be some overhead during this
   period, because all changes have to be transmitted in every packet,
   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, 2*N consecutive packets
   have to be lost, before the decompressor would not detect the 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.


4.4 Loss of update packets

   Only if the update packets are transmitted correctly, the receiver
   is able to decompress any incoming compressed header. 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
   reestablishes its context. This is always an update packet or a Full
   Header packet.


4.5 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 tradeoff 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.



Miyazaki             Expires November 23th, 2000                    6

 Header Compression using Keyword Packets                 May 23th, 2000





   Using this freedom the compressor may adapt the compression to the
   environment (i.e. the experienced BER or RTT). Another parameter of
   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 optimized 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 behavior, another set of packet formats is defined,
   which is optimized for non sequential IPv4 Identification values.

   The two sets of packet formats are called profiles in the remainder
   of this document. How it is decided and negotiated, which profile to
   use is not scope of this document. It should only be shown, that the
   differentiation between these environments might make sense.


5. 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.1 Full Header packet

   The Full Header packet is sent at the beginning of the session to
   establish a valid context. 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.

   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



Miyazaki             Expires November 23th, 2000                    7

 Header Compression using Keyword Packets                 May 23th, 2000




   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     :


















Miyazaki             Expires November 23th, 2000                    8

 Header Compression using Keyword Packets                 May 23th, 2000




5.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. 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.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
   :                               :
   +---+---+---+---+---+---+---+---+
   |           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.


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



Miyazaki             Expires November 23th, 2000                    9

 Header Compression using Keyword Packets                 May 23th, 2000




   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 (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.


5.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
   +...+...+...+...+...+...+...+...+




Miyazaki             Expires November 23th, 2000                   10

 Header Compression using Keyword Packets                 May 23th, 2000




   The first bit (0) indicates the extension that is used.
   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          +
      |                               |
      +                               +
      |                               |
      +---+---+---+---+---+---+---+---+



Miyazaki             Expires November 23th, 2000                   11

 Header Compression using Keyword Packets                 May 23th, 2000




   TOS (IPv4 Type Of Service Indication):
   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.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:










Miyazaki             Expires November 23th, 2000                   12

 Header Compression using Keyword Packets                 May 23th, 2000




     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1 | 0 | - | - | ddTL  | ddIDL |
   +---+---+---+---+---+---+---+---+
   :              ddTS             :   if ddTL > 0
   +...+...+...+...+...+...+...+...+
   :              ddTS             :   if ddTL > 1
   +...+...+...+...+...+...+...+...+
   :              ddTS             :   if ddTL > 2
   +...+...+...+...+...+...+...+...+
   :              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.3 One-Byte-Header or Two-Byte-Header packet

   Packets of these two types are always non-update 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:




Miyazaki             Expires November 23th, 2000                   13

 Header Compression using Keyword Packets                 May 23th, 2000




   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
      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.4 Context State packet

   This header compression proposal is aimed to perform good, even if
   used over an unreliable channel. Hence bit errors can occur quite



Miyazaki             Expires November 23th, 2000                   14

 Header Compression using Keyword Packets                 May 23th, 2000




   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
   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.






Miyazaki             Expires November 23th, 2000                   15

 Header Compression using Keyword Packets                 May 23th, 2000




   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.


6. 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
   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.

6.1 Full Header packet

   The Full Header packet is sent at the beginning of the session to
   establish a valid context. It is used exactly as in profile 1 and
   has the same format (see section 5.1 for details).

6.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 profile, this packet tyoe can be used for update packets
   (new-keyword flag set to one) or non-update packets.

6.2.1 Basic header

   The basic header's format is as follows:













Miyazaki             Expires November 23th, 2000                   16

 Header Compression using Keyword Packets                 May 23th, 2000




     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
   :                               :
   +---+---+---+---+---+---+---+---+
   |           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.

   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.




Miyazaki             Expires November 23th, 2000                   17

 Header Compression using Keyword Packets                 May 23th, 2000




   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:
   If the UDP Checksum is enabled, this field contains the 16-bit
   Checksum, else it is not present.

6.2.2 Changing Field Extension

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

6.2.3 Default Delta Extension

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

6.3 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.

   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



Miyazaki             Expires November 23th, 2000                   18

 Header Compression using Keyword Packets                 May 23th, 2000




      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
   +...+...+...+...+...+...+...+...+
   :      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



Miyazaki             Expires November 23th, 2000                   19

 Header Compression using Keyword Packets                 May 23th, 2000




   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.


6.4 Context State packet

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


7. Conclusions

   It was stated that CRTP induces too many additional errors, when
   used over unreliable links. A new solution, keyword header
   compression, was described, which reduces the number of additional
   errors.

   The solution is split into two different profiles, optimized for
   different scenarios. The average header size is reduced compared to
   CRTP as well as the number of additional errors. If used in a
   cautious way, e.g. sending several succeeding keyword packets, the
   amount of additional errors should be near zero.


8. Security Considerations

   Security issues are not considered in this memo.


9. Intellectual property considerations

   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).


10. Acknowledgements

   This proposal combines several ideas of other papers and introduces
   some new features and mechanisms. The main inspiration for some of
   these mechanisms came from discussions on the 47th IETF Meeting in
   Adelaide, the discussions on the ROHC mailing list and the Internet
   Drafts [7], [8], [11], [12], [13] and [14].



Miyazaki             Expires November 23th, 2000                   20

 Header Compression using Keyword Packets                 May 23th, 2000




11. References


   1  Bradner, S., "The Internet Standards Process -- Revision 3",
      BCP9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   3  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
      A Transport Protocol for real-time applications", RFC 1889,
      January 1996.

   4  Postel, J.,"User Datagram Protocol", STD 6, RFC 768, August 1980.

   5  Postel, J.,"Internet Protocol", STD 5, RFC 791, September 1981.

   6  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
      Specification", RFC 2460, December 1998.

   7  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
      Low-Speed Serial Links", RFC 2508, February 1999.

   8  Mikael Degermark, Hans Hannu, Lars-Erik Jonsson, Krister Svanbro,
      "CRTP over cellular radio links", Internet Draft (work in
      progress), June 1999.

   9  Homepage of 3GPP: http://www.3gpp.org

   10 "Procedure for Evaluation of Transmission Technologies for
      FPLMTS", ITU-R TG8-1, 8-1/TEMP/233-E, September 1995.

   11 Martensson, Einarsson, Jonsson,"ROCCO Conversational Video
      Profiles", Internet Draft (work in progress), March 2000.

   12 Le, Clanton, Liu, Zheng,"Adaptive Header Compression (ACE) for
      Real-Time Multimedia", Internet Draft (work in progress),
      March 2000.

   13 Jonsson, Degermark, Hannu, Svanbro," RObust Checksum-based header
      COmpression (ROCCO)", Internet Draft (work in progress),
      March 2000.

   14 Svanbro,"Lower Layer Guidelines for Robust Header Compression",
      Internet Draft (work in progress), March 2000.








Miyazaki             Expires November 23th, 2000                   21

 Header Compression using Keyword Packets                 May 23th, 2000





12. Author's Addresses

   Akihiro Miyazaki
   Matsushita Electric Industrial Co., Ltd
   1006, Kadoma, Kadoma City, Osaka, Japan
   Tel.  +81-6-6900-9192
   Fax.  +81-6-6900-9193
   Mail  akihiro@isl.mei.co.jp

   Hideaki Fukushima
   Matsushita Electric Industrial Co., Ltd
   1006, Kadoma, Kadoma City, Osaka, Japan
   Tel.  +81-6-6900-9192
   Fax.  +81-6-6900-9193
   Mail  fukusima@isl.mei.co.jp

   Thomas Wiebke
   Panasonic European Laboratories GmbH
   Monzastr. 4c, 63225 Langen, Germany
   Tel.  +49-(0)6103-766-161
   Fax.  +49-(0)6103-766-166
   Mail  wiebke@panasonic.de

   Rolf Hakenberg
   Panasonic European Laboratories GmbH
   Monzastr. 4c, 63225 Langen, Germany
   Tel.  +49-(0)6103-766-162
   Fax.  +49-(0)6103-766-166
   Mail  hakenberg@panasonic.de

   Carsten Burmeister
   Panasonic European Laboratories GmbH
   Monzastr. 4c, 63225 Langen, Germany
   Tel.  +49-(0)6103-766-263
   Fax.  +49-(0)6103-766-166
   Mail  burmeister@panasonic.de
















Miyazaki             Expires November 23th, 2000                   22

 Header Compression using Keyword Packets                 May 23th, 2000





Full Copyright Statement

   "Copyright (C) The Internet Society (2000). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.




































Miyazaki             Expires November 23th, 2000                   23


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