Network Working Group K. Schneider Request for Comments: 1976 S. Venters Category: Informational ADTRAN, Inc. August 1996
PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)
Status of This Memo
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. 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 defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.
The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a standard method for encapsulating and transporting serial data over a PPP link. The PPP Compression Control Protocol [3] provides a standard method for selecting and using a compression protocol to provide for data compression on a PPP link.
This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE).
This document is a product of the TR30.1 ad hoc committee on compression of synchronous data. It represents a component of a proposal to use PPP to provide compression of synchronous serial data in DSU/CSUs.
PPP [1] has three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols for establishing and configuring different network-layer protocols.
In addition to providing support for multi-protocol datagrams, the Point-to-Point Protocol (PPP) [1] has defined an effective and robust negotiating mechanism that can be used on point to point links. When used in conjunction with the PPP Compression Control Protocol [3] and one of the PPP Compression Protocols [4], PPP provides an interoperable method of employing data compression on a point-to- point link.
The PPP Serial Data Transport Protocol (PPP-SDTP) and the PPP Serial Data Control Protocol (PPP-SDCP) [2] have been developed to allow serial data to be carried within a PPP packet. PPP-SDTP uses a terminal adaption header based on that of ITU-T Recommendation V.120 [5].
In this document, several words are used to signify the requirements of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification.
MUST NOT This phrase means that the definition is an absolute prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a
Schneider & Venters Informational [Page 2]
RFC 1976 PPP DCE August 1996
different course.
MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option.
This document frequently uses the following terms:
datagram The unit of transmission in the network layer (such as IP). A datagram may be encapsulated in one or more packets passed to the data link layer.
frame The unit of transmission at the data link layer. A frame may include a header and/or a trailer, along with some number of units of data.
packet The basic unit of encapsulation, which is passed across the interface between the network layer and the data link layer. A packet is usually mapped to a frame; the exceptions are when data link layer fragmentation is being performed, or when multiple packets are incorporated into a single frame.
peer The other end of the point-to-point link.
silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
This document provides for three modes of operation for DCE devices: Mode-0 represents transparent operation; Mode-1 a simplified, predefined compression format; and Mode-2, a full PPP implementation providing compression of serial data.
Mode-0 represents the operating mode of currently deployed DCEs that operate in transparent mode, without any DCE-to-DCE protocols. Mode-1 devices implement data compression upon detecting an initial handshake, which is implemented via an newly defined LCP Configuration Option called the DCE-Identifier. The DCE-Identifier
Schneider & Venters Informational [Page 3]
RFC 1976 PPP DCE August 1996
is used both to distinguish DCE devices from PPP bridges and routers, and to all Mode-1 and Mode-2 DCE devices to interoperate, via its Mode parameter. In Mode-1, the parameters of operation are not negotiable. Mode-2 devices implement the full LCP state machine and are therefore capable of negotiating alternatives to the default set of paramaters and options. Mode-2 devices must also support Mode-1 operation, and fall-back to such operation when connected to a Mode-1 device. The mechanism of the Mode-1/Mode-2 handshake is given in Section 7.
The presence of this option indicates that the system sending it is Data Circuit-Terminating Equipment (DCE) that desires to establish a serial data compression link.
Unlike PPP's native bridge/router environment, the minimum requirement for use of PPP in DCE equipment is not simply interoperability, but rather interoperability with effective data
Schneider & Venters Informational [Page 4]
RFC 1976 PPP DCE August 1996
compression. With this in mind, it is desirable to specify a minimum PPP feature set, that is somewhat different than that of a normal PPP bridge/router requirement.
This different feature set includes: support for compression, support of a single default compression algorithm, support of Protocol-Field compression, support of Address-and-Control-Field-Compression, support of PPP-SDTP, etc.
The minimum feature set includes the following protocols:
PPP Link Control Protocol (Mode-1 must include a subset) [1] PPP in HDLC-like Framing [6] PPP Compression Control Protocol (Mode-2 only) [3] PPP LZS-DCP Compression Protocol [4] PPP Serial Data Transport Protocol [2] PPP Serial Data Control Protocol (Mode-2 only) [2]
The Stacker-LZS algorithm from Stac Electronics was chosen as the default compression algorithm for DCE devices. This decision was made by the TR30.1 ad hoc based on licensing issues (agreeing to non-discriminatory and reasonable terms), compression ratios, its efficient use of processor and memory resources, and speed scalability. A compression protocol incorporating in-band synchronization signaling was defined for the Stacker algorithm and selected for the default compression protocol. This protocol is known as the PPP LZS-DCP Compression Protocol [4]. Although the PPP LZS-DCP Compression Protocol specifies a number of formats and history management options, only the default format with a single history must be implemented.
4.1. Required Configuration Options and Parameters
To ensure that implementations are able to interoperate with effective data compression, a required set of Configuration Options are specified. These Options are assumed in Mode-1, and are negotiated in Mode-2, using the standard PPP negotiation state machine. (Mode-1 uses a fixed packet format with a predetermined set of values for LCP, LZS-DCP, and SDTP Configuration Options/parameters. The required values listed in this section are the predefined values.)
The following LCP Configuration Options [7] MUST be supported:
DSUs that use only Mode-1 (non-negotiate mode) use only a predetermined set of PPP packets. In addition to a fixed data packet format, two fixed formats are used to differentiate between Mode-1 devices and Mode-0 (transparent) devices. Mode-1 devices are designed to operate using compression if a peer has the same capability, or revert to transparent operation (Mode-0) if the peer does not support standard compression.
Mode-1 devices use LZS-DCP Compression Packets as specified in [4]. These packets include the capabilities of DCP: Reset-Request and Acknowledge, Compressed/Transparent, etc. Since the packets include signalling, these packets can be sent with an empty data field to signal a reset request if no data packets are ready for piggy-backed signalling.
Exactly one LZS-DCP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type 00FD (Compression Protocol). Exactly one SDTP packet is transported by each LZS-DCP data packet.
Schneider & Venters Informational [Page 6]
RFC 1976 PPP DCE August 1996
Operation in Mode-1 implies a set of predetermined values for LCP, LZS-DCP, and SDTP configuration options and parameters, using the values listed in the preceding section.
The following PPP packets are permitted and recognized:
LCP Configure-Request with DCE Mode-1 Configuration Option LCP Configure-Ack with DCE Mode-1 Configuration Option LZS-DCP Packet with the data field containing an SDTP packet LZS-DCP Packet with an empty data field
Protocol-Field-Compression and Address-and-Control-Field-Compression is used on all packets except the handshake packets (LCP packets).
Any Mode-1 or Mode-2 DCE that receives a Mode-1 request MUST Acknowledge the request.
Detailed Example when using Mode-1 on a point-to-point leased or circuit switched link (using PPP in HDLC-like Framing [6]) (data shown is after flags and inserted 0s are removed; lower case letters and numbers represent actual values, uppercase represent data fields whose values may vary from packet to packet; parentheses surrounding a field indicate that the field may not be present in all packets of that type):
The DATA field contains a compressed or uncompressed SDTP-PDU. The LCB field is only present on a packet containing compressed data. The Sequence Number and Data fields are only present on packets that contain data.
+----+------+----+ SDTP-PDU: | 49 | DATA | HD | +----+------+----+
When a unit is powered up, or when the lower layer signals that the peer has gone out of service and returned, the handshake procedure is initiated. The handshake procedure for Mode-1 and Mode-2 devices is described below.
Mode-1:
When starting Mode-1, each DCE sends out an LCP Configure-Request packet containing only the DCE-Identifier LCP Configuration Option described in Section 3, with the with the Mode Field set to a value of 1. When a DCE device receives such a packet, it must answer with an LCP Configure-Ack packet. In each of these packets, the identifier field is set to 0. If the originator of the Configure-Request packet does not receive a Configure-Ack response within a user configurable time T1, the unit MUST revert to transparent (Mode-0) operation.
Mode-2:
A Mode-2 device will first try to operate in Mode-2 by starting PPP normally, following the state machine described in [1]. The LCP Configure-Request MUST include the DCE-Identifier Configuration Option with the Mode Field set to 2. If the unit receives a Configure-Reject Packet Containing the DCE-Identifier, the unit MUST revert immediately to transparent (Mode-0) operation. If the LCP state machine times out because a response was not received in user configurable time T2, or if a Mode-1 Configuration-Request packet is received, the unit attempts to operate in Mode-1 by following the procedure listed above, ultimately reverting to Mode-0 operation if the Mode-1 procedure times out.
In either case, the unit is not prohibited from sending multiple Configuration-Request packets before the applicable timer (T1, T2) expires. A unit may also initiate the handshake procedure at any time.
[1] Simpson, W., ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[2] Schneider, K., and S. Venters, "PPP Serial Data Transport Protocol (PPP-SDTP)", RFC 1963, August 1996.
[3] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[4] Lutz, R., "PPP LZS-DCP Compression Protocol", RFC 1967 August 1996.
[5] CCITT Recommendation V.120, "Support by an ISDN of Data Terminal Equipment with V-Series Type Interfaces with Provision for Statistical Multiplexing (revised 1992)", ITU-T, 1993.
[6] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, January 1994.
[7] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.
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
Schneider & Venters Informational [Page 9]
RFC 1976 PPP DCE August 1996
Authors' Addresses
Questions about this memo can also be directed to:
Kevin Schneider Adtran, Inc. 901 Explorer Blvd. Huntsville, AL 35806-2807
Phone: (205) 971-8000 EMail: kevin@adtran.com
Stuart Venters Adtran, Inc. 901 Explorer Blvd. Huntsville, AL 35806-2807