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

Versions: (draft-jonsson-rohc-ip-only) 00 01 02 03 04 05 RFC 3843

Network Working Group                                       L-E. Jonsson
INTERNET-DRAFT                                                  Ericsson
Expires: July 2003                                      January 23, 2003






                    RObust Header Compression (ROHC):
                       A Compression Profile for IP
                     <draft-ietf-rohc-ip-only-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 the ROHC WG mailing list, rohc@ietf.org.


Abstract

   The original RObust Header Compression (ROHC) RFC, RFC 3095, defines
   a framework for header compression, along with compression protocols
   (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for
   uncompressed packet streams. However, no profile was defined for
   compression of IP only, which has been identified as a missing piece
   in RFC 3095. This document defines a ROHC compression profile for IP,
   similar to the IP/UDP profile defined by RFC 3095, but simplified to
   exclude UDP, and enhanced to compress IP header chains of arbitrary
   length.




Jonsson                                                         [Page 1]


INTERNET-DRAFT            A ROHC Profile for IP         January 23, 2003


Table of Contents

   1.  Introduction..................................................2
   2.  Terminology...................................................3
   3.  ROHC IP Compression (Profile 0x0004)..........................3
        3.1.  Static chain termination and multiple IP headers.......3
        3.2.  Initialization.........................................4
        3.3.  Packet types...........................................5
   4.  Security Considerations.......................................6
   5.  IANA Considerations...........................................6
   6.  Acknowledgements..............................................6
   7.  References....................................................6
   8.  Author's Address..............................................7

1.  Introduction

   The original RObust Header Compression (ROHC) RFC [RFC-3095] defines
   a framework for header compression, along with compression protocols
   (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for
   uncompressed packet streams. The profile for uncompressed data was
   defined to provide means to encapsulate all traffic over a link
   within ROHC packets. Through this profile, the lower layers do not
   have to provide multiplexing for different packet types, but instead
   ROHC can handle any packet stream, even if compression profiles for
   all kinds of packet streams have yet not been defined or implemented
   over the link.

   Although the profile without compression is simple and can tunnel
   arbitrary packets, it has of course a major weakness in that it does
   not compress the headers at all. When considering that normally all
   packets are expected to be IP [RFC-791, RFC-2460] packets, and that
   the IP header often represent a major part of the total header, a
   useful alternative to no compression would for most packets be
   compression of the IP header only. Unfortunately, such a profile was
   not defined in [RFC-3095], and this has thus been identified as an
   important missing piece in the ROHC toolbox.

   This document addresses this missing compression support and defines
   a ROHC compression profile for IP [RFC-791, RFC-2460] only, similar
   to the IP/UDP profile defined by [RFC-3095], but simplified to
   exclude UDP. Due to the similarities with the IP/UDP profile, the IP
   compression profile is described based on the IP/UDP profile, mainly
   covering differences. The most important differences are a different
   way of terminating the static header chain, and the capability to
   compress IP header chains of arbitrary length.









Jonsson                                                         [Page 2]


INTERNET-DRAFT            A ROHC Profile for IP         January 23, 2003


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 [RFC-2119].

   ROHC UDP

       "ROHC UDP" in this document refers to the IP/UDP profile
       (Profile 0x0002) as defined in [RFC-3095].

3.  ROHC IP Compression (Profile 0x0004)

   In general, there are no major difference between the ROHC UDP
   profile and the IP profile (ROHC IP) defined in this document, since
   the removal of UDP has no impact on the compression mechanisms. As
   for ROHC UDP, the compressor generates a 16-bit sequence number which
   increases by one for each packet compressed in the packet stream,
   simply called SN below. The most important difference between this
   profile and ROHC UDP is about static chain termination and handling
   of multiple IP headers. Unless stated explicitly below, mechanisms
   and formats are as for ROHC UDP.

3.1.  Static chain termination and multiple IP headers

   The most important difference for IP-only compression, compared to
   IP/UDP compression, is about how to terminate compression, i.e. how
   to end the static chain in IR headers. For the UDP profile, the chain
   always ends with a UDP header part, which per definition terminates
   compression, and the UDP header is also the last header in the
   uncompressed packet (except for potential application header). For
   the case of IP-only compression, there is no single last header that
   per profile definition terminates the chain. Instead, the static
   chain is terminated if the "Next Header / Protocol" field of a static
   IP header part indicates anything but IP (IPinIP or IPv6).

   Another difference with IP-only compression is related to the
   potential compression of multiple IP headers. ROHC UDP can compress
   at most two IP headers, but additional IP headers would completely
   disable the use of header compression, since the compressed chain
   must end with the UDP header part. However, as there is no single
   packet type that ends the compressed chain with the IP profile,
   additional IP headers would not have to cause header compression to
   be disabled. By implicitly terminating the chain after at most 2 IP
   headers, additional IP headers could just be left uncompressed.

   The IP profile defined in this document goes one step further, and
   supports compression of an arbitrary number of IP headers. The static
   chain can obviously be of an arbitrary length, and is simply
   terminated through the presence of a non-IP header (not IPinIP nor
   IPv6). The dynamic chain is structured analogously. In compressed



Jonsson                                                         [Page 3]


INTERNET-DRAFT            A ROHC Profile for IP         January 23, 2003


   packet headers, header information related to the initial two IP
   headers are carried as in the IP/UDP profile, while a dynamic header
   chain is added at the end of the compressed header for each and every
   additional IP header. The data structure used for these header
   portions in compressed headers is thus exactly the same as the one
   used in IR and IR-DYN packets.

   The following sections describe how the IP profile differs from the
   IP/UDP profile, providing the details of the general principles
   described in the previous paragraph.

3.2.  Initialization

   The static context for ROHC IP compression can be initialized in
   either of two ways:

   1) By using an IR packet as in ROHC UDP, where the profile is
      0x0004, and the static chain ends with the static part of an
      IP header, where the Next Header/Protocol field has any value but
      IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is
      initialized to a random value when the first IR packet is sent.

   2) By reusing an existing context. This is done with an IR-DYN
      packet, identifying profile 0x0004, where the dynamic chain
      corresponds to the prefix of the existing static chain, ending
      with an IP header where the Next Header/Protocol field has any
      value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor,
      SN is initialized to a random value when the first IR-DYN packet
      is sent.

   For ROHC IP, the dynamic part of an IR or IR-DYN packet is similar to
   the one for ROHC UDP, with a two-octet field containing the SN
   present at the end of the dynamic chain in IR and IR-DYN packets. It
   should be noted that the static and dynamic chains have an arbitrary
   length, and the SN is added only once, at the end of the dynamic
   chain in IR and IR-DYN packets. Note further that additional dynamic
   chains in compressed packets do not have this sequence number at the
   end of the chain, as SN is present within compressed base headers.
















