RFC 1976

PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) 🎀

Okay bestie, here's the title block up front so you can see the main facts right away 💖

• Issued by the Network Working Group 🌸
• Authors: K. Schneider and S. Venters, both at ADTRAN, Inc. 👑
• Category: Informational ✨
• Date: August 1996 📅
• Obsoletes/Updates: the title block doesn't list any, so it's not replacing or updating anything 🙈

Status of This Memo ✨

This memo is here to give information to the Internet community 🌈. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share away 🦋.

Abstract 💜

PPP [1] is the standard way to carry multi-protocol datagrams over point-to-point links 🔗. It has an extensible Link Control Protocol, plus a whole family of Network Control Protocols for setting up and configuring different network-layer protocols.

The PPP Serial Data Transport Protocol (PPP-SDTP) [2] is the standard way to encapsulate and transport serial data over a PPP link 🧚. The PPP Compression Control Protocol [3] is the standard way to select and use a compression protocol for data compression on a PPP link 🔥.

This document defines a specific set of parameters for these protocols, plus an LCP extension that defines a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE) 💅.

Table of Contents 📖

     1.     Introduction ..........................................    2
        1.1       Specification of Requirements ...................    2
        1.2       Terminology .....................................    3
     2.     Modes of Operation ....................................    3
     3.     PPP Link Control Protocol Extension ...................    4
     4.     Required PPP Elements .................................    4
        4.1       Required Configuration Options and Parameters ...    5
     5.     Mode-1 Requirements ...................................    6
        5.1       Detailed Mode-1 Example .........................    7
     6.     Initial Handshake Operation ...........................    8
     7.     Security ..............................................    9
     8.     References ............................................    9
     CHAIR'S ADDRESS ..............................................    9
     AUTHORS' ADDRESSES ...........................................   10

1. Introduction ✨

Okay so this doc came out of the TR30.1 ad hoc committee on compression of synchronous data 💖. It's one piece of a bigger proposal to use PPP to compress synchronous serial data in DSU/CSUs, and it's giving teamwork 🫶.

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.

On top of multi-protocol datagrams, PPP [1] has an effective and robust negotiating mechanism that works on point-to-point links 👑. Pair it with the PPP Compression Control Protocol [3] and one of the PPP Compression Protocols [4], and you get an interoperable way to do data compression on a point-to-point link. Main character energy 🌟.

PPP-SDTP and the PPP Serial Data Control Protocol (PPP-SDCP) [2] were built so serial data can ride inside a PPP packet 🧚. PPP-SDTP uses a terminal adaption header based on the one from ITU-T Recommendation V.120 [5].

1.1. Specification of Requirements

In this document, a few words are used to signal how strict a requirement is 🎀. They're usually capitalized, so keep an eye out for them.

• MUST: Also spelled as the adjective "required". It's an absolute requirement of the specification, no wiggle room 💅.
• MUST NOT: Spelled as this phrase. It's an absolute prohibition, a hard no ✋.
• SHOULD: Also spelled as the adjective "recommended". There can be legit reasons in certain situations to skip this item, but you need to fully understand the consequences and weigh them carefully before picking a different path 🧐.
• MAY: Also spelled as the adjective "optional". It marks one option from a set of allowed alternatives. An implementation that leaves this option out MUST be prepared to interoperate with an implementation that includes it 🦋.

1.2. Terminology

This doc uses these terms a lot, so let's get them straight 🌸:

• datagram: The unit of transmission in the network layer, like IP. A datagram may be encapsulated in one or more packets that get passed down 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, handed 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 happening, or when multiple packets are packed into a single frame 🎁.
• peer: The other end of the point-to-point link 🤝.
• silently discard: The implementation drops the packet without doing any more processing 🗑️. It SHOULD be able to log the error, including the contents of the silently discarded packet, and it SHOULD record the event in a statistics counter. Quiet, but not forgotten 🙈.

2. Modes of Operation 🧚

This document sets up three modes of operation for DCE devices 🌈. Mode-0 is transparent operation. Mode-1 is a simplified, predefined compression format. Mode-2 is a full PPP implementation that provides compression of serial data.

Mode-0 is how currently deployed DCEs work when they run in transparent mode, with no DCE-to-DCE protocols at all 💀. Mode-1 devices start compressing as soon as they detect an initial handshake. That handshake happens through a newly defined LCP Configuration Option called the DCE-Identifier. The DCE-Identifier does two jobs. It tells DCE devices apart from PPP bridges and routers, and its Mode parameter lets Mode-1 and Mode-2 DCE devices interoperate 🫶. In Mode-1, the operating parameters are not negotiable. Mode-2 devices run the full LCP state machine, so they can negotiate alternatives to the default set of parameters and options. Mode-2 devices must also support Mode-1 operation, and fall back to it when they're connected to a Mode-1 device. The mechanism for the Mode-1/Mode-2 handshake is covered in Section 7 ✨.

3. PPP Link Control Protocol Extension 💜

Using PPP in Compression DCE requires one extra LCP Configuration Option 🎀:

      25  DCE-Identifier

DCE-Identifier ✨

The presence of this option tells you that the system sending it is Data Circuit-Terminating Equipment (DCE) that wants to set up a serial data compression link 🔥.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |      Mode     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         25

      Length

         3

      Mode

         1   Mode-1 (No Additional Negotiation)
         2   Mode-2 (Full PPP Negotiation and State Machine)

4. Required PPP Elements 🍓

PPP's native bridge/router world plays by different rules. For DCE gear, the minimum requirement isn't just interoperability. It's interoperability with effective data compression 💅. So it makes sense to specify a minimum PPP feature set that's a bit different from a normal PPP bridge/router requirement.

