rfc3242.txt

RFC 的详细文档！

Network Working Group                                       L-E. Jonsson
Request for Comments: 3242                                  G. Pelletier
Category: Standards Track                                       Ericsson
                                                              April 2002


                   RObust Header Compression (ROHC):
              A Link-Layer Assisted Profile for IP/UDP/RTP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines a ROHC (Robust Header Compression) profile for
   compression of IP/UDP/RTP (Internet Protocol/User Datagram
   Protocol/Real-Time Transport Protocol) packets, utilizing
   functionality provided by the lower layers to increase compression
   efficiency by completely eliminating the header for most packets
   during optimal operation.  The profile is built as an extension to
   the ROHC RTP profile.  It defines additional mechanisms needed in
   ROHC, states requirements on the assisting layer to guarantee
   transparency, and specifies general logic for compression and
   decompression making use of this header-free packet.

Table of Contents

   1.  Introduction....................................................2
   2.  Terminology.....................................................4
   3.  Overview of the Link-Layer Assisted Profile.....................5
        3.1.  Providing Packet Type Identification.....................6
        3.2.  Replacing the Sequence Number............................6
        3.3.  CRC Replacement..........................................7
        3.4.  Applicability of This Profile............................7
   4.  Additions and Exceptions Compared to ROHC RTP...................8
        4.1.  Additional Packet Types..................................8
               4.1.1.  No-Header Packet (NHP)..........................8
               4.1.2.  Context Synchronization Packet (CSP)............8
               4.1.3.  Context Check Packet (CCP)......................9



Jonsson, et. al             Standards Track                     [Page 1]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


        4.2.  Interfaces Towards the Assisting Layer..................11
               4.2.1.  Interface, Compressor to Assisting Layer.......11
               4.2.2.  Interface, Assisting Layer to Decompressor.....12
        4.3.  Optimistic Approach Agreement...........................13
        4.4.  Fast Context Initialization, IR Redefinition............13
        4.5.  Feedback Option, CV-REQUEST.............................14
        4.6.  Periodic Context Verification...........................15
        4.7.  Use of Context Identifier...............................15
   5.  Implementation Issues..........................................15
        5.1.  Implementation Parameters and Signals...................15
               5.1.1.  Implementation Parameters at the Compressor....16
               5.1.2.  Implementation Parameters at the Decompressor..17
        5.2.  Implementation over Various Link Technologies...........18
   6.  IANA Considerations............................................18
   7.  Security Considerations........................................18
   8.  Acknowledgements...............................................18
   9.  References.....................................................19
   10. Authors' Addresses.............................................20
   11. Full Copyright Statement.......................................21

1.  Introduction

   Header compression is a technique used to compress and transparently
   decompress the header information of a packet on a per-hop basis,
   utilizing redundancy within individual packets and between
   consecutive packets within a packet stream.  Over the years, several
   protocols [VJHC, IPHC] have been developed to compress the network
   and transport protocol headers [IPv4, IPv6, UDP, TCP], and these
   schemes have been successful in improving efficiency over many wired
   bottleneck links, such as modem connections over telephone networks.
   In addition to IP, UDP, and TCP compression, an additional
   compression scheme called Compressed RTP [CRTP] has been developed to
   further improve compression efficiency for the case of real-time
   traffic using the Real-Time Transport Protocol [RTP].

   The schemes mentioned above have all been designed taking into
   account normal assumptions about link characteristics, which
   traditionally have been based on wired links only.  However, with an
   increasing number of wireless links in the Internet paths, these
   assumptions are no longer generally valid.  In wireless environments,
   especially wide coverage cellular environments, relatively high error
   rates are tolerated in order to allow efficient usage of the radio
   resources.  For real-time traffic, which is more sensitive to delays
   than to errors, such operating conditions will be norm over, for
   example, 3rd generation cellular links, and header compression must
   therefore tolerate packet loss.  However, with the previously
   mentioned schemes, especially for real-time traffic compressed by
   CRTP, high error rates have been shown to significantly degrade



