RFC 1962 (rfc1962) - Page 2 of 9
The PPP Compression Control Protocol (CCP)
Alternative Format: Original Text Document
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