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

Versions: 00

Network Working Group                          Krister Svanbro, Ericsson
INTERNET-DRAFT                                                    Sweden
Expires: September 2000                                   March 10, 2000

          Lower Layer Guidelines for Robust Header Compression

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is an individual submission to the IETF. Comments
   should be directed to the authors.


   This document describes lower layer guidelines for robust header
   compression (HC). The purpose of this document is to support the
   incorporation of robust header compression algorithms, as specified
   in the ROHC working group, into different systems such as those
   specified by 3GPP, 3GPP2, ETSI, etc. This document treats general
   guidelines as well as guidelines specific for cellular systems.

Svanbro                                                         [Page 1]

INTERNET-DRAFT    Lower Layer Guidelines for Robust HC    March 10, 2000


   1.  Introduction..................................................3

   2.  Terminology...................................................3

   3.  Guidelines for robust RTP/UDP/IP header compression...........3

     3.1 General guidelines..........................................3

          3.1.1  Error detection on (compressed) headers.............3

          3.1.2  Indication of erroneous headers.....................4

          3.1.3  Inferred header field information...................4

          3.1.4  Handling of header size variation...................4

          3.1.5  Negotiation of header compression parameters........5

          3.1.6  Demultiplexing of flows onto logically
                 separated channels..................................5

          3.1.7 Packet type identification...........................5

     3.2 Cellular system specific guidelines.........................5

          3.2.1 Handover procedures..................................6

   4.  Guidelines for Robust TCP/IP Header Compression...............6

   5.  Author's addresses............................................6

   6.  References....................................................7

Svanbro                                                         [Page 2]

INTERNET-DRAFT    Lower Layer Guidelines for Robust HC    March 10, 2000

1. Introduction

   Almost all header compression algorithms [RFC1144, RFC2507, RFC2508]
   rely on some functionality from underlying link layer. Headers
   (compressed or not) are expected to be delivered without any residual
   bit errors, IP length fields are inferred from link layer length
   fields and packet type identification may be separated from the
   header compression scheme and instead done at underlying link layer.
   [RFC2509], for example, elaborates on how to incorporate IP header
   compression [RFC2507] in PPP [RFC1661].

   It is important to be aware of such assumptions on required
   functionality from underlying layers when incorporating a header
   compression scheme into a system. The functionality required by a
   specific header compression scheme from lower layers may also be
   needed if incorporation of a header compression scheme is to be
   prepared without knowing the exact details of the final scheme.

   This document describes lower layer guidelines for robust header
   compression as being specified by the ROHC working group. These
   guidelines should simplify incorporation of the robust header
   compression algorithm into cellular system like those standardized by
   3GPP, 3GPP2, ETSI, etc, and also into specific link layer protocols
   such as PPP. The document should also enable preparation of this
   incorporation without requiring detailed knowledge about the final
   header compression scheme. Relevant standardization groups
   standardizing link layers should, aided by this document, include
   required functionality in "their" link layers to support robust
   header compression.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

3. Guidelines for robust RTP/UDP/IP header compression

   This chapter treats guidelines for robust RTP/UPD/IP header

3.1 General guidelines

3.1.1 Error detection on (compressed) headers

   All current header compression schemes [RFC1144, RFC2507, RFC2508]
   rely on lower layers to detect errors in (compressed) headers. The
   link layer underlying header compression MUST provide error detection
   to the de-compressor if the compressed header do not have an internal
   error detection. Headers passed up to the header decompressor should
   have a residual bit error rate (undetected bit error rate) very close

Svanbro                                                         [Page 3]

INTERNET-DRAFT    Lower Layer Guidelines for Robust HC    March 10, 2000

   to zero. (Further work is needed to find a numerical value or
   interval on the required residual bit error rate.)

3.1.2 Indication of erroneous headers

   It is RECOMMENDED that erroneous headers are passed up to the
   decompressor, but in that case an indication that the header has
   errors MUST be included to the decompressor together with erroneous

3.1.3 Inferred header field information

   Some fields of the RTP/UDP/IP headers may be classified as inferred
   [ROCCO], that is their values are to be inferred from other values or
   from an underlying link layer. An underlying link layer MUST
   therefore provide the header decompressor with the following

   Packet Length (IPv4)

     Information about the received packet (with the compressed header)
     length MUST be provided by the link layer.

   Payload Length (IPv6)

     Information about the received packet (with the compressed header)
     length MUST be provided by the link layer.

   Length (UDP)

     This field is redundant with the Packet Length (IPv4) or the
     Payload Length (IPv6) field. Hence, the value of this field MUST in
     some way be provided to the decompressor.

   In summary, all of the fields above relate to the length of the
   packet the compressed header is included in. All three fields may
   thus be inferred by the decompressor if one packet length value is
   signaled from the link layer to the decompressor on a per packet
   basis. This packet length value should be the length of the received
   packet including the (compressed) header.

