rfc2507.txt

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

   to who sent the link-layer frame.  If such information is not
   available, all compressors on the multi-access link may be
   enumerated, automatically or otherwise, and supply their number as
   part of the CID. This latter method requires a large CID space.

5.2.  Size of the context

   The size of the context SHOULD be limited to simplify implementation
   of compressor and decompressor, and put a limit on their memory
   requirements.  However, there is no upper limit on the size of an
   IPv6 header as the chain of extension headers can be arbitrarily
   long.  This is a problem as the context is essentially a stored
   header.

   The configurable parameter MAX_HEADER (see section 14) represents the
   maximum size of the context, expressed as the maximum sized header
   that can be stored as context. When a header is larger than
   MAX_HEADER, only part of it is stored as context.  An implementation
   MUST NOT compress more than the initial MAX_HEADER octets of a
   header.  An implementation MUST NOT partially compress a subheader.



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


   Thus, the part of the header that is stored as context and is
   compressed is the longest initial sequence of entire subheaders that
   is not larger than MAX_HEADER octets.

5.3.  Size of full headers

   It is desirable to avoid increasing the size of packets with full
   headers beyond their original size, as their size may be optimized
   for the MTU of the link. Since we assume that the link layer
   implementation provides the length of packets, we can use the length
   fields in full headers to pass the values of the CID and the
   generation to the decompressor.

   This requires that the link-layer must not add padding to the
   payload, at least not padding that can be delivered to the
   destination link user. It is also required that no extra padding is
   added after UDP data or in tunneled packets. This allows values of
   length fields to be calculated from the length of headers and the
   length of the link-layer frame.

   The generation requires one octet and the CID may require up to 2
   octets.  There are length fields of 2 octets in the IPv6 Base Header,
   the IPv4 header, and the UDP header.

   A full TCP header will thus have at least 2 octets available in the
   IP header to pass the 8 bit CID, which is sufficient. There will be
   more than two octets available if there is more than one IP header.

   [RFC-1144] uses the 8 bit Protocol field of the IPv4 header to pass
   the CID. We cannot use the corresponding method as the sequence of
   IPv6 extension headers is not fixed and CID values are not disjoint
   from the legal values of Next Header fields.

   An IPv6/UDP or IPv4/UDP packet will have 4 octets available to pass
   the generation and the CID, so all CID sizes may be used. Fragmented
   or encrypted packet streams may have only 2 octets available to pass
   the generation and CID.  Thus, 8-bit CIDs may be the only CID sizes
   that can be used for such packet streams.  When IPv6/IPv4 or
   IPv4/IPv6 tunneling is used, there will be at least 4 octets
   available, and both CID sizes may be used.

   The generation value is passed in the higher order octet of the first
   length field in the full header. When only one length field is
   available, the 8-bit CID is passed in the low order octet.  When two
   length fields are available, the lowest two octets of the CID are
   passed in the second length field and the low order octet of the
   first length field carries the highest octet of the CID.




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


5.3.1.  Use of length fields in full TCP headers

   Use of first length field:

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Length field   | LSB of pkt nr |      CID      |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Use of second length field if available:

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Second length field  | MSB of pkt nr |       0       |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Pkt nr is short for packet sequence number, described in section
   11.2.

5.3.2.  Use of length fields in full non-TCP headers

   Full non-TCP headers with 8-bit CID:

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  First length field   |0|D| Generation|      CID      |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Second length field (if avail.) |       0       | Data (if D=1) |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Full non-TCP headers with 16-bit CID:

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  First length field   |1|D| Generation| Data (if D=1) |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Second length field  |              CID              |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first bit in the first length field indicates the length of the
   CID.  The Data field is zero if D is zero. The use of the D bit and
   Data field is explained in section 12.









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


