rfc2507.txt

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

Network Working Group                                       M. Degermark
Request for Comments: 2507           Lulea University of Technology/SICS
Category: Standards Track                                    B. Nordgren
                        Lulea University of Technology/Telia Research AB
                                                                 S. Pink
                                     Lulea University of Technology/SICS
                                                           February 1999


                         IP Header Compression

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

Abstract

   This document describes how to compress multiple IP headers and TCP
   and UDP headers per hop over point to point links. The methods can be
   applied to of IPv6 base and extension headers, IPv4 headers, TCP and
   UDP headers, and encapsulated IPv6 and IPv4 headers.

   Headers of typical UDP or TCP packets can be compressed down to 4-7
   octets including the 2 octet UDP or TCP checksum. This largely
   removes the negative impact of large IP headers and allows efficient
   use of bandwidth on low and medium speed links.

   The compression algorithms are specifically designed to work well
   over links with nontrivial packet-loss rates. Several wireless and
   modem technologies result in such links.

TABLE OF CONTENTS

   1.  Introduction..............................................3
   2.  Terminology...............................................5
   3.  Compression method........................................7
        3.1.  Packet types.......................................8
        3.2.  Lost packets in TCP packet streams.................9
        3.3.  Lost packets in UDP and non-TCP packet streams....10
   4.  Grouping packets into packet streams.....................14



Degermark, et. al.          Standards Track                     [Page 1]

RFC 2507                 IP Header Compression             February 1999


        4.1.  Guidelines for grouping packets...................15
   5.  Size Issues..............................................16
        5.1.  Context identifiers...............................16
        5.2.  Size of the context...............................17
        5.3.  Size of full headers..............................18
           5.3.1.  Length fields in full TCP headers............19
           5.3.2.  Length fields in full non-TCP headers........19
   6.  Compressed Header Formats................................20
   7.  Compression of subheaders................................22
        7.1.  IPv6 Header.......................................24
        7.2.  IPv6 Extension Headers............................25
        7.3.  Options...........................................25
        7.4.  Hop-by-hop Options Header.........................26
        7.5.  Routing Header....................................26
        7.6.  Fragment Header...................................27
        7.7.  Destination Options Header........................28
        7.8.  No Next Header....................................29
        7.9.  Authentication Header.............................29
        7.10. Encapsulating Security Payload Header.............29
        7.11. UDP Header........................................30
        7.12. TCP Header........................................30
        7.13. IPv4 Header.......................................33
        7.14  Minimal Encapsulation header......................34
   8.  Changing context identifiers.............................35
   9.  Rules for dropping or temporarily storing packets........35
   10. Low-loss header compression for TCP .....................36
        10.1.  The "twice" algorithm............................37
        10.2.  Header Requests..................................37
   11. Links that reorder packets...............................38
        11.1.  Reordering in non-TCP packet streams.............39
        11.2.  Reordering in TCP packet streams.................39
   12. Hooks for additional header compression..................40
   13. Demultiplexing...........................................41
   14. Configuration Parameters.................................42
   15. Implementation Status....................................43
   16. Acknowledgments..........................................44
   17. Security Considerations..................................44
   18. Authors' Addresses.......................................45
   19. References...............................................46
   20. Full Copyright Statement.................................47











Degermark, et. al.          Standards Track                     [Page 2]

RFC 2507                 IP Header Compression             February 1999


1.  Introduction

   There are several reasons to do header compression on low- or
   medium-speed links. Header compression can

   *  Improve interactive response time

      For very low-speed links, echoing of characters may take longer
      than 100-200 ms because of the time required to transmit large
      headers. 100-200 ms is the maximum time people can tolerate
      without feeling that the system is sluggish.

   * Allow using small packets for bulk data with good line efficiency

      This is important when interactive (for example Telnet) and bulk
      traffic (for example FTP) is mixed because the bulk data should be
      carried in small packets to decrease the waiting time when a
      packet with interactive data is caught behind a bulk data packet.

      Using small packet sizes for the FTP traffic in this case is a
      global solution to a local problem. It will increase the load on
      the network as it has to deal with many small packets. A better
      solution might be to locally fragment the large packets over the
      slow link.

   * Allow using small packets for delay sensitive low data-rate traffic

      For such applications, for example voice, the time to fill a
      packet with data is significant if packets are large.  To get low
      end-to-end delay small packets are preferred.  Without header
      compression, the smallest possible IPv6/UDP headers (48 octets)
      consume 19.2 kbit/s with a packet rate of 50 packets/s.  50
      packets/s is equivalent to having 20 ms worth of voice samples in
      each packet. IPv4/UDP headers consumes 11.2 kbit/s at 50
      packets/s.  Tunneling or routing headers, for example to support
      mobility, will increase the bandwidth consumed by headers by 10-20
      kbit/s.  This should be compared with the bandwidth required for
      the actual sound samples, for example 13 kbit/s with GSM encoding.
      Header compression can reduce the bandwidth needed for headers
      significantly, in the example to about 1.7 kbit/s. This enables
      higher quality voice transmission over 14.4 and 28.8 kbit/s
      modems.

   *  Decrease header overhead.

      A common size of TCP segments for bulk transfers over medium-speed
      links is 512 octets today. When TCP segments are tunneled, for
      example because Mobile IP is used, the IPv6/IPv6/TCP header is 100