3.1.4 Handling of header size variations

   It is desirable for many cellular link layer technologies that bit
   rate variations are minimized. However, there will always be some
   variation in compressed header sizes since there is a trade-off
   between header size variations and compression efficiency, and also
   due to events in the header flow and on the channel. The link layer
   MUST in some manner support varying header sizes from 40 bytes (full
   RTP/UDP/IPv4 header) or 60 bytes (full RTP/UDP/IPv6) down to 1 byte
   for the minimal compressed header. It is likely that the small

Svanbro                                                         [Page 4]

INTERNET-DRAFT    Lower Layer Guidelines for Robust HC    March 10, 2000

   compressed headers are dominating the flow of headers, and that the
   largest headers are sent rarely, e.g. only a few times in the
   initialization phase of the header compression scheme.

3.1.5 Negotiation of header compression parameters

   The ROHC header compression scheme will have some parameters that
   needs to be set at an initial setup phase. For instance, the header
   compression profile to use must be determined [ROCCO]. Compressor and
   decompressor capabilities may also be negotiated. Hence, the link
   layer supporting robust header compression MUST include mechanisms
   for negotiating header compression parameters such as, header
   compression profiles, compressor and decompressor capabilities.

   It also RECOMMENDED that the link layer have mechanisms that support
   re-negotiations of such parameters.

3.1.6 Demultiplexing of flows onto logically separated channels

   In some cellular technologies there are a demultiplexing of flows
   onto radio bearers suitable to the particular flows, i.e., onto
   logically separated channels. For instance, realtime flows such as
   voice and video may be carried on logically separated bearers. It is
   RECOMMENDED that this kind of demultiplexing is done in the link
   layer technology supporting robust header compression. By doing so,
   the need for context identification in the header compression scheme
   is reduced. If there is a one to one mapping between flow and logical
   channel, there is no need at all for context identification at the
   header compression level.

3.1.7 Packet type identification

   Header compression schemes like [RFC2507, RFC2508] have relied on the
   underlying link layer to identify different kinds of headers. This
   kind of mechanism is not necessary for robust RTP/UDP/IP header
   compression. The packet type identification will be incorporated in
   the header compression scheme and there is thus, no need for such a
   mechanism in the link layer.

3.2 Cellular system specific guidelines

   An important group of link layer technologies where robust header
   compression will be needed for services carried by RTP are future
   cellular systems, which may have a very large number of users in some
   years. The need for header compression is large in these kinds of
   systems to achieve spectrum efficiency. Hence, it is important that
   future cellular systems can efficiently incorporate the robust header
   compression scheme.

Svanbro                                                         [Page 5]

INTERNET-DRAFT    Lower Layer Guidelines for Robust HC    March 10, 2000

3.2.1 Handover procedures

   One cellular specific property that may affect header compression is
   mobility and thus, handover (i.e., change of serving base station or
   radio network controller).

   Handover SHOULD NOT cause significant long events of packet loss.
   Significant in this context relates to the kind of loss tolerable for
   the carried realtime application.

   The cellular system supporting robust header compression MAY also
   have internal mechanisms for transferring the header compression
   context between nodes where contexts may reside, at or before

   If the cellular system does not have any internal mechanism for
   transferring header compression context between nodes, the transfer
   of context may be done by the header compression scheme. The header
   compression scheme may perform a new header compression
   initialization, e.g. by sending "full" headers. This will, however,
   introduce an increase in the average header size dependent on how
   often a transfer of context is needed.

   In this latter case, the lower layers MUST indicate to the header
   compressor module that a handover has occurred, so that it knows when
   to perform the initialization.

4. Guidelines for Robust TCP/IP Header Compression

   This chapter treats guidelines for robust TCP/IP header compression.

   To be written.

5. Author's Addresses

     Krister Svanbro             Tel:    +46 920 20 20 77
     Ericsson Research           Mobile: +46 70 621 69 42
     Lulea, Sweden               EMail:  krister.svanbro@epl.ericsson.se

Svanbro                                                         [Page 6]

INTERNET-DRAFT    Lower Layer Guidelines for Robust HC    March 10, 2000

6. References

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

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

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

   [RFC2509]   Mattias Engan, Steven Cassner, "IP Header Compression
               over PPP", RFC2509, February 1999

   [RFC1661]   Simpson, W., Ed., "The Point-To-Point Protocol (PPP)",
               STD 51, RFC 1661, July 1994.

   [ROCCO]     Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, Krister
               Svanbro, "RObust Checksum-based header COmpression
               ROCCO)", Internet-Draft (work in progress), March 2000.

This Internet-Draft expires in September 2000.

Svanbro                                                         [Page 7]

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