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

Versions: (draft-ietf-rohc-lower-layer-guidelines) 00 01 02 RFC 3409

Network Working Group                          Krister Svanbro, Ericsson
INTERNET-DRAFT                                                    Sweden
Expires: August 2001                                    February 7, 2001








    Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression
          <draft-ietf-rohc-rtp-lower-layer-guidelines-01.txt>


Status of this memo

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

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

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

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

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

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


Abstract

   This document describes lower layer guidelines for robust header
   compression (ROHC) and the requirements ROHC put on lower layers. 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. The document covers only lower layer guidelines for
   compression of RTP/UDP/IP and UDP/IP headers as specified in [ROHC].
   Both general guidelines and guidelines specific for cellular systems
   are treated.



Svanbro                                                         [Page 1]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001





TABLE OF CONTENTS


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

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

   3.  General guidelines............................................4

          3.1  Error detection.......................................4

          3.2  Inferred header field information.....................4

          3.3  Handling of header size variation.....................5

          3.4  Negotiation of header compression parameters..........6

          3.5  Demultiplexing of flows onto logically
                 separated channels..................................6

          3.6  Packet type identification............................6

          3.7  Packet duplication....................................6

          3.8  Packet reordering.....................................7

          3.9  Feedback packets......................................7

   4.  Cellular system specific guidelines...........................7

          4.1  Handover procedures...................................7

          4.2  Unequal error detection...............................8

          4.3  Unequal error protection..............................9

   5.  IANA Considerations...........................................9

   6.  Security considerations......................................10

   7.  Author's addresses...........................................10

   8.  References...................................................10








Svanbro                                                         [Page 2]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001


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 RTP/UDP/IP
   header compression [ROHC] as being specified by the ROHC working
   group. [ROHC] will from this point be referenced to as ROHC. These
   guidelines should simplify incorporation of the robust header
   compression algorithms 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.

   Hence, this document clarifies the requirements [ROHC] put on lower
   layers, while the requirements on ROHC may be found in [REQ].


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.














Svanbro                                                         [Page 3]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001


3. General guidelines

3.1 Error detection

   All current header compression schemes [RFC1144, RFC2507, RFC2508]
   rely on lower layers to detect errors in (compressed) headers. This
   is usually done with link layer checksums covering at least the
   compressed header. However, all error detecting mechanisms may fail
   to detect some bit errors and cause residual bit errors (undetected
   bit errors).

   Lower layers MUST provide error detection for at least ROHC headers.
   ROHC has been designed not to increase residual bit error rate (for
   reasonable residual error rates) compared to the case when no header
   compression is used. Headers passed up to the header decompressor
   should, however, have a residual bit error close to zero.

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

3.2 Inferred header field information

   Some fields of the RTP/UDP/IP headers may be classified as inferred,
   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 information:

   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.



Svanbro                                                         [Page 4]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001


3.3 Handling of header size variations

   It is desirable for many cellular link layer technologies that bit
   rate variations and thus packet size 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. Variations in header sizes cause variations in packet
   sizes depending on variations of payload size. The following will
   only treat header size variations caused by ROHC and not packet size
   variations due to variations of payload size.

   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 compressed headers dominate 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.

   Header size variations and thus packet size variations depend on
   numerous factors. Un-predictable changes in the RTP, UDP or IP
   headers may cause compressed headers to momentarily increase in size
   as well as header sizes may depend on packet loss rate at lower
   layers. Header size distributions depend also on the mode ROHC
   operates in. However, for e.g. a voice application, carried by
   RTP/UDP/IPv4, with a constant speech frame size and silence
   suppression, the following basic header size changes may be
   considered as typical:

   In the very beginning of the speech session, the ROHC scheme is
   initialized by sending full headers called IR/DYN. These are the
   largest headers and with sizes depending on basically IP-version. For
   IPv4 the size is approximately 40 bytes, and for IPv6 approximately
   60 bytes. The IR/DYN headers are used typically during one round trip
   time, possible interleaved with compressed headers. After that,
   usually only compressed headers are sent. Compressed headers may vary
   in size from 1 byte up to several bytes. The smallest compressed
   headers is used when there is no unpredictable changes in header
   fields, typically during a talk spurt. In the beginning of a talk
   spurt, compressed header sizes may increase with one or a few bytes
   momentarily. Apart from increases due to new talk spurts, compressed
   headers may increase in size momentarily due to unpredictable changes
   in header fields.

   ROHC provides some means to limit the amount of produced header
   sizes. In some cases a larger header than needed may be used to limit
   the number of header sizes used. Padding octets may also be used to
   fill up to a desired size. Chapter 6.3 Implementation parameters in
   [ROHC] provide optional implementation parameters that make it
   possible to mandate how a ROHC implementation should operate, for
   instance to mandate how many header sizes that may be used.



