rfc1974.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

Network Working Group                                          R. Friend
Request for Comments: 1974                              Stac Electronics
Category: Informational                                       W. Simpson
                                                              DayDreamer
                                                             August 1996


                   PPP Stac LZS Compression Protocol

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  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 Stac LZS data compression
   algorithm, with single or multiple compression histories, for
   compressing PPP encapsulated packets.

Table of Contents

     1.     Introduction ..........................................    2
        1.1       Licensing .......................................    2
        1.2       Specification of Requirements ...................    3
     2.     LZS Packets ...........................................    3
        2.1       Padding .........................................    4
        2.2       Zero Deletion/Insertion .........................    4
        2.3       Reliability and Sequencing ......................    4
           2.3.1  Reset-Request and Reset-Ack Packet Formats.......    5
        2.4       Data Expansion ..................................    6
        2.5       Packet Format ...................................    6
           2.5.1  PPP Protocol ....................................    7
           2.5.2  History Number ..................................    7
           2.5.3  Check Value .....................................    7
              2.5.3.1  LCB ........................................    7
              2.5.3.2  CRC ........................................    7
              2.5.3.3  Sequence Number ............................    8
                 2.5.3.3.1  History Synchronization with Sequence
                             Numbers Example ......................    9



Friend & Simpson             Informational                      [Page 1]

RFC 1974                        Stac LZS                     August 1996


           2.5.4  History Synchronization Procedure ...............   10
           2.5.5  Compressed Data .................................   11
     3.     Sending Compressed Datagrams ..........................   12
        3.1       Transmitter Process .............................   12
        3.2       Receiver Process ................................   12
        3.3       History Maintenance .............................   13
        3.4       History Resynchronization Mechanism .............   14
     4.     Configuration Option Format ...........................   14
     5.     Definition of Extended Mode ...........................   16
        5.1       Extended Mode Packet Format .....................   16
        5.2       Extended Mode Transmitter Process ...............   18
        5.3       Extended Mode Receiver Process ..................   18
        5.4       Extended Mode Synchronization ...................   19
     SECURITY CONSIDERATIONS ......................................   19
     REFERENCES ...................................................   20
     CHAIR'S ADDRESS    ...........................................   20
     AUTHORS' ADDRESSES............................................   20

1.  Introduction

   Starting with a sliding window compression history, similar to LZ1
   [3], Stac Electronics developed a new, enhanced compression algorithm
   identified as Stac LZS.  The LZS algorithm is optimized to compress
   all file types as efficiently as possible.  Even string matches as
   short as two octets are effectively compressed.

   The Stac LZS compression algorithm supports both single compression
   history communication and multiple compression history communication.

   A single compression history will require the minimum amount of
   memory to implement, but may not provide as much compression as a
   multiple history implementation.

   Often, many streams of information are interleaved over the same
   link.  Each virtual link will transmit data that is independent of
   other virtual links.  Using multiple compression histories can
   improve the compression ratio of a communication link by associating
   separate compression histories with separate virtual links of
   communication.

1.1.  Licensing

   Source and object licenses are available on a non-discriminatory
   basis.  Hardware implementations are also available.  Contact Stac
   Electronics at the address and phone number listed with the author's
   address for further information.





Friend & Simpson             Informational                      [Page 2]

RFC 1974                        Stac LZS                     August 1996


1.2.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the specification.

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that there
             may exist valid reasons in particular circumstances to
             ignore this item, but the full implications MUST be
             understood and carefully weighed before choosing a
             different course.

   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST be
             prepared to interoperate with another implementation which
             does include the option.

2.  LZS Packets

   Before any LZS packets may be communicated, PPP must reach the
   Network-Layer Protocol phase.

   When the Compression Control Protocol (CCP) has reached the Opened
   state, and LZS is negotiated as the primary compression algorithm,
   exactly one Stac LZS datagram is encapsulated in the PPP Information
   field, where the PPP Protocol field indicates type hex 00FD
   (compressed datagram) or type hex 00FB (Individual link compressed
   datagram).  Type hex 00FD is used when compression is negotiated over
   a single physical link or when compression is negotiated over a
   single bundle consisting of multiple physical links.  Type hex 00FB
   is used when compression is negotiated separately over individual
   physical links to the same destination.  For more information, please
   refer to PPP Compression Control Protocol.

   When CCP has not successfully reached the Opened state, or LZS is not
   the primary compression algorithm, exactly one LZS datagram is
   encapsulated in the PPP Information field, where the PPP Protocol
   field indicates type hex 4021 (Stac LZS).

      Note that in the latter case, use of LZS is terminated by the PPP
      LCP Protocol-Reject.  The default format is used: a single history
      with no History Number field and no Check Value field (as if the



Friend & Simpson             Informational                      [Page 3]

RFC 1974                        Stac LZS                     August 1996


      negotiated history count were 1).

   The maximum length of the Stac LZS 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 ID Field.  Protocol-Field-Compression MAY be used on this
   value, if it has been successfully negotiated for the link.

   The PPP Protocol ID Field is followed by the original Information
   field. The length of the uncompressed data field is limited only by
   the allowed size of the compressed data field and the higher protocol
   layers.

   PPP Link Control Protocol packets MUST NOT be sent within Stac LZS
   packets.  PPP Network Control Protocol packets MUST NOT be sent
   within Stac LZS packets.

2.1.  Padding

   The LZS Information field always ends with the last compressed data
   byte (also known as the <end marker>), which is used to disambiguate
   padding.  This allows trailing bits as well as octets to be
   considered padding.

2.2  Zero Deletion/Insertion

   When the sender does not add Padding [1], any trailing zero octets
   MAY be removed prior to transmission.  A single trailing zero octet
   MUST be appended upon receipt, after removal of any framing FCS.

2.3.  Reliability and Sequencing

   When no Compression History is kept, the algorithm does not depend on
   a reliable link, and does not require that packets be delivered in
   sequence.  However, per packet compression results in a lower
   compression ratio than it could be on a stream.

   Some reasons for resetting the history on a per packet basis include:

      -  The link has a high error rate.
      -  The resources of the transmitter or receiver limit the ability
         to maintain a compression history between packets.

   When more than 1 Compression History is negotiated, the packet
   sequence MUST be preserved within specific History Numbers.  There is
   no sequence requirement between different History Numbers.



Friend & Simpson             Informational                      [Page 4]

RFC 1974                        Stac LZS                     August 1996


   When one or more compression histories is negotiated on the link, the
   implementation MUST implement either a lower layer reliable link
   protocol, or keep the compressor and decompressor histories in
   synchronization, or both.

   To maintain history synchronization, the implementation MUST use the
   Reset-Request and Reset-Ack messages of the Compression Control
   Protocol and MUST use an Option 17 check mode value of sequence
   numbers (and MAY implement other check mode values other than none).
   In this case the Data field of the CCP Reset-Request and Reset-Ack
   MUST contain the two octet History Number to be reset, most
   significant octet first.

   If neither of these conditions are met on the data link, then the
   compression histories MUST be reset after transmitting each datagram.

   The transmitter MAY clear a Compression History at any time.  The
   receiver is implicitly notified of this event, and the decompression
   history will automatically be affected.

   The transmitter MUST reset a history after a CCP Reset-Request for
   the given History Number.

   2.3.1  Reset-Request and Reset-Ack Packet Formats

      A summary of the CCP Reset-Request and Reset-Ack packet formats
      for Stac LZS compressed links are 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Data             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code

      14 for Reset-Request;

      15 for Reset-Ack.

   Identifier

      On transmission, the Identifier field MUST be changed whenever the
      content of the Data field changes, and whenever a valid reply has