Jonsson, et. al             Standards Track                     [Page 2]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


   header compression performance [CRTPC].  This problem was the driving
   force behind the creation of the RObust Header Compression (ROHC) WG
   in the IETF.

   The ROHC WG has developed a header compression framework on top of
   which profiles can be defined for different protocol sets, or for
   different compression strategies.  Due to the limited packet loss
   robustness of CRTP, and the demands of the cellular industry for an
   efficient way of transporting voice over IP over wireless, the main
   focus of ROHC has so far been on compression of IP/UDP/RTP headers,
   which are generous in size, especially compared to the payloads often
   carried by packets with such headers.

   ROHC RTP has become a very efficient, robust and capable compression
   scheme, able to compress the headers down to a total size of one
   octet only.  Also, transparency is guaranteed to an extremely great
   extent even when residual bit errors are present in compressed
   headers delivered to the decompressor.  The requirements for RTP
   compression [RTP-REQ], defined by the WG before and during the
   development process, have thus been fulfilled.

   As mentioned above, the 3rd generation cellular systems, where IP
   will be used end-to-end, have been one of the driving forces behind
   ROHC RTP, and the scheme has been designed to also suit new cellular
   air interfaces, such as WCDMA, making it possible to run even speech
   services with spectrum efficiency insignificantly lower than for
   existing one-service circuit switched solutions [VTC2000].  However,
   other air interfaces such as those based on GSM and IS-95 will also
   be used in all-IP networks, with further implications for the header
   compression issue.  These older air interfaces are less flexible,
   with radio bearers optimized for specific payload sizes.  This means
   that not even a single octet of header can be added without using the
   next higher fixed packet size supported by the link, something which
   is obviously very costly.  For the already deployed speech vocoders,
   the spectrum efficiency over these links will thus be low compared to
   existing circuit switched solutions.  To achieve high spectrum
   efficiency overall with any application, more flexible air interfaces
   must be deployed, and then the ROHC RTP scheme will perform
   excellently, as shown for WCDMA [MOMUC01].  However, for deployment
   reasons, it is however important to also provide a suitable header
   compression strategy for already existing vocoders and air
   interfaces, such as for GERAN and for CDMA2000, with minimal effects
   on spectral efficiency.

   This document defines a new link-layer assisted ROHC RTP profile
   extending ROHC RTP (profile 0x0001) [ROHC], compliant with the ROHC
   0-byte requirements [0B-REQ].  The purpose of this new profile is to
   provide a header-free packet format that, for a certain application



Jonsson, et. al             Standards Track                     [Page 3]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


   behavior, can replace a majority of the 1-octet header ROHC RTP
   packets during normal U/O-mode operation, while still being fully
   transparent and complying with all the requirements of ROHC RTP
   [RTP-REQ].  For other applications, compression will be carried out
   as with normal ROHC RTP.

   To completely eliminate the compressed header, all functionality
   normally provided by the 1-octet header has to be provided by other
   means, typically by utilizing functionality provided by the lower
   layers and sacrificing efficiency for less frequently occurring
   larger compressed headers.  The latter is not a contradiction since
   the argument for eliminating the last octet for most packets is not
   overall efficiency in general.  It is important to remember that the
   purpose of this profile is to provide efficient matching of existing
   applications to existing link technologies, not efficiency in
   general.  The additional complexity introduced by this profile,
   although minimized by a tight integration with already existing ROHC
   functionality, implies that it should therefore only be used to
   optimize performance of specific applications over specific links.

   When implementing this profile over various link technologies, care
   must be taken to guarantee that all the functionality needed is
   provided by ROHC and the lower layers together.  Therefore,
   additional documents should specify how to incorporate this profile
   on top of various link technologies.

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.

   CCP    Context Check Packet
   CRC    Cyclic Redundancy Check
   CSP    Context Synchronization Packet
   LLA    Link Layer Assisted ROHC RTP profile
   NHP    No Header Packet
   ROHC   RObust Header Compression
   RHP    ROHC Header Packet (a non-NHP packet, i.e., RRP, CSP or CCP)
   RRP    ROHC RTP Packet as defined in [ROHC, profile 0x0001]

   Assisting layer

      "Assisting layer" refers to any entity implementing the interface
      to ROHC (section 4.2).  It may, for example, refer to a sub-layer
      used to adapt the ROHC implementation and the physical link layer.
      This layer is assumed to have knowledge of the physical layer
      synchronization.



Jonsson, et. al             Standards Track                     [Page 4]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


   Compressing side

      "Compressing side" refers to the combination of the header
      compressor, operating with the LLA profile, and its associated
      assisting layer.

   Lower layers

      "Lower layers" in this document refers to entities located below
      ROHC in the protocol stack, including the assisting layer.

   ROHC RTP

      "ROHC RTP" in this document refers to the IP/UDP/RTP profile
      (profile 0x0001) as defined in [ROHC].

3.  Overview of the Link-Layer Assisted Profile

   The ROHC IP/UDP/RTP profile defined in this document, profile 0x0005
   (hex), is designed to be used over channels that have been optimized
   for specific payload sizes and therefore cannot efficiently
   accommodate header information when transmitted together with
   payloads corresponding to these optimal sizes.

   The LLA profile extends, and thus also inherits all functionality
   from, the ROCH RTP profile by defining some additional functionality
   and an interface from the ROHC component towards an assisting lower
   layer.

                  +---------------------------------------+
                  |                                       |
     The LLA      |    ROHC RTP,                          |
     profile      |    Profile #1       +-----------------+
                  |                     |  LLA Additions  |
                  +---------------------+-----------------+

   By imposing additional requirements on the lower layers compared to
   [ROHC], it is possible to infer the information needed to maintain
   robust and transparent header compression even though the headers are
   completely eliminated during most of the operation time.

   Basically, what this profile does is to replace the smallest and most
   frequent ROHC U/O-mode headers with a no-header format, for which the
   header functionality must be provided by other means.







Jonsson, et. al             Standards Track                     [Page 5]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


     Smallest header in                 Smallest header in
     ROHC RTP (profile #1)              LLA (profile #5)
   +--+--+--+--+--+--+--+--+              ++
   |        1 octet        |  ----->      ||  No Header
   +--+--+--+--+--+--+--+--+              ++
               |
               |                        Header field functionality
               +------------------->    provided by other means