Svanbro                                                         [Page 5]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001


3.4 Negotiation of header compression parameters

   ROHC has some parameters that needs to be set at an initial setup
   phase. Which header compression profile to use may have to be
   determined and also what kind of context identification (CID)
   mechanism to use.

   The lower layers supporting ROHC MUST include mechanisms for
   negotiating header compression parameters such as, CID usage and/or
   header compression profiles. It is RECOMMENDED that the lower layer
   have mechanisms that support re-negotiations of these parameters.

   For unidirectional links, this negotiation may be performed out-of-
   band or even a priori.

3.5 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, real-time 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 lower
   layers 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.6 Packet type identification

   Header compression schemes like [RFC2507, RFC2508] have relied on the
   underlying link layer to identify different kinds of headers by means
   of packet type identifiers on link layers. This kind of mechanism is
   not necessary for ROHC. The packet type identification is
   incorporated in the ROHC scheme and there is thus, no need for such a
   mechanism in the link layer. If ROHC is used together with header
   compression schemes requiring packet type identification at the link
   layer, e.g. [RFC2507, RFC2508], or if ROHC is used on top of link
   layers where packet type identifiers already are present, it is
   RECOMMENDED that one (1) ROHC packet type identifier is supported on
   lower layers. Thus, only one ROHC packet type is needed to mix ROHC
   and e.g. RFC2507 flows or to support ROHC on links where packet type
   identifiers already are present.

3.7 Packet duplication

   Exact duplications of one and the same packet may waste transmission
   resources and is in contradiction to compression. Even so, packet
   duplication may occur for various reasons. Packet duplication may
   also occur in different places along the path for a packet.




Svanbro                                                         [Page 6]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001


   ROHC can handle packet duplication before the compressor but it is
   RECOMMENDED that such packet duplications are avoided. Lower layers
   MUST NOT duplicate packets on the path between ROHC compressor and
   decompressor.

3.8 Packet reordering

   Lower layers between compressor and decompressor is not assumed to
   reorder packets, i.e., the decompressor receives packets in the same
   order as the compressor sends them. ROHC handles, however, reordering
   before the compression point. That is, there is no assumption that
   the compressor will only receive packets in sequence.

3.9 Feedback packets

   ROHC consist of three modes; Unidirectional mode (U-mode),
   bidirectional optimistic mode (O-mode) and bidirectional reliable
   mode (R-mode). A brief description of the modes can be found in
   chapter 4.4 in [ROHC].

   In U-mode it is not necessary to send any feedback from the
   decompressor to the compressor. O-mode and R-mode requires however
   that feedback messages from the decompressor to the compressor may be
   sent. Feedback message consist of small ROHC internal packets without
   any application payload. It is possible in ROHC to piggy-back
   feedback packets onto regular packets with ROHC compressed headers
   and payload, if there is ROHC type of compression in both the forward
   and reverse direction. However, this piggy-backing may not be desired
   or possible in some cases.

   Lower layer MUST support transport of feedback packets from
   decompressor to compressor if ROHC is to be used in O-mode or R-mode.
   Lower layers MUST support transport of small stand-alone feedback
   packets if piggybacking of feedback packets is not used. The feedback
   packets from the decompressor SHOULD be delivered as soon as possible
   to the compressor.

4. Cellular system specific guidelines

   An important group of link layer technologies where robust header
   compression will be needed 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.

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



