RFC 1975

PPP Magnalink Variable Resource Compression

📅 published August 1996, from ietf

Okay bestie, the title block first ✨ This is RFC 1975, called PPP Magnalink Variable Resource Compression. It came from the Network Working Group and was written by D. Schremp, J. Black, and J. Weiss, all at Magnalink. It's Informational and dated August 1996. It doesn't list anything it obsoletes or updates 💖

Status of This Memo 📜

This memo gives information to the Internet community 🌸 It does not set any kind of Internet standard, and it can be shared without limits 🦋

Abstract ✨

The Point-to-Point Protocol (PPP) [1] is the go-to standard for wrapping multiple protocol datagrams up and sending them over point-to-point links 🧚 The PPP Compression Control Protocol [2] is how two sides agree on data compression over a PPP link 🤝

The Magnalink Variable Resource Compression Algorithm (MVRCA) gives you a whole range of compression implementations that can still talk to each other 💅 How well each one performs depends on how much CPU and memory is available 🔥

Introduction 🌈

Okay so the Magnalink variable resource compression algorithm is basically a family of compression solutions that all play nice together 🫶 Their performance depends on how much CPU and memory you have. It's giving tailored, because it can be fitted to the system it runs on without breaking interoperability 😭

Licensing 🍓

Source licenses are available on a non-discriminatory basis ✨

If you want to evaluate it under NDA and licensing, the contact person is:

        Director of OEM Sales
        Magnalink Communications Division
        Telco Systems Inc.
        63 Nahatan Street
        Norwood, Mass. 02062
        Phone: (617) 255-9400, Fax: (617) 255-5885
        oem@magna.telco.com

MVRCA Packets 🦋

Before any MVRCA packets may be communicated, PPP must reach the Network-Layer Protocol phase[1], and the Compression Control Protocol must reach the Opened state 🙈

The text of a Packet to be compressed starts with the PPP Protocol number. And if Protocol-Field-Compression was negotiated, the Packet header (PPP Protocol number included) may already be compressed 💜

Reliability and Sequencing 🔥

MVRCA packets may be sent over an unreliable link, or over a reliable link described in "PPP Reliable Transmission"[3], as long as that reliable link was negotiated 💖 If frames arrive out of order or one gets dropped, the decompressor notices and asks for a resynchronization using the Reset-Req and Reset-Ack types of the CCP[2], aimed at the compressor for the affected context 😭

Data Expansion 💅

Compression can occasionally make a data packet bigger, and that's the tea ☕ MVRCA doesn't have expansion, though, because any data that would grow just gets sent uncompressed instead 🌈 Dictionary synchronization still holds across those uncompressed packets 🫶

Encapsulation 🎀

The encapsulation is made up of the PPP Protocol Identifier, a bit that tells you whether the data is compressed, the Context Identifier (CID), a proprietary flag bit (E), a Packet Integrity Byte (PIB), and the compressed data 🧚

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PPP Protocol Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|E|   CID     |     PIB       |  C compressed flag
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  1 data is compressed
   | Compressed data  ...             0 data is not compressed
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Compressed/Uncompressed Flag (C) 🦋

Sometimes the compressor isn't very effective on certain types of Packets or Fragments 💀 When that happens, the uncompressed data goes into the compression History Buffer and gets sent across the link in a frame with the Compressed/Uncompressed Flag (C) set to 0 ✨

Context Identifier (CID) 👑

PPP carries multiple protocol datagrams, so it can be a great idea to compress each protocol, or each virtual circuit, in its own History Buffer (its own Context) 🌸 The CID tells the decompressor which History Buffer the compressor picked for a given Packet. How that choice gets made is up to the implementor 💅 The number of buffers and the size of each one are negotiated 🎀

A CID of 0 means the Packet by Packet context gets used, if it was negotiated 🧚 That context gets cleared between Packets, so its History Buffer isn't kept across Packet boundaries 🙈

Packet Integrity Byte (PIB) 💖

To make sure Packets are compressed and decompressed correctly, and that History Buffer synchronization stays intact, a Packet Integrity Byte gets added to the packet header 🔥

The packet integrity byte is defined in the full protocol specification 📜

Configuration Option Format 🌈

Description 🍓

The CCP MVRCA Configuration Option is how you negotiate MVRCA on the link 🫶 By default, or if nobody can agree, no compression is used 💀

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |FE |P| History |  # Contexts   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🦋

The value is 24 ✨

Length 🧚

The value is 4 💅

FE - Features 🔥

This field negotiates features that are specific to this compression algorithm 💜

History 🎀

This defines the size of the compression history buffer. The valid values are defined in the full protocol specification 📜

# Contexts 👑

This is the number of contexts. Each context means a History Buffer gets created for that context, with the size given in the Context History field 💖 Values are 1-63 🌸 This value includes both the Packet by Packet context and the contexts that keep history 🫶

So if this value is 1 and the P (Packet by Packet) flag is also 1, then only per-packet compression is supported, and history isn't kept across packet boundaries 😭 The Context Identifier (CID) starts at 1 for contexts where history is maintained 🌈

P - Packet by Packet flag 🍓

When P is 1, packet by packet compression is enabled for the context whose context ID is 0 ✨ When P is 0, packet by packet compression is not supported 💀

Security Considerations 😱

Security issues are not discussed in this memo 💀 Please don't skip over this one, because the whole memo leaves them out 🙈

References 📚

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

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

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

Acknowledgments 🫶

Chair's Address 🎀

The working group can be contacted through the current chair:

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

EMail: karl@ascend.com

Authors' Addresses 💖

Comments about this document may also be directed to the authors 🦋

Doug Schremp
Telco Systems, Inc.
Magnalink Communications Division
63 Nahatan Street
Norwood Ma. 02062

Phone: (617) 255-9400
EMail: dhs@magna.telco.com


Jeffrey Black
Telco Systems, Inc.
Magnalink Communications Division
63 Nahatan Street
Norwood Ma. 02062

Phone: (617) 255-9400
EMail: jtb@magna.telco.com


Jeffrey Weiss
Telco Systems, Inc.
Magnalink Communications Division
63 Nahatan Street
Norwood Ma. 02062

Phone: (617) 255-9400
EMail: jaw@magna.telco.com
📦 where this page comes from