That 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 these 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 got picked as the default compression algorithm for DCE devices 🎉. The TR30.1 ad hoc group made that call based on licensing (agreeing to non-discriminatory and reasonable terms), compression ratios, efficient use of processor and memory resources, and speed scalability 💜. A compression protocol with in-band synchronization signaling was defined for the Stacker algorithm and selected as the default compression protocol. It's called the PPP LZS-DCP Compression Protocol [4]. That protocol specifies a bunch of formats and history management options, but only the default format with a single history must be implemented 🙃.

4.1. Required Configuration Options and Parameters 🧚

To make sure implementations can interoperate with effective data compression, there's a required set of Configuration Options 🫶. These Options are assumed in Mode-1, and 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:

      Maximum-Receive-Unit                 1550
      Address/Control-Field-Compression    Yes
      Protocol-Field-Compression           Yes

The following CCP Configuration Option MUST be supported:

      Compression-Type                      23 (LZS-DCP)

The following default LZS-DCP Configuration Options MUST be supported:

      Check-Mode                    3 (sequence + LCB)
      History-Count                 1 (single history)
      Process-Mode                  0 (None)

The default SDTP/SDCP Configuration Options MUST be supported. They are:

      Packet-Format:                Header-Last
      Header-Type:                  H-Only
      Multiple-Packets:             Off
      Multi-Port:                   Off
      Transport-Mode:               HDLC-Synchronous
      Maximum-Frame-Size:           10,000 bytes
      Allow-Odd-Frames:             Off
      FCS-Type:                     Transparent-Transport
      Flow-Expiration-Time:         100

5. Mode-1 Requirements ✨

okay so Mode-1 is the "no negotiating, just do it" crew 💅 DSUs that only use Mode-1 stick to a predetermined set of PPP packets. There's one fixed data packet format, plus two fixed formats that help Mode-1 devices tell themselves apart from Mode-0 (transparent) devices 🦋. Mode-1 devices are built to use compression when their peer has the same capability, and if the peer doesn't support standard compression, they fall back to transparent operation (Mode-0) 🫶.

Mode-1 devices use LZS-DCP Compression Packets as specified in [4]. These carry the DCP capabilities: Reset-Request and Acknowledge, Compressed/Transparent, and so on ✨. Since the packets already carry signalling, one can go out with an empty data field to request a reset when no data packets are ready to piggy-back that signalling on 🌸.

Exactly one LZS-DCP packet lives inside the PPP Information field, and the PPP Protocol field says type 00FD (Compression Protocol) 👑. Each LZS-DCP data packet carries exactly one SDTP packet 🧚.

Operating in Mode-1 comes with a set of predetermined values for the LCP, LZS-DCP, and SDTP configuration options and parameters, the ones listed in the previous section 💖.

These are the PPP packets that 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 get used on all packets except the handshake packets (LCP packets) 🙈

Any Mode-1 or Mode-2 DCE that gets a Mode-1 request MUST Acknowledge the request. 🔥

5.1. Detailed Mode-1 Example ✨

Here's the detailed example for Mode-1 on a point-to-point leased or circuit switched link (using PPP in HDLC-like Framing [6]). Quick reading guide 🤓: the data is shown after the flags and inserted 0s have been removed. Lowercase letters and numbers are actual values, UPPERCASE means data fields whose values can change from packet to packet, and anything in parentheses might not show up in every packet of that type 🎀.

LCP Configure-Request:

                                         Config. Opt.
Addr. Ctl.  PID    Code ID   Length Type Lngth Mode
+----+----+-------+----+----+-------+----+----+----+-----+
| ff | 03 | c0 21 | 01 | 00 | 00 07 | 21 | 03 | 01 | FCS |
+----+----+-------+----+----+-------+----+----+----+-----+

LCP Configure-Ack:

                                         Config. Opt.
Addr. Ctl.  PID    Code ID   Length Type Lngth Mode
+----+----+-------+----+----+-------+----+----+----+-----+
| ff | 03 | c0 21 | 02 | 00 | 00 07 | 21 | 03 | 01 | FCS |
+----+----+-------+----+----+-------+----+----+----+-----+

LZS-DCP Packet:

 PID  DCP
+----+----+------+------ -+-------+-----+
| fd | HD | (SQ) | (DATA) | (LCB) | FCS |
+----+----+------+--------+-------+-----+

The DATA field holds a compressed or uncompressed SDTP-PDU. The LCB field only shows up on packets carrying compressed data, and the Sequence Number and Data fields only show up on packets that carry data 📦

                  +----+------+----+
      SDTP-PDU:   | 49 | DATA | HD |
                  +----+------+----+

6. Initial Handshake Operation 🚀

So when a unit powers up, or when the lower layer says the peer went out of service and came back, the handshake kicks off 💜 Here's how Mode-1 and Mode-2 do it.

Mode-1:

When starting Mode-1, each DCE sends out an LCP Configure-Request packet that only has the DCE-Identifier LCP Configuration Option from Section 3, with the Mode Field set to 1 🌈. When a DCE gets one of these, it must answer with an LCP Configure-Ack packet. In both of these packets, the identifier field is set to 0. If the originator of the Configure-Request doesn't get a Configure-Ack back within the user configurable time T1, the unit MUST revert to transparent (Mode-0) operation 💀

Mode-2:

A Mode-2 device first tries Mode-2 by starting PPP normally and 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 no response came back within the user configurable time T2, or if a Mode-1 Configuration-Request packet shows up, the unit tries Mode-1 by following the procedure above. It ends up reverting to Mode-0 operation if the Mode-1 procedure times out too 🫠

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 🦋

7. Security Considerations 💀

Security issues are not discussed in this memo. Not one word, bestie 😭💀

8. References 📚

[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

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

Phone: (205) 971-8000
EMail: sventers@adtran.com