rfc2507.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,547 行 · 第 1/5 页

3.3.3. Rules for sending Full Headers

   The following pseudo code can be used by the compressor to determine
   when to send a full header for a non-TCP packet stream.  The code
   maintains two variables:

         C_NUM       -- a count of the number of compressed headers sent
                        since the last full header was sent.
         F_LAST      -- the time of sending the last full header.

   and uses the functions

         current_time()       return the current time
         min(a,b)             return the smallest of a and b

      the procedures send_full_header(), increment_generation_value(),
      and send_compressed_header()
      do the obvious thing.

         if ( <this header changes the context> )

             C_NUM := 0;
             F_LAST := current_time();
             F_PERIOD := 1;
             increment_generation_value();
             send_full_header();

         elseif ( C_NUM >= F_PERIOD )

             C_NUM := 0;
             F_LAST := current_time();
             F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD);
             send_full_header();

         elseif ( current_time() > F_LAST + F_MAX_TIME )

             C_NUM := 0;
             F_LAST := current_time();
             send_full_header();

         else

             C_NUM := C_NUM + 1
             send_compressed_header();

         endif





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


3.3.4.  Cost of sending Header Refreshes

   If every f'th packet carries a full header, H is the size of a full
   header, and C is the size of a compressed header, the average header
   size is

                 (H-C)/f + C

   For f > 1, the average header size is (H-C)/f larger than a
   compressed header.

   In a diagram where the average header size is plotted for various f
   values, there is a distinct knee in the curve, i.e., there is a limit
   beyond which further increasing f gives diminishing returns.
   F_MAX_PERIOD should be chosen to be a frequency well to the right of
   the knee of the curve.  For typical sizes of H and C, say 48 octets
   for the full header (IPv6/UDP) and 4 octets for the compressed
   header, setting F_MAX_PERIOD > 44 means that full headers will
   contribute less than an octet to the average header size. With a
   four-address routing header, F_MAX_PERIOD > 115 will have the same
   effect.

   The default F_MAX_PERIOD value of 256 (section 14) puts the full
   header frequency well to the right of the knee and means that full
   headers will typically contribute considerably less than an octet to
   the average header size.  For H = 48 and C = 4, full headers
   contribute about 1.4 bits to the average header size after reaching
   the steady-state header refresh frequency determined by the default

   F_MAX_PERIOD. 1.4 bits is a very small overhead.

   After a change in the context, the exponential backoff scheme will
   initially send full headers frequently.  The default F_MAX_PERIOD
   will be reached after nine full headers and 255 compressed headers
   have been sent.  This is equivalent to a little over 5 seconds for a
   typical voice stream with 20 ms worth of voice samples per packet.

   During the whole backoff period, full headers contribute 1.5 octets
   to the average header size when H = 48 and C = 4.  For 20 ms voice
   samples, it takes less than 1.3 seconds until full headers contribute
   less than one octet to the average header size, and during these
   initial 1.3 seconds full headers add less than 4 octets to the
   average header size.  The cost of the exponential backoff is not
   great and as the headers of non-TCP packet streams are expected to
   change seldomly, it will be amortized over a long time.






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


   The cost of header refreshes in terms of bandwidth are higher than
   similar costs for hard state schemes like [RFC-1553] where full
   headers must be acknowledged by the decompressor before compressed
   headers may be sent. Such schemes typically send one full header plus
   a few control messages when the context changes.  Hard state schemes
   require more types of protocol messages and an exchange of messages
   is necessary.  Hard state schemes also need to deal explicitly with
   various error conditions that soft state handles automatically, for
   instance the case of one party disappearing unexpectedly, a common
   situation on wireless links where mobiles may go out of range of the
   base station.

   The major advantage of the soft state scheme is that no handshakes
   are needed between compressor and decompressor, so the scheme can be
   used over simplex links.  The costs in terms of bandwidth are higher
   than for hard state schemes, but the simplicity of the decompressor,
   the simplicity of the protocol, and the lack of handshakes between
   compressor and decompressor justifies this small cost. Moreover, soft
   state schemes are more easily extended to multicast over multi-access
   links, for example radio links.

4.  Grouping packets into packet streams

   This section explains how packets MAY be grouped together into packet
   streams for compression.  To achieve the best compression rates,
   packets SHOULD be grouped together such that packets in the same
   packet stream have similar headers. If this grouping fails, header
   compression performance will be bad, since the compression algorithm
   can rarely utilize the existing context for the packet stream and
   full headers must be sent frequently.

   Grouping is done by the compressor. A compressor may use whatever
   criterion it finds appropriate to group packets into packet streams.
   To determine what packet stream a packet belongs to, a compressor MAY

   a) examine the compressible chain of subheaders (see section 7),

   b) examine the contents of an upper layer protocol header that
      follows the compressible chain of subheaders, for example ICMP
      headers, DVMRP headers, or tunneled IPX headers,

   c) use information obtained from a resource manager, for example if a
      resource manager requests compression for a particular packet
      stream and provides a way to identify packets belonging to that
      packet stream,






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


   d) use any other relevant information, for example if routes flap and
      the hop limit (TTL) field in a packet stream changes frequently
      between n and n+k, a compressor may choose to group the packets
      into two different packet streams.

   A compressor is also free not to group packets into packet streams
   for compression, letting some packets keep their regular headers and
   passing them through unmodified.

   As long as the rules for when to send full headers for a non-TCP
   packet stream are followed and subheaders are compressed as specified
   in this document, the decompressor is able to reconstruct a
   compressed header correctly regardless of how packets are grouped
   into packet streams.