Jonsson                                                         [Page 4]


INTERNET-DRAFT            A ROHC Profile for IP         January 23, 2003


3.3.  Packet types

   The only packet format that differs from ROHC UDP is the general
   format for compressed packets, which has no UDP checksum in the end.
   Instead, it ends with a list of dynamic header portions, one for each
   IP header above the initial two (if any, as indicated by the presence
   of corresponding header portions in the static chain).

   The general format for a compressed header is thus as follows:

     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         :                    |
   +---+---+---+---+---+---+---+---+                    |
   |   first octet of base header  |                    |
   +---+---+---+---+---+---+---+---+                    |
   :                               :                    |
   /   0, 1, or 2 octets of CID    /                    |
   :                               :                    |
   +---+---+---+---+---+---+---+---+                    |
   /   remainder of base header    /                    |
   +---+---+---+---+---+---+---+---+                    |
   :                               :                    |
   /           Extension           /                    |
   :                               :                    |
    --- --- --- --- --- --- --- ---                     |
   :                               :                    |
   +   IP-ID of outer IPv4 header  +
   :                               :     (see section 5.7 or [RFC-3095])
    --- --- --- --- --- --- --- ---
   /    AH data for outer list     /                    |
    --- --- --- --- --- --- --- ---                     |
   :                               :                    |
   +         GRE checksum          +                    |
   :                               :                    |
    --- --- --- --- --- --- --- ---                     |
   :                               :                    |
   +   IP-ID of inner IPv4 header  +                    |
   :                               :                    |
    --- --- --- --- --- --- --- ---                     |
   /    AH data for inner list     /                    |
    --- --- --- --- --- --- --- ---                     |
   :                               :                    |
   +         GRE checksum          +                    |
   :                               :                    |
    --- --- --- --- --- --- --- ---
   :            List of            :
   /        Dynamic chains         /    variable, given by static chain
   :   for additional IP headers   :           (includes no SN)
    --- --- --- --- --- --- --- ---




Jonsson                                                         [Page 5]


INTERNET-DRAFT            A ROHC Profile for IP         January 23, 2003


4.  Security Considerations

   The security considerations of [RFC-3095] apply equally to this
   document, without exceptions or additions.

5.  IANA Considerations

   ROHC profile identifier 0x0004 has been reserved by the IANA for the
   profile defined in this document.

   { NOTE TO IANA - TO BE REMOVED BEFORE PUBLICATION }

      A ROHC profile identifier must be reserved by the IANA for the
      profile defined in this document. Profile number 0x0004 has
      previously been saved for this purpose, and should thus be used.
      As for previous ROHC profiles, profile numbers 0xnn04 must also be
      reserved for future variants of this profile. A suggested
      registration in the "RObust Header Compression (ROHC) Profile
      Identifiers" name space would then be:

      OLD:   0xnn04         To be Assigned by IANA

      NEW:   0x0004         ROHC IP                    [RFCXXXX (this)]
             0xnn04         Reserved

   { END OF NOTE }

6.  Acknowledgements

   The author would like to thank Carsten Bormann and Ghyslain Pelletier
   for valuable input and review.

7.  References

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.

   [RFC-3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima,
               H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
               Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
               K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust
               Header Compression (ROHC)", RFC 3095, July 2001.

   [RFC-791]   Postel, J., "Internet Protocol", RFC 791, September 1981.

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

   [PROTOCOL]  "Assigned Internet Protocol Numbers", IANA registry at:
               http://www.iana.org/assignments/protocol-numbers




Jonsson                                                         [Page 6]


INTERNET-DRAFT            A ROHC Profile for IP         January 23, 2003


8.  Author's Address

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















































Jonsson                                                         [Page 7]


INTERNET-DRAFT            A ROHC Profile for IP         January 23, 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.







This Internet-Draft expires July 23, 2003.



















Jonsson                                                         [Page 8]


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