rfc1962.txt

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

      been received for a previous request.  For retransmissions, the
      Identifier MAY remain unchanged.

      On reception, the Identifier field of the Reset-Request is copied
      into the Identifier field of the Reset-Ack packet.

   Data

      The Data field is zero or more octets and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value and may be of any length from zero to the peer's established
      MRU minus four.

4.  CCP Configuration Options

   CCP Configuration Options allow negotiation of compression algorithms
   and their parameters.  CCP uses the same Configuration Option format
   defined for LCP [1], with a separate set of Options.

   Configuration Options, in this protocol, indicate algorithms that the
   receiver is willing or able to use to decompress data sent by the
   sender.  As a result, it is to be expected that systems will offer to
   accept several algorithms, and negotiate a single one that will be
   used.



Rand                        Standards Track                     [Page 5]

RFC 1962                    PPP Compression                    June 1996


   There is the possibility of not being able to agree on a compression
   algorithm.  In that case, no compression will be used, and the link
   will continue to operate without compression.  If link reliability
   has been separately negotiated, then it will continue to be used,
   until the LCP is re-negotiated.

   We expect that many vendors will want to use proprietary compression
   algorithms, and have made a mechanism available to negotiate these
   without encumbering the Internet Assigned Number Authority with
   proprietary number requests.

   The LCP option negotiation techniques are used.  If an option is
   unrecognized, a Configure-Reject MUST be sent.  If all protocols the
   sender implements are Configure-Rejected by the receiver, then no
   compression is enabled in that direction of the link.

   If an option is recognized, but not acceptable due to values in the
   request (or optional parameters not in the request), a Configure-NAK
   MUST be sent with the option modified appropriately.  The Configure-
   NAK MUST contain only those options that will be acceptable.  A new
   Configure-Request SHOULD be sent with only the single preferred
   option, adjusted as specified in the Configure-Nak.

   Up-to-date values of the CCP Option Type field are specified in the
   most recent "Assigned Numbers" RFC [2].  Current values are assigned
   as follows:

      CCP Option      Compression type
      0               OUI
      1               Predictor type 1
      2               Predictor type 2
      3               Puddle Jumper
      4-15            unassigned
      16              Hewlett-Packard PPC
      17              Stac Electronics LZS
      18              Microsoft PPC
      19              Gandalf FZA
      20              V.42bis compression
      21              BSD LZW Compress
      255             Reserved

      The unassigned values 4-15 are intended to be assigned to other
      freely available compression algorithms that have no license fees.








Rand                        Standards Track                     [Page 6]

RFC 1962                    PPP Compression                    June 1996


4.1.  Proprietary Compression OUI

   Description

      This Configuration Option provides a way to negotiate the use of a
      proprietary compression protocol.

      Since the first matching compression will be used, it is
      recommended that any known OUI compression options be transmitted
      first, before the common options are used.

      Before accepting this option, the implementation must verify that
      the Organization Unique Identifier identifies a proprietary
      algorithm that the implementation can decompress, and that any
      vendor specific negotiation values are fully understood.

   A summary of the Proprietary Compression OUI Configuration Option
   format is shown below.  The fields are transmitted from left to
   right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |       OUI ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         OUI       |    Subtype    |  Values...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Type

      0

   Length

      >= 6

   IEEE OUI

      The vendor's IEEE Organization Unique Identifier (OUI), which is
      the most significant three octets of an Ethernet Physical Address,
      assigned to the vendor by IEEE 802.  This identifies the option as
      being proprietary to the indicated vendor.  The bits within the
      octet are in canonical order, and the most significant octet is
      transmitted first.






Rand                        Standards Track                     [Page 7]

RFC 1962                    PPP Compression                    June 1996


   Subtype

      This field is specific to each OUI, and indicates a compression
      type for that OUI.  There is no standardization for this field.
      Each OUI implements its own values.

   Values

      This field is zero or more octets, and contains additional data as
      determined by the vendor's compression protocol.

4.2.  Other Compression Types

   Description

      These Configuration Options provide a way to negotiate the use of
      a publicly defined compression algorithm.  Many compression
      algorithms are specified.  No particular compression technique has
      arisen as an Internet Standard.

      These protocols will be made available to all interested parties,
      but may have certain licensing restrictions associated with them.
      For additional information, refer to the compression protocol
      documents that define each of the compression types.

   A summary of the Compression Type Configuration Option format is
   shown below.  The fields are transmitted from left to right.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Values...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Type

      1 to 254

   Length

      >= 2

   Values

      This field is zero or more octets, and contains additional data as
      determined by the compression protocol.



Rand                        Standards Track                     [Page 8]

RFC 1962                    PPP Compression                    June 1996


Security Considerations

   Security issues are not discussed in this memo.

References

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, July 1994.

   [2]   Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
         1700, USC/Information Sciences Institute, October 1994.

   [3]   Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.

Acknowledgments

   Bill Simpson helped with the document formatting.

Chair's Address

   The working group can be contacted via the current chair:

      Karl Fox
      Ascend Communications
      3518 Riverside Drive, Suite 101
      Columbus, Ohio 43221

      EMail: [e-mail]

Author's Address

   Questions about this memo can also be directed to:

      Dave Rand
      Novell, Inc.
      2180 Fortune Drive
      San Jose, CA  95131

      [phone]

      EMail: [e-mail]










Rand                        Standards Track                     [Page 9]