rfc2507.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,547 行 · 第 1/5 页

      Carried by full and compressed non-TCP headers.

   Packet stream

      A sequence of packets whose headers are similar and share context.
      For example, headers in a TCP packet stream have the same source
      and final destination address, and the same port numbers in the
      TCP header.  Similarly, headers in a UDP packet stream have the
      same source and destination address, and the same port numbers in
      the UDP header.

   Full header (header refresh)

      An uncompressed header that updates or refreshes the context for a
      packet stream. It carries a CID that will be used to identify the
      context.

      Full headers for non-TCP packet streams also carry the generation
      of the context they update or refresh.

   Regular header

      A normal, uncompressed, header.  Does not carry CID or generation
      association.



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


   Incorrect decompression

      When a compressed and then decompressed header is different from
      the uncompressed header. Usually due to mismatching context
      between the compressor and decompressor or bit errors during
      transmission of the compressed header.

   Differential coding

      A compression technique where the compressed value of a header
      field is the difference between the current value of the field and
      the value of the same field in the previous header belonging to
      the same packet stream. A decompressor can thus obtain the value
      of the field by adding the value in the compressed header to its
      context.  This technique is used for TCP streams but not for non-
      TCP streams.

3.  Compression method

   Much of the header information stays the same over the life-time of a
   packet stream. For non-TCP packet streams almost all fields of the
   headers are constant. For TCP many fields are constant and others
   change with small and predictable values.

   To initiate compression of the headers of a packet stream, a full
   header carrying a context identifier, CID, is transmitted over the
   link.  The compressor and decompressor store most fields of this full
   header as context.  The context consists of the fields of the header
   whose values are constant and thus need not be sent over the link at
   all, or change little between consecutive headers so that it uses
   fewer bits to send the difference from the previous value compared to
   sending the absolute value.

   Any change in fields that are expected to be constant in a packet
   stream will cause the compressor to send a full header again to
   update the context at the decompressor. As long as the context is the
   same at compressor and decompressor, headers can be decompressed to
   be exactly as they were before compression. However, if a full header
   or compressed header is lost during transmission, the context of the
   decompressor may become obsolete as it is not updated properly.
   Compressed headers will then be decompressed incorrectly.

   IPv6 is not meant to be used over links that can deliver a
   significant fraction of damaged packets to the IPv6 module.  This
   means that links must have a very low bit-error rate or that link-
   level frames must be protected by strong checksums, forward error
   correction or something of that nature.  Header compression SHOULD
   not be used for IPv4 without strong link-level checksums.  Damaged



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


   frames will thus be discarded by the link layer.  The link layer
   implementation might indicate to the header compression module that a
   frame was damaged, but it cannot say what packet stream it belonged
   to as it might be the CID that is damaged.  Moreover, frames may
   disappear without the link layer implementation's knowledge, for
   example if the link is a multi-hop link where frames can be dropped
   due to congestion at each hop.  The kind of link errors that a header
   compression module should deal with and protect against will thus be
   packet loss.

   So a header compression scheme needs mechanisms to update the context
   at the decompressor and to detect or avoid incorrect decompression.
   These mechanisms are very different for TCP and non-TCP streams, and
   are described in sections 3.2 and 3.3.

   The compression mechanisms in this document assume that packets are
   not reordered between the compressor and decompressor.  If the link

   does reorder, section 11 describes mechanisms for ordering the
   packets before decompression.  It is also assumed that the link-layer
   implementation can provide the length of packets, and that there is
   no padding in UDP packets or tunneled packets.

3.1.  Packet types

   This compression method uses four packet types in addition to the
   IPv4 and IPv6 packet types.  The combination of link-level packet
   type and the value of the first four bits of the packet uniquely
   determines the packet type.  Details on how these packet types are
   represented are in section 13.

       FULL_HEADER - indicates a packet with an uncompressed header,
       including a CID and, if not a TCP packet, a generation.  It
       establishes or refreshes the context for the packet stream
       identified by the CID.

       COMPRESSED_NON_TCP - indicates a non-TCP packet with a compressed
       header. The compressed header consists of a CID identifying what
       context to use for decompression, a generation to detect an
       inconsistent context and the randomly changing fields of the
       header.

       COMPRESSED_TCP - indicates a packet with a compressed TCP header,
       containing a CID, a flag octet indentifying what fields have
       changed, and the changed fields encoded as the difference from
       the previous value.





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


       COMPRESSED_TCP_NODELTA - indicates a packet with a compressed TCP
       header where all fields that are normally sent as the difference
       to the previous value are instead sent as-is.  This packet type
       is only sent as the response to a header request from the
       decompressor. It must not be sent as the result of a
       retransmission.

   In addition to the packet types used for compression, regular IPv4
   and IPv6 packets are used whenever a compressor decides to not
   compress a packet.  An additional packet type may be used to speed up
   repair of TCP streams over links where the decompressor can send
   packets to the compressor.

       CONTEXT_STATE - indicates a special packet sent from the
       decompressor to the compressor to communicate a list of (TCP)
       CIDs for which synchronization has been lost. This packet is only
       sent over a single link so it requires no IP header. The format
       is shown in section 10.2.