Degermark, et. al.          Standards Track                     [Page 3]

RFC 2507                 IP Header Compression             February 1999


      octets.  Header compression will decrease the header overhead for
      IPv6/TCP from 19.5 per cent to less than 1 per cent, and for
      tunneled IPv4/TCP from 11.7 to less than 1 per cent. This is a
      significant gain for line-speeds as high as a few Mbit/s.

      The IPv6 specification prescribes path MTU discovery, so with IPv6
      bulk TCP transfers should use segments larger than 512 octets when
      possible.  Still, with 1400 octet segments (RFC 894 Ethernet
      encapsulation allows 1500 octet payloads, of which 100 octets are
      used for IP headers), header compression reduces IPv6 header
      overhead from 7.1% to 0.4%.

   *  Reduce packet loss rate over lossy links.

      Because fewer bits are sent per packet, the packet loss rate will
      be lower for a given bit-error rate. This results in higher
      throughput for TCP as the sending window can open up more between
      losses, and in fewer lost packets for UDP.

   The mechanisms described here are intended for a point-to-point link.
   However, care has been taken to allow extensions for multi-access
   links and multicast.

   Headers that can be compressed include TCP, UDP, IPv4, and IPv6 base
   and extension headers.  For TCP packets, the mechanisms of Van
   Jacobson [RFC-1144] are used to recover from loss. Two additional
   mechanisms that increase the efficiency of VJ header compression over
   lossy links are also described.  For non-TCP packets, compression
   slow-start and periodic header refreshes allow minimal periods of
   packet discard after loss of a header that changes the context. There
   are hooks for adding header compression schemes on top of UDP, for
   example compression of RTP headers.

   Header compression relies on many fields being constant or changing
   seldomly in consecutive packets belonging to the same packet stream.
   Fields that do not change between packets need not be transmitted at
   all.  Fields that change often with small and/or predictable values,
   e.g., TCP sequence numbers, can be encoded incrementally so that the
   number of bits needed for these fields decrease significantly.  Only
   fields that change often and randomly, e.g., checksums or
   authentication data, need to be transmitted in every header.

   The general principle of header compression is to occasionally send a
   packet with a full header; subsequent compressed headers refer to the
   context established by the full header and may contain incremental
   changes to the context.





Degermark, et. al.          Standards Track                     [Page 4]

RFC 2507                 IP Header Compression             February 1999


   This header compression scheme does not require that all packets in
   the same stream passes over the compressed link. However, for TCP
   streams the difference between subsequent headers can become more
   irregular and the compression rate can decrease. Neither is it
   required that corresponding TCP data and acknowledgment packets
   traverse the link in opposite directions.

   This header compression scheme is useful on first-hop or last-hop
   links as well as links in the middle of the network. When many packet
   streams (several hundred) traverse the link, a phenomenon that could
   be called CID thrashing could occur, where headers seldom can be
   matched with an existing context and have to be sent uncompressed or
   as full headers. It is up to an implementation to use techniques such
   as hysteresis to ensure that the packet streams that give the highest
   compression rates keep their context.  Such techniques are more
   likely to be needed in the middle of the network.

2.  Terminology

   This section explains some terms used in this document.

   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.

   Subheader

      An IPv6 base header, an IPv6 extension header, an IPv4 header, a
      UDP header, or a TCP header.

   Header

      A chain of subheaders.

   Compress

      The act of reducing the size of a header by removing header fields
      or reducing the size of header fields. This is done in a way such
      that a decompressor can reconstruct the header if its context
      state is identical to the context state used when compressing the
      header.

   Decompress

      The act of reconstructing a compressed header.






Degermark, et. al.          Standards Track                     [Page 5]

RFC 2507                 IP Header Compression             February 1999


   Context identifier (CID)

      A small unique number identifying the context that should be used
      to decompress a compressed header.  Carried in full headers and
      compressed headers.

   Context

      The state which the compressor uses to compress a header and the
      decompressor uses to decompress a header.  The context is the
      uncompressed version of the last header sent (compressor) or
      received (decompressor) over the link, except for fields in the
      header that are included "as-is" in compressed headers or can be
      inferred from, e.g., the size of the link-level frame.

      The context for a packet stream is associated with a context
      identifier.  The context for non-TCP packet streams is also