rfc2393.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页

Network Working Group                                         A. Shacham
Request for Comments: 2393                                         Cisco
Category: Standards Track                                     R. Monsour
                                                                   Hi/fn
                                                              R. Pereira
                                                                TimeStep
                                                               M. Thomas
                                                      AltaVista Internet
                                                           December 1998


                IP Payload Compression Protocol (IPComp)

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 (1998).  All Rights Reserved.

Abstract

   This document describes a protocol intended to provide lossless
   compression for Internet Protocol datagrams in an Internet
   environment.

1. Introduction

   IP payload compression is a protocol to reduce the size of IP
   datagrams.  This protocol will increase the overall communication
   performance between a pair of communicating hosts/gateways ("nodes")
   by compressing the datagrams, provided the nodes have sufficient
   computation power, through either CPU capacity or a compression
   coprocessor, and the communication is over slow or congested links.

   IP payload compression is especially useful when encryption is
   applied to IP datagrams.  Encrypting the IP datagram causes the data
   to be random in nature, rendering compression at lower protocol
   layers (e.g., PPP Compression Control Protocol [RFC-1962])
   ineffective.  If both compression and encryption are required,
   compression MUST be applied before encryption.





Shacham, et. al.            Standards Track                     [Page 1]

RFC 2393                         IPComp                    December 1998


   This document defines the IP payload compression protocol (IPComp),
   the IPComp packet structure, the IPComp Association (IPCA), and
   several methods to negotiate the IPCA.

   Other documents shall specify how a specific compression algorithm
   can be used with the IP payload compression protocol.  Such
   algorithms are beyond the scope of this document.

1.1. Specification of Requirements

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

2. Compression Process

   The compression processing of IP datagrams has two phases:
   compressing of outbound IP datagrams ("compression") and
   decompressing of inbound datagrams ("decompression").  The
   compression processing MUST be lossless, ensuring that the IP
   datagram, after being compressed and decompressed, is identical to
   the original IP datagram.

   Each IP datagram is compressed and decompressed by itself without any
   relation to other datagrams ("stateless compression"), as IP
   datagrams may arrive out of order or not arrive at all.  Each
   compressed IP datagram encapsulates a single IP payload.

   Processing of inbound IP datagrams MUST support both compressed and
   non-compressed IP datagrams, in order to meet the non-expansion
   policy requirements, as defined in section 2.2.

   The compression of outbound IP datagrams MUST be done before any IP
   security processing, such as encryption and authentication, and
   before any fragmentation of the IP datagram.  In addition, in IP
   version 6 [RFC-2460], the compression of outbound IP datagrams MUST
   be done before the addition of either a Hop-by-Hop Options header or
   a Routing Header, since both carry information that must be examined
   and processed by possibly every node along a packet's delivery path,
   and therefore MUST be sent in the original form.

   Similarly, the decompression of inbound IP datagrams MUST be done
   after the reassembly of the IP datagrams, and after the completion of
   all IP security processing, such as authentication and decryption.







Shacham, et. al.            Standards Track                     [Page 2]

RFC 2393                         IPComp                    December 1998


2.1. Compressed Payload

   The compression is applied to a single array of octets, which are
   contiguous in the IP datagram.  This array of octets always ends at
   the last octet of the IP packet payload.  Note: a contiguous array of
   octets in the IP datagram may be not contiguous in physical memory.

   In IP version 4 [RFC-0791], the compression is applied to the upper
   layer protocol (ULP) payload of the IP datagram.  No portion of the
   IP header or the IP header options is compressed.

   In the IPv6 context, IPComp is viewed as an end-to-end payload, and
   MUST not apply to hop-by-hop, routing, and fragmentation extension
   headers.  The compression is applied starting at the first IP Header
   Option field that does not carry information that must be examined
   and processed by nodes along a packet's delivery path, if such IP
   Header Option field exists, and continues to the ULP payload of the
   IP datagram.

   The size of a compressed payload, generated by the compression
   algorithm, MUST be in whole octet units.

   As defined in section 3, an IPComp header is inserted immediately
   preceding the compressed payload.  The original IP header is modified
   to indicate the usage of the IPComp protocol and the reduced size of
   the IP datagram.  The original content of the Next Header (IPv6) or
   protocol (IPv4) field is stored in the IPComp header.

   The decompression is applied to a single contiguous array of octets
   in the IP datagram.  The start of the array of octets immediately
   follows the IPComp header and ends at the last octet of the IP
   payload.  If the decompression process is successfully completed, the
   IP header is modified to indicate the size of the decompressed IP
   datagram, and the original next header as stored in the IPComp
   header.  The IPComp header is removed from the IP datagram and the
   decompressed payload immediately follows the IP header.