Svanbro                                                         [Page 7]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001



   The main characteristics of handovers relevant for robust header
   compression are: the length of the longest packet loss event due to
   handover (i.e. the number of consecutive packet losses); relocation
   of header compression context when necessary.

   Depending on the location of the header compressor/decompressor in
   the radio access network and the type of handover, handover may or
   may not cause disruptions or packet loss events in the (compressed)
   header flow relevant for the header compression scheme. For instance,
   if soft handover is used and if the header compressor/decompressor
   reside above the combining point for soft handover, there will be no
   extra packet losses visible to the decompressor due to handover. In
   hard handovers, where packet loss events due to handover is
   introduced, the length of the longest consecutive packet loss is most
   relevant and should thus, be minimized.

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

   If hard handovers are performed, which may cause significant long
   events of consecutive packet loss, it is RECOMMENDED that the radio
   access network notifies the compressor when such a handover has
   started and completed.

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

   If the cellular system does not have any internal mechanism for
   transferring header compression context between nodes, the context
   relocation may be done by the header compression scheme by means of a
   context refresh. 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 that such a handover has occurred, so that it knows when
   to refresh the context. Chapter 6.3 Implementation parameters and
   signals in [ROHC] provide optional implementation parameters that
   make it possible to trigger e.g. a complete context refresh.

4.2 Unequal error detection

   Chapter 3.1 states that ROHC requires error detection from lower
   layers for at least the compressed header. However, some cellular
   technologies may differentiate the amount of error detection for
   different parts of a packet. For instance, it could be possible to



Svanbro                                                         [Page 8]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001


   have a stronger error detection for the header part of a packet, if
   the application payload part of the packet is less sensitive to
   errors, e.g. some cellular types of speech codecs.

   ROHC does not require UED from lower layers, ROHC requires only a
   error detection mechanism that detects errors in at least the header
   part of the packet. There is thus no requirement on lower layers to
   provide separate error detection for the header and payload part of a
   packet. However, overall performance may be increased if UED is used.

   For example, if equal error detection is used in the form of one link
   layer checksum covering the entire packet including both header and
   payload part, any bit error will cause the packet to be discarded at
   the ROHC decompressor. It is not possible to distinguish between
   errors in the header and the payload part of the packet with this
   error detection mechanism and the ROHC decompressor must assume that
   the header is damaged, even if the bit error hit the payload part of
   the packet. If the header is assumed to be damaged, it is not
   possible to ensure correct decompression and that packet will thus be
   discarded. If the application is such that it tolerates some errors
   in the payload, it could have been better to deliver that packet to
   the application and let the application judge whether the payload was
   usable or not. Hence, with an unequal error detection scheme where it
   is possible to separate detection of errors in the header and payload
   part of a packet, more packets may be delivered to applications in
   some cases for the same lower layer error rates. The final benefit
   depends of course on the cost of UED for the radio interface and
   related protocols.

4.3 Unequal error protection

   Some cellular technologies can provide different error probabilities
   for different parts of a packet, unequal error protection (UEP). For
   instance, the lower layers may provide a stronger error protection
   for the header part of a packet compared to the payload part of the
   packet.

   ROHC does not require UEP. UEP may be beneficial in some cases to
   reduce the error rate in ROHC headers, but only if it is possible to
   distinguish between errors in header and payload parts of a packets.
   I.e. only if unequal error detection (UED) is used. The benefit of
   UEP depend of course on the cost of UEP for the radio interface and
   related protocols.

5. IANA Considerations

   A protocol which follows these guidelines, e.g., [ROHC], will require
   the IANA to assign various numbers. This document by itself, however,
   does not require IANA involvment.





Svanbro                                                         [Page 9]

INTERNET-DRAFT   Lower Layer Guidelines for Robust HC   February 7, 2001


6. Security Considerations

   A protocol which follows these guidelines, e.g., [ROHC], must be able
   to compress packets containing IPSEC headers according to [REQ].
   There may be other sequrity aspects to consider in such protocols.
   This document by itself, however, does not add security risks.

7. Author's Addresses

   Krister Svanbro               Tel:   +46 920 20 20 77
   Box 920                       Fax:   +46 920 20 20 99
   Ericsson Erisoft AB           Email: krister.svanbro@ericsson.com
   SE-971 28 Lulea, Sweden

8. References

   [ROHC]      Carsten Borman et al, "Robust Header Compression (ROHC)",
               Internet-Draft (work in progress), February 2001.
               <draft-ietf-rohc-rtp-08.txt>

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

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

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


This Internet-Draft expires in April 2001.











Svanbro                                                        [Page 10]


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