3.2.  Lost packets in TCP packet streams

   Since TCP headers are compressed using the difference from the
   previous TCP header, loss of a packet with a compressed or full
   header will cause subsequent compressed headers to be decompressed
   incorrectly because the context used for decompression was not
   incremented properly.

   Loss of a compressed TCP header will cause the TCP sequence numbers
   of subsequently decompressed TCP headers to be off by k, where k is
   the size of the lost segment.  Such incorrectly decompressed TCP
   headers will be discarded by the TCP receiver as the TCP checksum
   reliably catches "off-by-k" errors in the sequence numbers for
   plausible k.

   TCP's repair mechanisms will eventually retransmit the discarded
   segment and the compressor peeks into the TCP headers to detect when
   TCP retransmits.  When this happens, the compressor sends a full
   header on the assumption that the retransmission was due to
   mismatching compression state at the decompressor.  [RFC-1144] has a
   good explanation of this mechanism.

   The mechanisms of section 10 should be used to speed up the repair of
   the context.  This is important over medium speed links with high
   packet loss rates, for example wireless.  Losing a timeout's worth of
   packets due to inconsistent context after each packet lost over the
   link is not acceptable, especially when the TCP connection is over
   the wide area.




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


3.3.  Lost packets in UDP and other non-TCP packet streams

   Incorrectly decompressed headers of UDP packets and other non-TCP
   packets are not so well-protected by checksums as TCP packets.  There
   are no sequence numbers that become "off-by-k" and virtually
   guarantees a failed checksum as there are for TCP. The UDP checksum
   only covers payload, UDP header, and pseudo header.  The pseudo
   header includes the source and destination addresses, the transport
   protocol type and the length of the transport packet.  Except for
   those fields, large parts of the IPv6 header are not covered by the
   UDP checksum.  Moreover, other non-TCP headers lack checksums
   altogether, for example fragments.

   In order to safely avoid incorrect decompression of non-TCP headers,
   each version of the context for non-TCP packet streams is identified
   by a generation, a small number that is carried by the full headers
   that establish and refresh the context.  Compressed headers carry the
   generation value of the context that were used to compress them.
   When a decompressor sees that a compressed header carries a
   generation value other than the generation of its context for that
   packet stream, the context is not up to date and the packet must be
   discarded or stored until a full header establishes correct context.

   Differential coding is not used for non-TCP streams, so compressed
   non-TCP headers do not change the context.  Thus, loss of a
   compressed header does not invalidate subsequent packets with
   compressed headers. Moreover, the generation changes only when the
   context of a full header is different from the context of the
   previous full header. This means that losing a full header will make
   the context of the decompressor obsolete only when the full header
   would actually have changed the context.

   The generation field is 6 bits long so the generation value repeats
   itself after 64 changes to the context. To avoid incorrect
   decompression after error bursts or other temporary disruptions, the
   compressor must not reuse the same generation value after a shorter
   time than MIN_WRAP seconds. A decompressor which has been
   disconnected MIN_WRAP seconds or more must wait for the next full
   header before decompressing. A compressor must wait at least MIN_WRAP
   seconds after booting before compressing non-TCP headers. Instead of
   reusing a generation value too soon, a compressor may switch to
   another CID or send regular headers until MIN_WRAP seconds have
   passed.  The value of MIN_WRAP is found in section 14.








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


3.3.1.  Compression Slow-Start

   To allow the decompressor to recover quickly from loss of a full
   header that would have changed the context, full headers are sent
   periodically with an exponentially increasing period after a change
   in the context. This technique avoids an exchange of messages between
   compressor and decompressor used by other compression schemes, such
   as in [RFC-1553]. Such exchanges can be costly for wireless mobiles
   as more power is consumed by the transmitter and delay can be
   introduced by switching between sending and receiving.  Moreover,
   techniques that require an exchange of messages cannot be used over
   simplex links, such as direct-broadcast satellite channels or cable
   TV systems, and are hard to adapt to multicast over multi-access
   links.

    |.|..|....|........|................|..............................
    ^
    Change   Sent packets: | with full header, . with compressed header

   The picture shows how packets are sent after change.  The compressor
   keeps a variable for each non-TCP packet stream, F_PERIOD, that keeps
   track of how many compressed headers may be sent between full
   headers.  When the headers of a non-TCP packet stream change so that
   its context changes, a full header is sent and F_PERIOD is set to
   one. After sending F_PERIOD compressed headers, a full header is
   sent.  F_PERIOD is doubled each time a full header is sent during
   compression slow-start.

3.3.2.  Periodic Header Refreshes

   To avoid losing too many packets if a receiver has lost its context,
   there is an upper limit, F_MAX_PERIOD, on the number of non-TCP
   packets with compressed headers that may be sent between header
   refreshes. If a packet is to be sent and F_MAX_PERIOD compressed
   headers have been sent since the last full header for this packet
   stream was sent, a full header must be sent.

   To avoid long periods of disconnection for low data rate packet
   streams, there is also an upper bound, F_MAX_TIME, on the time
   between full headers in a non-TCP packet stream. If a packet is to be
   sent and more than F_MAX_TIME seconds have passed since the last full
   header was sent for this packet stream, a full header must be sent.
   The values of F_MAX_PERIOD and F_MAX_TIME are found in section 14.








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