RFC 1993

PPP Gandalf FZA Compression Protocol 🎀

Okay bestie, let's start with the title block ✨. This is RFC 1993, written by A. Barbir (Gandalf), D. Carr (Newbridge), and W. Simpson (DayDreamer). It's Informational and dated August 1996. There's no Obsoletes or Updates line in the header, so it doesn't replace or change any other RFC 🦋.

---

Status of This Memo 📜

This memo gives information to the Internet community 💜. It doesn't specify an Internet standard. Distribution is unlimited, so share it with everyone 🌈.

Abstract 🧚

The Point-to-Point Protocol (PPP) [1] gives us a standard way to carry multi-protocol datagrams over point-to-point links 🔥.

The PPP Compression Control Protocol [2] is how two sides negotiate and use compression protocols on PPP-encapsulated links 💅.

This document explains how to use the Gandalf FZA data compression algorithm [3] to compress PPP-encapsulated packets 🫶.

Table of Contents 🍓

     1.     Introduction ..........................................    1
        1.1       Licensing .......................................    1
     2.     FZA Packets ...........................................    2
        2.1       Packet Format ...................................    3
     3.     Configuration Option Format ...........................    4
     SECURITY CONSIDERATIONS ......................................    4
     ACKNOWLEDGEMENTS .............................................    5
     REFERENCES ...................................................    5
     CONTACTS .....................................................    5

1. Introduction ✨

Okay so FZA is a high-performance LZ [4] derivative 🔥. It maxes out compression by spending more memory and CPU. The good news is you can tune how much compression you get based on how much CPU and memory you have available 💖.

Multiple PPP packets can be squished into one compressed frame. A single PPP packet can also be spread across multiple frames 🦋.

1.1. Licensing 💼

Source and object licenses are available on a non-discriminatory basis, either for a royalty or for a fixed price. Patent indemnity is included with the license 🌸.

2. FZA Packets 📦

Before any FZA packets can be communicated, PPP has to reach the Network-Layer Protocol phase 🧚.

Once the Compression Control Protocol (CCP) reaches the Opened state, and FZA is negotiated as the primary compression algorithm, the PPP Protocol field shows either type hex 00FB (link compressed datagram) or type hex 00FD (compressed datagram) 💅.

The maximum length of an FZA datagram sent over a PPP link is the same as the maximum length of the Information field of a PPP-encapsulated packet 🎀.

Padding

FZA packets need the Self-Describing-Padding Configuration Option [5] to be negotiated during LCP Link Establishment 🌈.

Reliability and Sequencing

FZA expects a reliable link, as described in "PPP Reliable Transmission" [6] 🫶.

FZA also expects packets to be delivered in sequence 🔥.

Data Expansion

The maximum expansion of Gandalf FZA is 2:1. Typical expansion on pre-compressed data is 1.01:1, which is pretty chill 😭. Expanded data is still sent so the integrity of the compression history stays intact 💜.

When the expansion goes over the size of the peer's Maximum Receive Unit for the link, the expanded packet gets sent in multiple PPP frames. The compressed data includes an indication of where the original packet ends ✨.

2.1. Packet Format 🦋

Here's a summary of the Gandalf FZA packet format. The fields are sent from left to right 💖.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |     Compressed Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PPP Protocol

This is one or two octets. The PPP Protocol field is explained in the Point-to-Point Protocol Encapsulation [1] 🧚.

Type 00FD is used when the PPP multilink protocol isn't in use, and/or when it's "inside" a multilink bundle. Type 00FB is used "outside" multilink, so each individual link in a multilink bundle can compress on its own 🔥. This value MAY be compressed when LCP Protocol-Field-Compression is negotiated 💅.

Compressed Data

This is one or more octets, holding the compressed PPP-encapsulated packet(s) 🌸.

Before compression, the uncompressed data starts with the original PPP Protocol number. This value MAY be compressed when LCP Protocol-Field-Compression is negotiated 🎀.

The original Protocol number is followed by the original Information field. The length of the original Information field before compression MUST NOT exceed the link Maximum Receive Unit (MRU) 🙈.

PPP Link Control Protocol packets MUST NOT be sent within compressed data 💀.

3. Configuration Option Format 🎀

Description

The CCP Gandalf-FZA Configuration Option is how you negotiate using Gandalf FZA on the link. By default, or if there's ultimate disagreement, no compression is used 🫶.

Here's a summary of the Gandalf-FZA Configuration Option format. Again, the fields go from left to right 🦋.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   History   |    Version ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

The value is 19 🌈.

Length

The value is >= 3 💜.

History

This is one octet. The History field gives the maximum size of the compression history as a power of 2. Valid values run from 12 to 15 ✨.

The peer is not required to send as many histories as the implementation says it can accept 🧚.

Version

This is zero or more octets of extra configuration information. Any implementation that doesn't implement this information MUST send a Configure-Nak without this field 🔥.

The Version field is not present for FZA 💅.

The Version field is a single octet, and it holds the value 1 for FZA+ 🌸.

---

Security Considerations 🔐

Security issues are not discussed in this memo 😬. (Yes, really. Be careful out there, bestie 💀.)

Acknowledgements 👑

FZA was developed by David Carr while he was at Gandalf Data Limited 🫶.

FZA+ was an improvement by Abbie Barbir 💖.

Editting and formatting was done by William Simpson 🎀.

References 📚

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

[2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, Novell, June 1996.

[3] Barbir, A., "A New Fast Approximate Arithmetic Coder", Proceedings of IEEE 28th SouthEastern Symposium on Systems Theory (SSST), Baton Rouge, Louisiana, pages 482-486, April 1996.

[4] Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential Data Compression", IEEE Transactions On Information Theory, Vol. IT-23, No. 3, May 1977.

[5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, DayDreamer, January 1994.

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

Contacts 💌

Licensing queries should go to:

   Michael Williams
   Director of Business Development
   Gandalf Data Limited
   130 Colonnade Road South
   Napean, Ontario, Canada  K2E 7M4
   (613) 274-6500 ext 6575

Comments should be submitted to the ietf-ppp@merit.edu mailing list 📬.

This document was reviewed by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF) 🌸.

The working group can be contacted through the current chair:

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

       karl@MorningStar.com
       karl@Ascend.com

Questions about this memo can also go to:

   Abdulkader Barbir
   Gandalf Data Limited
   130 Colonnade Road South
   Napean, Ontario, Canada  K2E 7M4
   (613) 274-6500 ext 8550

       abarbir@gandalf.ca

Questions about this memo should not be directed to:

   Dave Carr
   Newbridge Networks Corporation
   600 March Road
   P.O. Box 13600
   Kanata, Ontario, Canada, K2K 2E6

       dcarr@newbridge.com

   William Allen Simpson
   DayDreamer
   Computer Systems Consulting Services
   1384 Fontaine
   Madison Heights, Michigan  48071

       wsimpson@UMich.edu
       wsimpson@GreenDragon.com (preferred)