PPP Gandalf FZA Compression Protocol
A compression algorithm for PPP links using the Gandalf FZA method.
Barbir, A., Carr, D., and W. Simpson, "PPP Gandalf FZA Compression Protocol", RFC 1993, DOI 10.17487/RFC1993, August 1996, <https://www.rfc-editor.org/info/rfc1993>.
@misc{rfc1993,
series = {Request for Comments},
number = 1993,
howpublished = {RFC 1993},
publisher = {RFC Editor},
doi = {10.17487/RFC1993},
url = {https://www.rfc-editor.org/info/rfc1993},
author = {A. Barbir and D. Carr and W. Simpson},
title = {{PPP Gandalf FZA Compression Protocol}},
pagetotal = 7,
year = 1996,
month = aug,
} RFC text
Contents
Network Working Group A. Barbir
Request for Comments: 1993 Gandalf
Category: Informational D. Carr
Newbridge
W. Simpson
DayDreamer
August 1996
PPP Gandalf FZA Compression Protocol
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. 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.
The PPP Compression Control Protocol [2] provides a method to
negotiate and utilize compression protocols over PPP encapsulated
links.
This document describes the use of the Gandalf FZA data compression
algorithm [3] for compressing 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
FZA is a high performance LZ [4] derivative that maximizes
compression at the expense of memory and CPU. Compression
performance can be adjusted based on CPU and memory available.
Multiple PPP packets can be combined in a single compressed frame, or
a single PPP packet can be spread across multiple frames.
1.1. Licensing
Source and object licenses are available on a non-discriminatory
basis for either a royalty or fixed price arrangement. Patent
indemnity is included with the license.
2. FZA Packets
Before any FZA packets may be communicated, PPP must reach the
Network-Layer Protocol phase.
When the Compression Control Protocol (CCP) has reached the Opened
state, and FZA is negotiated as the primary compression algorithm,
the PPP Protocol field indicates type hex 00FB (link compressed
datagram), or type hex 00FD (compressed datagram).
The maximum length of the FZA datagram transmitted over a PPP link is
the same as the maximum length of the Information field of a PPP
encapsulated packet.
Padding
The FZA packets require the negotiation of the Self-Describing-
Padding Configuration Option [5] at LCP Link Establishment.
Reliability and Sequencing
The FZA algorithm expects a reliable link, as described in "PPP
Reliable Transmission" [6].
FZA expects the packets to be delivered in sequence.
Data Expansion
The maximum expansion of Gandalf FZA is 2:1. However, typical
expansion on pre-compressed data is 1.01:1. Expanded data is sent
to maintain the integrity of the compression history.
When the expansion exceeds the size of the peer's Maximum Receive
Unit for the link, the expanded packet is sent in multiple PPP
frames. The compressed data contains an indication of the end of
the original packet.
2.1. Packet Format
A summary of the Gandalf FZA packet format is shown below. The
fields are transmitted from left to right.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol | Compressed Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPP Protocol
One or two octets. The PPP Protocol field is described in the
Point-to-Point Protocol Encapsulation [1].
Type 00FD is used when the PPP multilink protocol is not used,
and/or "inside" a multilink bundle. Type 00FB is used "outside"
multilink, to compress independently on individual links of a
multilink bundle. This value MAY be compressed when LCP
Protocol-Field-Compression is negotiated.
Compressed Data
One or more octets. The compressed PPP encapsulated packet(s).
Prior to compression, the uncompressed data begins 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 negotiates the use of
Gandalf FZA on the link. By default or ultimate disagreement, no
compression is used.
A summary of the Gandalf-FZA Configuration Option format is shown
below. The fields are transmitted from left to right.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | History | Version ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
19
Length
>= 3
History
One octet. The History field specifies the maximum size of the
compression history in powers of 2. Valid values range from 12 to
15.
The peer is not required to send as many histories as the
implementation indicates that it can accept.
Version
Zero or more octets of additional configuration information. Any
implementation that does not 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 containing the value 1 for
FZA+.
Security Considerations
Security issues are not discussed in this memo.
Acknowledgements
FZA was developed by David Carr while at Gandalf Data Limited.
FZA+ was an improvement by Abbie Barbir.
Editting and formatting 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 be directed 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 via 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 be directed 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)
AI ELI5
On this page
§1Introduction to Gandalf FZA Compression
The Point-to-Point Protocol (PPP) provides a standard method for transporting datagrams over point-to-point links, and the PPP Compression Control Protocol (CCP) provides a method to negotiate and use compression algorithms. RFC 1993 describes the use of the Gandalf FZA data compression algorithm for compressing PPP encapsulated packets.
FZA is a high-performance derivative of the Lempel-Ziv (LZ) compression method. It maximizes compression ratio at the expense of CPU and memory consumption. Compression performance can be adjusted based on available resources. Licensing is available on a non-discriminatory basis.
Gandalf FZA is a way to make PPP data smaller before sending it across a slow link. The compression can be adjusted depending on how much memory and processing power you have.
§2Packet Format and Requirements
Before any FZA packets are sent, PPP must reach the Network-Layer Protocol phase and the Compression Control Protocol (CCP) must have reached the Opened state with FZA negotiated as the primary compression algorithm. PPP Protocol field type hex 00FB is used for link compressed datagrams (outside multilink), and type hex 00FD is used for compressed datagrams (inside multilink or without multilink).
FZA packets consist of a PPP Protocol field (one or two octets) followed by compressed data. The maximum length is the same as a normal PPP Information field. Multiple PPP packets can be combined into a single compressed frame, or a single PPP packet can be split across multiple frames. FZA requires self-describing padding negotiation and a reliable, in-order delivery link.
Compressed packets get a type label (00FB or 00FD) so the other end knows they are compressed. Multiple packets can be combined or one packet can span several frames.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
PPP-PROTO | PPP Protocol | 2 bytes | Type hex 00FB (link compressed) or 00FD (compressed). May be compressed with LCP Protocol-Field-Compression. | |
COMPRESSED-DATA | Compressed Data | 1 byte | One or more octets of FZA-compressed PPP packets with original protocol number and information field. |
§3Compression Characteristics and Data Expansion
The maximum expansion of Gandalf FZA is 2:1, meaning in the worst case expanded data is twice the original size. However, typical expansion on pre-compressed data is only 1.01:1, meaning compression schemes rarely cause significant bloat. When expansion exceeds the Maximum Receive Unit (MRU) for the link, the expanded packet is sent across multiple PPP frames with an indication in the compressed data marking the end of the original packet.
Expanded data is sent to maintain the integrity of the compression history. PPP Link Control Protocol packets MUST NOT be sent within compressed data, ensuring that control traffic is not affected by compression.
Sometimes already-compressed files don't compress well, and can actually get bigger. The algorithm handles this by either sending expanded data or splitting it across frames.
§4Configuration and Negotiation
The CCP Gandalf-FZA Configuration Option is used to negotiate compression on the link. The option includes a Type field (value 19), a Length field (>= 3), a History field (one octet specifying the maximum compression history size in powers of 2, valid values 12 to 15), and an optional Version field.
The Version field is not present for standard FZA, but contains the value 1 for FZA+, an improved variant. By default or if negotiation fails, no compression is used. The peer is not required to send as many histories as the implementation indicates it can accept.
Before sending compressed data, the two ends agree on how much history to keep (which affects compression strength) and which FZA version to use (FZA or FZA+).