2.2. Non-Expansion Policy

   If the total size of a compressed ULP payload and the IPComp header,
   as defined in section 3, is not smaller than the size of the original
   ULP payload, the IP datagram MUST be sent in the original non-
   compressed form.  To clarify:  If an IP datagram is sent non-
   compressed, no IPComp header is added to the datagram.  This policy
   ensures saving the decompression processing cycles and avoiding
   incurring IP datagram fragmentation when the expanded datagram is
   larger than MTU.




Shacham, et. al.            Standards Track                     [Page 3]

RFC 2393                         IPComp                    December 1998


   Small IP datagrams are likely to expand as a result of compression.
   Therefore, a numeric threshold should be applied before compression,
   where IP datagrams of size smaller than the threshold are sent in the
   original form without attempting compression.  The numeric threshold
   is implementation dependent.

   An IP datagram with payload that has been previously compressed tends
   not to compress any further.  The previously compressed payload may
   be the result of external processes, such as compression applied by
   an upper layer in the communication stack, or by an off-line
   compression utility.  An adaptive algorithm should be implemented to
   avoid the performance hit.  For example, if the compression of i
   consecutive IP datagrams of an IPCA fails, the next k IP datagrams
   are sent without attempting compression.  If the next j datagrams are
   also failing to compress, the next k+n datagrams are sent without
   attempting compression.  Once a datagram is compressed successfully,
   the normal process of IPComp restarts.  Such an adaptive algorithm,
   including all the related thresholds, is implementation dependent.

   During the processing of the payload, the compression algorithm MAY
   periodically apply a test to determine the compressibility of the
   processed data, similar to the requirements of [V42BIS].  The nature
   of the test is algorithm dependent.  Once the compression algorithm
   detects that the data is non-compressible, the algorithm SHOULD stop
   processing the data, and the payload is sent in the original non-
   compressed form.

3. Compressed IP Datagram Header Structure

   A compressed IP datagram is encapsulated by modifying the IP header
   and inserting an IPComp header immediately preceding the compressed
   payload.  This section defines the IP header modifications both in
   IPv4 and IPv6, and the structure of the IPComp header.

3.1. IPv4 Header Modifications

   The following IPv4 header fields are set before transmitting the
   compressed IP datagram:

      Total Length

         The length of the entire encapsulated IP datagram, including
         the IP header, the IPComp header and the compressed payload.

      Protocol

         The Protocol field is set to 108, IPComp Datagram, [RFC-1700].




Shacham, et. al.            Standards Track                     [Page 4]

RFC 2393                         IPComp                    December 1998


      Header Checksum

         The Internet Header checksum [RFC-0791] of the IP header.

   All other IPv4 header fields are kept unchanged, including any header
   options.

3.2. IPv6 Header Modifications

   The following IPv6 header fields are set before transmitting the
   compressed IP datagram:

      Payload Length

         The length of the compressed IP payload.

      Next Header

         The Next Header field is set to 108, IPComp Datagram, [RFC-
         1700].

   All other IPv6 header fields are kept unchanged, including any non-
   compressed header options.

   The IPComp header is placed in an IPv6 packet using the same rules as
   the IPv6 Fragment Header.  However if an IPv6 packet contains both an
   IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header
   MUST precede the IPComp header in the packet.

3.3.  IPComp Header Structure

   The four-octet header has the following structure:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |     Flags     | Compression Parameter Index |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header

        8-bit selector.  Stores the IPv4 Protocol field or the IPv6 Next
        Header field of the original IP header.

   Flags

        8-bit field.  Reserved for future use.  MUST be set to zero.
        MUST be ignored by the receiving node.



Shacham, et. al.            Standards Track                     [Page 5]