home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1993.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  9.6 KB  |  397 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          A. Barbir
  8. Request for Comments: 1993                                       Gandalf
  9. Category: Informational                                          D. Carr
  10.                                                                Newbridge
  11.                                                               W. Simpson
  12.                                                               DayDreamer
  13.                                                              August 1996
  14.  
  15.  
  16.                   PPP Gandalf FZA Compression Protocol
  17.  
  18.  
  19. Status of this Memo
  20.  
  21.    This memo provides information for the Internet community.  It does
  22.    not specify an Internet standard.  Distribution of this memo is
  23.    unlimited.
  24.  
  25. Abstract
  26.  
  27.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  28.    transporting multi-protocol datagrams over point-to-point links.
  29.  
  30.    The PPP Compression Control Protocol [2] provides a method to
  31.    negotiate and utilize compression protocols over PPP encapsulated
  32.    links.
  33.  
  34.    This document describes the use of the Gandalf FZA data compression
  35.    algorithm [3] for compressing PPP encapsulated packets.
  36.  
  37. Table of Contents
  38.  
  39.      1.     Introduction ..........................................    1
  40.         1.1       Licensing .......................................    1
  41.      2.     FZA Packets ...........................................    2
  42.         2.1       Packet Format ...................................    3
  43.      3.     Configuration Option Format ...........................    4
  44.      SECURITY CONSIDERATIONS ......................................    4
  45.      ACKNOWLEDGEMENTS .............................................    5
  46.      REFERENCES ...................................................    5
  47.      CONTACTS .....................................................    5
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Barbir, Carr & Simpson                                          [Page i]
  59.  
  60. RFC 1993                      Gandalf FZA                    August 1996
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    FZA is a high performance LZ [4] derivative that maximizes
  66.    compression at the expense of memory and CPU.  Compression
  67.    performance can be adjusted based on CPU and memory available.
  68.  
  69.    Multiple PPP packets can be combined in a single compressed frame, or
  70.    a single PPP packet can be spread across multiple frames.
  71.  
  72. 1.1.  Licensing
  73.  
  74.    Source and object licenses are available on a non-discriminatory
  75.    basis for either a royalty or fixed price arrangement.  Patent
  76.    indemnity is included with the license.
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Barbir, Carr & Simpson                                          [Page 1]
  115.  
  116. RFC 1993                      Gandalf FZA                    August 1996
  117.  
  118.  
  119. 2.  FZA Packets
  120.  
  121.    Before any FZA packets may be communicated, PPP must reach the
  122.    Network-Layer Protocol phase.
  123.  
  124.    When the Compression Control Protocol (CCP) has reached the Opened
  125.    state, and FZA is negotiated as the primary compression algorithm,
  126.    the PPP Protocol field indicates type hex 00FB (link compressed
  127.    datagram), or type hex 00FD (compressed datagram).
  128.  
  129.    The maximum length of the FZA datagram transmitted over a PPP link is
  130.    the same as the maximum length of the Information field of a PPP
  131.    encapsulated packet.
  132.  
  133.    Padding
  134.  
  135.       The FZA packets require the negotiation of the Self-Describing-
  136.       Padding Configuration Option [5] at LCP Link Establishment.
  137.  
  138.    Reliability and Sequencing
  139.  
  140.       The FZA algorithm expects a reliable link, as described in "PPP
  141.       Reliable Transmission" [6].
  142.  
  143.       FZA expects the packets to be delivered in sequence.
  144.  
  145.    Data Expansion
  146.  
  147.       The maximum expansion of Gandalf FZA is 2:1.  However, typical
  148.       expansion on pre-compressed data is 1.01:1.  Expanded data is sent
  149.       to maintain the integrity of the compression history.
  150.  
  151.       When the expansion exceeds the size of the peer's Maximum Receive
  152.       Unit for the link, the expanded packet is sent in multiple PPP
  153.       frames.  The compressed data contains an indication of the end of
  154.       the original packet.
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Barbir, Carr & Simpson                                          [Page 2]
  171.  
  172. RFC 1993                      Gandalf FZA                    August 1996
  173.  
  174.  
  175. 2.1.  Packet Format
  176.  
  177.    A summary of the Gandalf FZA packet format is shown below.  The
  178.    fields are transmitted from left to right.
  179.  
  180.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  181.    |         PPP Protocol          |     Compressed Data ...
  182.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  183.  
  184.    PPP Protocol
  185.  
  186.       One or two octets.  The PPP Protocol field is described in the
  187.       Point-to-Point Protocol Encapsulation [1].
  188.  
  189.       Type 00FD is used when the PPP multilink protocol is not used,
  190.       and/or "inside" a multilink bundle.  Type 00FB is used "outside"
  191.       multilink, to compress independently on individual links of a
  192.       multilink bundle.  This value MAY be compressed when LCP
  193.       Protocol-Field-Compression is negotiated.
  194.  
  195.    Compressed Data
  196.  
  197.       One or more octets.  The compressed PPP encapsulated packet(s).
  198.  
  199.       Prior to compression, the uncompressed data begins with the
  200.       original PPP Protocol number.  This value MAY be compressed when
  201.       LCP Protocol-Field-Compression is negotiated.
  202.  
  203.       The original Protocol number is followed by the original
  204.       Information field.  The length of the original Information field
  205.       before compression MUST NOT exceed the link Maximum Receive Unit
  206.       (MRU).
  207.  
  208.       PPP Link Control Protocol packets MUST NOT be sent within
  209.       compressed data.
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Barbir, Carr & Simpson                                          [Page 3]
  227.  
  228. RFC 1993                      Gandalf FZA                    August 1996
  229.  
  230.  
  231. 3.  Configuration Option Format
  232.  
  233.    Description
  234.  
  235.       The CCP Gandalf-FZA Configuration Option negotiates the use of
  236.       Gandalf FZA on the link.  By default or ultimate disagreement, no
  237.       compression is used.
  238.  
  239.    A summary of the Gandalf-FZA Configuration Option format is shown
  240.    below.  The fields are transmitted from left to right.
  241.  
  242.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  243.    |     Type      |    Length     |   History   |    Version ...
  244.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  245.  
  246.    Type
  247.  
  248.       19
  249.  
  250.    Length
  251.  
  252.       >= 3
  253.  
  254.    History
  255.  
  256.       One octet.  The History field specifies the maximum size of the
  257.       compression history in powers of 2.  Valid values range from 12 to
  258.       15.
  259.  
  260.       The peer is not required to send as many histories as the
  261.       implementation indicates that it can accept.
  262.  
  263.    Version
  264.  
  265.       Zero or more octets of additional configuration information.  Any
  266.       implementation that does not implement this information MUST send
  267.       a Configure-Nak without this field.
  268.  
  269.       The Version field is not present for FZA.
  270.  
  271.       The Version field is a single octet containing the value 1 for
  272.       FZA+.
  273.  
  274.  
  275. Security Considerations
  276.  
  277.    Security issues are not discussed in this memo.
  278.  
  279.  
  280.  
  281.  
  282. Barbir, Carr & Simpson                                          [Page 4]
  283.  
  284. RFC 1993                      Gandalf FZA                    August 1996
  285.  
  286.  
  287. Acknowledgements
  288.  
  289.    FZA was developed by David Carr while at Gandalf Data Limited.
  290.  
  291.    FZA+ was an improvement by Abbie Barbir.
  292.  
  293.    Editting and formatting by William Simpson.
  294.  
  295.  
  296. References
  297.  
  298.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  299.          51, RFC 1661, DayDreamer, July 1994.
  300.  
  301.    [2]   Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
  302.          1962, Novell, June 1996.
  303.  
  304.    [3]   Barbir, A., "A New Fast Approximate Arithmetic Coder",
  305.          Proceedings of IEEE 28th SouthEastern Symposium on Systems
  306.          Theory (SSST), Baton Rouge, Louisiana, pages 482-486, April
  307.          1996.
  308.  
  309.    [4]   Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential
  310.          Data Compression", IEEE Transactions On Information Theory,
  311.          Vol. IT-23, No. 3, May 1977.
  312.  
  313.    [5]   Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
  314.          DayDreamer, January 1994.
  315.  
  316.    [6]   Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
  317.          1994.
  318.  
  319.  
  320.  
  321. Contacts
  322.  
  323.    Licensing queries should be directed to:
  324.  
  325.    Michael Williams
  326.    Director of Business Development
  327.    Gandalf Data Limited
  328.    130 Colonnade Road South
  329.    Napean, Ontario, Canada  K2E 7M4
  330.    (613) 274-6500 ext 6575
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Barbir, Carr & Simpson                                          [Page 5]
  339.  
  340. RFC 1993                      Gandalf FZA                    August 1996
  341.  
  342.  
  343.    Comments should be submitted to the ietf-ppp@merit.edu mailing list.
  344.  
  345.    This document was reviewed by the Point-to-Point Protocol Working
  346.    Group of the Internet Engineering Task Force (IETF).
  347.  
  348.    The working group can be contacted via the current chair:
  349.  
  350.       Karl Fox
  351.       Ascend Communications
  352.       3518 Riverside Drive, Suite 101
  353.       Columbus, Ohio  43221
  354.  
  355.           karl@MorningStar.com
  356.           karl@Ascend.com
  357.  
  358.  
  359.    Questions about this memo can also be directed to:
  360.  
  361.       Abdulkader Barbir
  362.       Gandalf Data Limited
  363.       130 Colonnade Road South
  364.       Napean, Ontario, Canada  K2E 7M4
  365.       (613) 274-6500 ext 8550
  366.  
  367.           abarbir@gandalf.ca
  368.  
  369.  
  370.    Questions about this memo should not be directed to:
  371.  
  372.       Dave Carr
  373.       Newbridge Networks Corporation
  374.       600 March Road
  375.       P.O. Box 13600
  376.       Kanata, Ontario, Canada, K2K 2E6
  377.  
  378.           dcarr@newbridge.com
  379.  
  380.       William Allen Simpson
  381.       DayDreamer
  382.       Computer Systems Consulting Services
  383.       1384 Fontaine
  384.       Madison Heights, Michigan  48071
  385.  
  386.           wsimpson@UMich.edu
  387.           wsimpson@GreenDragon.com (preferred)
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395. Barbir, Carr & Simpson                                          [Page 6]
  396.  
  397.