4.1  Guidelines for grouping packets

   In this section we give OPTIONAL guidelines for how a compressor may
   group packets into packet streams for compression.

   Defining fields

      The defining fields of a header should be present and identical in
      all packets belonging to the same packet stream.  These fields are
      marked DEF in section 7. The defining fields include the flow
      label, source and destination addresses of IP headers, final
      destination address in routing headers, the next header fields
      (for IPv6), the protocol field (IPv4), port numbers (UDP and TCP),
      and the SPI in authentication and encryption headers.

   Fragmented packets

      Fragmented and unfragmented packets should never be grouped
      together in the same packet stream. The Identification field of
      the Fragment header or IPv4 header should not be used to identify
      the packet stream. If it was, the first fragment of a new packet
      would cause a compression slow-start.

      No field after a Fragment Header, or an IPv4 header for a
      fragment, should be used for grouping purposes.

   Upper protocol identification

      The first next header field identifying a header not described in
      section 7 should be used for identifying packet streams, i.e., all
      packets with the same DEF fields and the same upper protocol
      should be grouped together.




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


   TTL field (Hop Limit field)

      A sophisticated implementation might monitor the TTL (Hop Limit)
      field and if it changes frequently use it as a DEF field. This can
      occur when there are frequent route flaps so that packets traverse
      different paths through the internet.

   Traffic Class field (IPv6), Type of Service field (IPv4)

      It is possible that the Traffic Class field of the IPv6 header and
      the Type of Service of the IPv4 header will change frequently
      between packets with otherwise identical DEF fields.  A
      sophisticated implementation should watch out for this and be
      prepared to use these fields as defining fields.

   When IP packets are tunneled they are encapsulated with an additional
   IP header at the tunnel entry point and then sent to the tunnel
   endpoint. To group such packets into packet streams, the inner
   headers should also be examined to determine the packet stream.  If
   this is not done, full headers will be sent each time the headers of
   the inner IP packet changes.  So when a packet is tunneled, the
   identifying fields of the inner subheaders should be considered in
   addition to the identifying fields of the initial IP header.

   An implementation can use other fields for identification than the
   ones described here. If too many fields are used for identification,
   performance might suffer because more CIDs will be used and the wrong
   CIDs might be reused when new flows need CIDs. If too few fields are
   used for identification, performance might suffer because there are
   too frequent changes to the context.

   We stress that these guidelines are educated guesses. When IPv6 is
   widely deployed and IPv6 traffic can be analyzed, we might find that
   other grouping algorithms perform better. We also stress that if the
   grouping fails, the result will be bad performance but not incorrect
   decompression. The decompressor can do its task regardless of how the
   grouping algorithm works.

5.  Size Issues

5.1.  Context Identifiers

   Context identifiers can be 8 or 16 bits long.  Their size is not
   relevant for finding the context.  An 8-bit CID with value two and a
   16-bit CID with value two are equivalent.






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


   The CID spaces for TCP and non-TCP are separate, so a TCP CID and a
   non-TCP CID never identify the same context.  Even if they have the
   same value. This doubles the available CID space while using the same
   number of bits for CIDs.  It is always possible to tell whether a
   full or compressed header is for a TCP or non-TCP packet, so no
   mixups can occur.

   Non-TCP compressed headers encode the size of the CID using one bit
   in the second octet of the compressed header. The 8-bit CID allows a
   minimum compressed header size of 2 octets for non-TCP packets, the
   CID uses the first octet and the size bit and the 6-bit Generation
   value fit in the second octet.

   For TCP the only available CID size is 8 bits as in [RFC-1144].  8
   bits is probably sufficient as TCP connections are always point-to-
   point.

   The 16 bit CID size may not be needed for point-to-point links; it is
   intended for use on multi-access links where a larger CID space may
   be needed for efficient selection of CIDs.

   The major difficulty with multi-access links is that several
   compressors share the CID space of a decompressor.  CIDs can no
   longer be selected independently by the compressors as collisions may
   occur.  This problem may be resolved by letting the decompressors
   have a separate CID space for each compressor.  Having separate CID
   spaces requires that decompressors can identify which compressor sent
   the compressed packet, perhaps by utilizing link-layer information as