[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 RFC 1993

Network Working Group                                          Dave Carr
Internet Draft                                                   Gandalf
expires in six months                                       October 1993


                  PPP Gandalf FZA Compression Protocol
                    draft-ietf-pppext-gandalf-00.txt



Status of this Memo

   This document is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the ietf-ppp@ucdavis.edu mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.


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 for compressing PPP encapsulated packets.





Carr                     expires in six months                  [Page i]

DRAFT                         Gandalf FZA                   October 1993


1.  Introduction

   FZA is a high performance LZA derivative which 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.




































Carr                     expires in six months                  [Page 1]

DRAFT                         Gandalf FZA                   October 1993


2.  FZA Packets

   Before any FZA packets may be communicated, PPP must reach the
   Network-Layer Protocol phase, and the CCP Control Protocol must reach
   the Opened state.

   Exactly one FZA datagram is encapsulated in the PPP Information
   field, where the PPP Protocol field indicates 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.

   Prior to compression, the uncompressed data begins with the PPP
   Protocol number.  This value MAY be compressed when Protocol-Field-
   Compression is negotiated.

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

   Padding

      The FZA packets require the negotiation of the Self-Describing-
      Padding Configuration Option [3] at LCP Link Establishment.

   Reliability and Sequencing

      The FZA algorithm expects a reliable link, as described in "PPP
      Reliable Transmission" [4].

      Gandalf 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.









Carr                     expires in six months                  [Page 2]

DRAFT                         Gandalf FZA                   October 1993


2.1.  Packet Format

   A summary of the Gandalf FZA packet format is shown below.  The
   fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |     Compressed Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   PPP Protocol

      The PPP Protocol field is described in the Point-to-Point Protocol
      Encapsulation [1].

      When the Gandalf FZA compression protocol is successfully
      negotiated by the PPP Compression Control Protocol [2], the value
      is 00FD hex.  This value MAY be compressed when Protocol-Field-
      Compression is negotiated.

   Compressed Data

      The compressed PPP encapsulated packet.

























Carr                     expires in six months                  [Page 3]

DRAFT                         Gandalf FZA                   October 1993


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.

    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     |   History   |     Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      6

   Length

      >= 3


   History

      The History field specifies the maximum size of the compression
      history in powers of 2.  Valid values range from 12 to 15.

   Data
      Zero or more octets of additional configuration information.  Any
      implementation which does not implement this information MUST send
      a Configure-Nak without this field.














Carr                     expires in six months                  [Page 4]

DRAFT                         Gandalf FZA                   October 1993


Security Considerations

   Security issues are not discussed in this memo.


References

   [1]   Simpson, W.A., "The Point-to-Point Protocol (PPP)", work in
         progress.

   [2]   Rand, D., "The PPP Compression Control Protocol (CCP)", work in
         progress.

   [3]   Simpson, W.A., "PPP LCP Extensions", work in progress.

   [4]   Rand, D., "PPP Reliable Transmission", work in progress.


Acknowledgments

   Editting and formatting by Bill Simpson.






























Carr                     expires in six months                  [Page 5]

DRAFT                         Gandalf FZA                   October 1993


Chair's Address

   The working group can be contacted via the current chair:

      Fred Baker
      Advanced Computer Communications
      315 Bollay Drive
      Santa Barbara, California  93117

      EMail: fbaker@acc.com


Author's Address

   Questions about this memo can also be directed to:

      Dave Carr
      Gandalf Data Limited
      130 Colonnade Road South
      Napean, Ontario, Canada  K2E 7M4

      (613) 723-6500
      (613) 226-1717 Fax

      Email: dcarr@gandalf.ca


























Carr                     expires in six months                  [Page 6]
DRAFT                         Gandalf FZA                   October 1993


                           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 ......................................    5

     REFERENCES ...................................................    5

     ACKNOWLEDGEMENTS .............................................    5

     CHAIR'S ADDRESS ..............................................    6

     AUTHOR'S ADDRESS .............................................    6
































Bill.Simpson@um.cc.umich.edu


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/