summaryrefslogtreecommitdiff
path: root/rfc/rfc1962.txt
diff options
context:
space:
mode:
Diffstat (limited to 'rfc/rfc1962.txt')
-rw-r--r--rfc/rfc1962.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/rfc/rfc1962.txt b/rfc/rfc1962.txt
new file mode 100644
index 0000000..fc9b47d
--- /dev/null
+++ b/rfc/rfc1962.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group D. Rand
+Request for Comments: 1962 Novell
+Category: Standards Track June 1996
+
+
+ The PPP Compression Control Protocol (CCP)
+
+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.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links. PPP
+ also defines an extensible Link Control Protocol.
+
+ This document defines a method for negotiating data compression over
+ PPP links.
+
+Table of Contents
+
+ 1. Introduction .......................................... 1
+ 2. Compression Control Protocol (CCP) .................... 2
+ 2.1 Sending Compressed Datagrams .................... 3
+ 3. Additional Packets .................................... 4
+ 3.1 Reset-Request and Reset-Ack ..................... 4
+ 4. CCP Configuration Options ............................. 5
+ 4.1 Proprietary Compression OUI ..................... 7
+ 4.2 Other Compression Types ......................... 8
+ SECURITY CONSIDERATIONS ...................................... 9
+ REFERENCES ................................................... 9
+ ACKNOWLEDGEMENTS ............................................. 9
+ CHAIR'S ADDRESS .............................................. 9
+ AUTHOR'S ADDRESS ............................................. 9
+
+1. Introduction
+
+ In order to establish communications over a PPP link, each end of the
+ link must first send LCP packets to configure and test the data link
+ during Link Establishment phase. After the link has been
+ established, optional facilities may be negotiated as needed.
+
+
+
+
+
+Rand Standards Track [Page 1]
+
+RFC 1962 PPP Compression June 1996
+
+
+ One such facility is data compression. A wide variety of compression
+ methods may be negotiated, although typically only one method is used
+ in each direction of the link.
+
+ A different compression algorithm may be negotiated in each
+ direction, for speed, cost, memory or other considerations, or only
+ one direction may be compressed.
+
+2. Compression Control Protocol (CCP)
+
+ The Compression Control Protocol (CCP) is responsible for
+ configuring, enabling, and disabling data compression algorithms on
+ both ends of the point-to-point link. It is also used to signal a
+ failure of the compression/decompression mechanism in a reliable
+ manner.
+
+ CCP uses the same packet exchange mechanism as the Link Control
+ Protocol (LCP). CCP packets may not be exchanged until PPP has
+ reached the Network-Layer Protocol phase. CCP packets received
+ before this phase is reached should be silently discarded.
+
+ The Compression Control Protocol is exactly the same as the Link
+ Control Protocol [1] with the following exceptions:
+
+ Frame Modifications
+
+ The packet may utilize any modifications to the basic frame format
+ which have been negotiated during the Link Establishment phase.
+
+ Data Link Layer Protocol Field
+
+ Exactly one CCP packet is encapsulated in the PPP Information
+ field, where the PPP Protocol field indicates type hex 80FD
+ (Compression Control Protocol).
+
+ When individual link data compression is used in a multiple link
+ connection to a single destination, the PPP Protocol field
+ indicates type hex 80FB (Individual link Compression Control
+ Protocol).
+
+ Code field
+
+ In addition to Codes 1 through 7 (Configure-Request, Configure-
+ Ack, Configure-Nak, Configure-Reject, Terminate-Request,
+ Terminate-Ack and Code-Reject), two additional Codes 14 and 15
+ (Reset-Request and Reset-Ack) are defined for this protocol.
+ Other Codes should be treated as unrecognized and should result in
+ Code-Rejects.
+
+
+
+Rand Standards Track [Page 2]
+
+RFC 1962 PPP Compression June 1996
+
+
+ Timeouts
+
+ CCP packets may not be exchanged until PPP has reached the
+ Network-Layer Protocol phase. An implementation should be
+ prepared to wait for Authentication and Link Quality Determination
+ to finish before timing out waiting for a Configure-Ack or other
+ response. It is suggested that an implementation give up only
+ after user intervention or a configurable amount of time.
+
+ Configuration Option Types
+
+ CCP has a distinct set of Configuration Options.
+
+2.1. Sending Compressed Datagrams
+
+ Before any compressed packets may be communicated, PPP must reach the
+ Network-Layer Protocol phase, and the Compression Control Protocol
+ must reach the Opened state.
+
+ One or more compressed packets are encapsulated in the PPP
+ Information field, where the PPP Protocol field indicates type hex
+ 00FD (Compressed datagram). Each of the compression algorithms may
+ use a different mechanism to indicate the inclusion of more than one
+ uncompressed packet in a single Data Link Layer frame.
+
+ When using multiple PPP links to a single destination, there are two
+ methods of employing data compression. The first method is to
+ compress the data prior to sending it out through the multiple links.
+ The second is to treat each link as a separate connection, that may
+ or may not have compression enabled. In the second case, the PPP
+ Protocol field MUST be type hex 00FB (Individual link compressed
+ datagram).
+
+ Only one primary algorithm in each direction is in use at a time, and
+ that is negotiated prior to sending the first compressed frame. The
+ PPP Protocol field of the compressed datagram indicates that the
+ frame is compressed, but not the algorithm with which it was
+ compressed.
+
+ The maximum length of a compressed packet transmitted over a PPP link
+ is the same as the maximum length of the Information field of a PPP
+ encapsulated packet. Larger datagrams (presumably the result of the
+ compression algorithm increasing the size of the message in some
+ cases) may be sent uncompressed, using its standard form, or may be
+ sent in multiple datagrams, if the compression algorithm supports it.
+
+ Each of the compression algorithms must supply a way of determining
+ if they are passing data reliably, or they must require the use of a
+
+
+
+Rand Standards Track [Page 3]
+
+RFC 1962 PPP Compression June 1996
+
+
+ reliable transport such as LAPB [3]. Vendors are strongly encouraged
+ to employ a method of validating the compressed data, or recognizing
+ out-of-sync compressor/decompressor pairs.
+
+3. Additional Packets
+
+ The Packet format and basic facilities are already defined for LCP
+ [1].
+
+ Up-to-date values of the CCP Code field are specified in the most
+ recent "Assigned Numbers" RFC [2]. This specification concerns the
+ following values:
+
+ 14 Reset-Request
+ 15 Reset-Ack
+
+3.1. Reset-Request and Reset-Ack
+
+ Description
+
+ CCP includes Reset-Request and Reset-Ack Codes in order to provide
+ a mechanism for indicating a decompression failure in one
+ direction of a compressed link without affecting traffic in the
+ other direction. A decompression failure may be determined by
+ periodically passing a hash value, performing a CRC check on the
+ decompressed data, or other mechanism. It is strongly suggested
+ that some mechanism be available in all compression algorithms to
+ validate the decompressed data before passing the data on to the
+ rest of the system.
+
+ A CCP implementation wishing to indicate a decompression failure
+ SHOULD transmit a CCP packet with the Code field set to 14
+ (Reset-Request), and the Data field filled with any desired data.
+ Once a Reset-Request has been sent, any Compressed packets
+ received are discarded, and another Reset-Request is sent with the
+ same Identifier, until a valid Reset-Ack is received.
+
+ Upon reception of a Reset-Request, the transmitting compressor is
+ reset to an initial state. This may include clearing a
+ dictionary, resetting hash codes, or other mechanisms. A CCP
+ packet MUST be transmitted with the Code field set to 15 (Reset-
+ Ack), the Identifier field copied from the Reset-Request packet,
+ and the Data field filled with any desired data.
+
+ On receipt of a Reset-Ack, the receiving decompressor is reset to
+ an initial state. This may include clearing a dictionary,
+ resetting hash codes, or other mechanisms. Since there may be
+ several Reset-Acks in the pipe, the decompressor MUST be reset for
+
+
+
+Rand Standards Track [Page 4]
+
+RFC 1962 PPP Compression June 1996
+
+
+ each Reset-Ack which matches the currently expected identifier.
+
+ A summary of the Reset-Request and Reset-Ack packet formats 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+
+ Code
+
+ 14 for Reset-Request;
+
+ 15 for Reset-Ack.
+
+ Identifier
+
+ On transmission, the Identifier field MUST be changed whenever the
+ content of the Data field changes, and whenever a valid reply has
+ 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: karl@ascend.com
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ Dave Rand
+ Novell, Inc.
+ 2180 Fortune Drive
+ San Jose, CA 95131
+
+ +1 408 321-1259
+
+ EMail: dlr@daver.bungi.com
+
+
+
+
+
+
+
+
+
+
+Rand Standards Track [Page 9]
+