6.  Compressed Header Formats

   This section uses some terminology (DELTA, RANDOM) defined in section
   7.

      a) COMPRESSED_TCP format (similar to [RFC 1144]):

            +-+-+-+-+-+-+-+-+
            |      CID      |
            +-+-+-+-+-+-+-+-+
            |R O I P S A W U|
            +-+-+-+-+-+-+-+-+
            |               |
            +  TCP Checksum +
            |               |
            +-+-+-+-+-+-+-+-+
            | RANDOM fields, if any (see section 7)   (implied)
             - - - - - - - -
            | R-octet       |                         (if R=1)
             - - - - - - - -
            | Urgent Pointer Value                    (if U=1)
             - - - - - - - -
            | Window Delta                            (if W=1)
             - - - - - - - -
            | Acknowledgment Number Delta             (if A=1)
             - - - - - - - -
            | Sequence Number Delta                   (if S=1)
             - - - - - - - -
            | IPv4 Identification Delta               (if I=1)
             - - - - - - - -
            |  Options                                (if O=1)
             - - - - - - - -


   The latter flags in the second octet (IPSAWU) have the same meaning
   as in [RFC-1144], regardless of whether the TCP segments are carried
   by IPv6 or IPv4. The C bit has been eliminated because the CID is
   always present. The context associated with the CID keeps track of
   the IP version and what RANDOM fields are present.  The order between
   delta fields specified here is exactly as in [RFC-1144]. An
   implementation will typically scan the context from the beginning and
   insert the RANDOM fields in order. The RANDOM fields are thus placed
   before the DELTA fields of the TCP header in the same order as they
   occur in the original uncompressed header.







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


   The I flag is zero unless an IPv4 header immediately precedes the TCP
   header. The combined IPv4/TCP header is then compressed as a unit as
   described in [RFC-1144]. Identification fields in IPv4 headers that
   are not immediately followed by a TCP header are RANDOM.

   If the O flag is set, the Options of the TCP header were not the same
   as in the previous header. The entire Option field are placed last in
   the compressed TCP header.

   If the R flag is set, there were differences between the context and
   the Reserved field (6 bits) in the TCP header or bit 6 or 7 of the
   TOS octet (Traffic Class octet) in a IPv4 header (IPv6 header) that
   immediately precedes the TCP header.  An octet with the actual values
   of the Reserved field and bit 6 and 7 of the TOS or Traffic Class
   field is then placed immediately after the RANDOM fields.  Bits 0-5
   of the passed octet is the actual value of the Reserved field, and
   bits 6 and 7 are the actual values of bits 6 and 7 in the TOS or
   Traffic Class field. If there is no preceding IP header, bits 6 and 7
   are 0.  The octet passed with the R flag MUST NOT update the context.

   NOTE: The R-octet does not update the context because if it did, the
   nTCP checksum would not guard the receiving TCP from erroneously
   decompressed headers. Bits 6 and 7 of the TOS octet or Traffic Class
   octet is expected to change frequently due to Explicit Congestion
   Notification.

   See section 7.12 and [RFC-1144] for further information on how to
   compress TCP headers.

      b) COMPRESSED_TCP_NODELTA header format

          +-+-+-+-+-+-+-+-+
          |      CID      |
          +-+-+-+-+-+-+-+-+
          |  RANDOM fields, if any (see section 7)   (implied)
          +-+-+-+-+-+-+-+-+
          |  Whole TCP header except for Port Numbers
          +-+-+-+-+-+-+-+-+













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


      c) Compressed non-TCP header, 8 bit CID:
           0             7
          +-+-+-+-+-+-+-+-+
          |      CID      |
          +-+-+-+-+-+-+-+-+
          |0|D| Generation|
          +-+-+-+-+-+-+-+-+
          |      data     |                      (if D=1)
           - - - - - - - -
          | RANDOM fields, if any (section 7)    (implied)
           - - - - - - - -

      d) Compressed non-TCP header, 16 bit CID:
           0             7
          +-+-+-+-+-+-+-+-+
          |  msb of CID   |
          +-+-+-+-+-+-+-+-+
          |1|D| Generation|
          +-+-+-+-+-+-+-+-+
          |  lsb of CID   |
          +-+-+-+-+-+-+-+-+
          |      data     |                      (if D=1)
           - - - - - - - -
          | RANDOM fields, if any (section 7)    (implied)
           - - - - - - - -

   The generation, CID and optional one octet data are followed by
   relevant RANDOM fields (see section 7) as implied by the compression
   state, placed in the same order as they occur in the original
   uncompressed header, followed by the payload.

7.  Compression of subheaders

   This section gives rules for how the compressible chain of subheaders
   is compressed. These rules MUST be followed.  Subheaders that may be
   compressed include IPv6 base and extension headers, TCP headers, UDP
   headers, and IPv4 headers.  The compressible chain of subheaders
   extends from the beginning of the header

   a) up to but not including the first header that is not an IPv4
      header, an IPv6 base or extension header, a TCP header, or a UDP
      header, or

   b) up to and including the first TCP header, UDP header, Fragment
      Header, Encapsulating Security Payload Header, or IPv4 header for
      a fragment,





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


   whichever gives the shorter chain. For example, rules a) and b) both
   fit a chain of subheaders that contain a Fragment Header and ends at