rfc1967.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       K. Schneider
Request for Comments: 1967                                  ADTRAN, Inc.
Category: Informational                                        R. Friend
                                                         Stac Technology
                                                             August 1996


               PPP LZS-DCP Compression Protocol (LZS-DCP)

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 for compressing PPP encapsulated packets, using a DCP
   header [6].  This protocol is an enhanced version of the non-DCP
   (Option 17) PPP Stac LZS compression protocol [5], and will be
   referred to as the LZS-DCP Compression Protocol.

Table of Contents

     1.     Introduction ..........................................    2
        1.1       Licensing .......................................    3
        1.2       Specification of Requirements ...................    3
        1.3       Terminology .....................................    3
     2.     LZS-DCP Packets .......................................    4
        2.1       Example LZS-DCP Packets .........................    5
        2.2       Padding .........................................    6
        2.3       Reliabliity and Squencing .......................    6
        2.4       Data Expansion ..................................    6
        2.5       Packet Format ...................................    7
           2.5.1  PPP Protocol ....................................    7
           2.5.2  DCP-Header ......................................    8
           2.5.3  History Number ..................................    9
           2.5.4  Sequence Number .................................    9
           2.5.5  Data ............................................   10
           2.5.6  Longitudinal Check Byte .........................   10



Schneider & Friend           Informational                      [Page 1]

RFC 1967                        LZS-DCP                      August 1996


           2.5.7  Compressed Data .................................   11
     3.     Sending Compressed Datagrams     .....................    11
        3.1       Transmitter Process .............................   11
        3.2       Receiver Process ................................   12
        3.3       History Maintenance .............................   13
        3.4       Anti-Expansion Mechanism ........................   14
        3.5       History Resynchronization Mechanism .............   14
     4.     Configuration Option Format ...........................   15
     SECURITY CONSIDERATIONS ......................................   16
     REFERENCES ...................................................   17
     CHAIR'S ADDRESS ..............................................   17
     AUTHORS' ADDRESSES ...........................................   18

1.  Introduction

   Starting with a sliding window compression history, similar to LZ1
   [3], Stac Electronics developed a compression algorithm identified as
   Stac LZS.  A PPP Compression Protocol for this compression algorithm
   was developed and published [5].  That protocol was taken as a basis
   for data compression work done in TIA for DSU/CSUs.  As a part of
   that standardization process, the concept of a portable Data
   Compression Protocol (DCP) was introduced [6].  The resulting
   (pending) TIA/EIA-655 standard uses this LZS-DCP protocol, which
   ncorporates DCP into a PPP compression protocol for Stac LZS.  A very
   similar protocol is currently out for ballot in the Frame Relay
   Forum.  (It is identical except for the size of the history number
   field.)

   This publication of the LZS-DCP compression protocol is in the
   interest of providing a common compression protocol for Stac-LZS, and
   to provide features that are not available with the LZS compression
   protocol [5].  Some of the differences between the LZS-DCP and LZS
   (compression type 17) protocols are as follows:

        1) LZS-DCP provides an option which allows packets containing
           uncompressible data to be transferred without requiring the
           compression history to be cleared, potentially allowing a
           higher compression ratio.  A bit is included in the DCP
           header to indicate whether the packet contains compressed or
           uncompressed data.

        2) LZS-DCP uses reset request and acknowledgment bits in the DCP
           header that is included on each packet rather than using
           CCP's reset request and acknowledge packets, which may result
           in fewer discarded data packets during the REQ/ACK handshake.

        3) LZS-DCP allows simultaneous use of both sequence numbers and
           the LCB for compression error detection.



Schneider & Friend           Informational                      [Page 2]

RFC 1967                        LZS-DCP                      August 1996


   The Stac LZS compression algorithm supports both single and multiple
   compression histories.  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
   physical link.  Each virtual connection will transmit data that is
   independent of other virtual connections.  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 ([e-mail]) for further information.

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.

1.3.  Terminology

   This document frequently uses the following terms:

   datagram  The unit of transmission in the network layer (such as IP).
             A datagram may be encapsulated in one or more packets
             passed to the data link layer.



Schneider & Friend           Informational                      [Page 3]

RFC 1967                        LZS-DCP                      August 1996


   frame     The unit of transmission at the data link layer.  A frame
             may include a header and/or a trailer, along with some
             number of units of data.

   packet    The basic unit of encapsulation, which is passed across the
             interface between the network layer and the data link
             layer.  A packet is usually mapped to a frame; the
             exceptions are when data link layer fragmentation is being
             performed, or when multiple packets are incorporated into a
             single frame.

   peer      The other end of the point-to-point link.

   silently discard

             This means the implementation discards the packet without
             further processing.  The implementation SHOULD provide the
             capability of logging the error, including the contents of
             the silently discarded packet, and SHOULD record the event
             in a statistics counter.

2.  LZS-DCP Packets

   Before any LZS-DCP packets are communicated, PPP MUST reach the
   Network-Layer Protocol phase, and the CCP Control Protocol MUST reach
   the Opened state.

   Exactly one LZS-DCP 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.

   The maximum length of the LZS-DCP 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 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



Schneider & Friend           Informational                      [Page 4]

RFC 1967                        LZS-DCP                      August 1996


   layers.

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

2.1.  Example LZS-DCP packets (shown using PPP in HDLC-like framing,
      using Address-and-Control-Field-Compression and Protocol-Field-
      Compression. - RFC 1662 )

   Compressed Packet:

        PPP |                                        | PPP
        PID | HDR   SEQ           DATA           LCB | FCS
      +-----+-----+-----+---................---+-----+-----+
      | F D | C 0 | n n |   Compressed Data    | y y | z z |
      +-----+-----+-----+---................---+-----+-----+
                        /                      \
                       /      Compression       \
                      /      Transformation      \
                     /                            \
                    /PPP                           \
                   / PID   PPP Information Field    \
                  +-----+----....................----+
                  | x x | upper layer protocol data  |
                  +-----+----....................----+


   Uncompressed Packet

        PPP |                                  | PPP
        PID | HDR   SEQ           DATA         | FCS
      +-----+-----+-----+---................---+-----+
      | F D | 8 0 | n n |   Un-compressed Data | z z |
      +-----+-----+-----+---................---+-----+
                        /                      \
                       /                        \
                      /                          \
                     /                            \
                    /PPP                           \
                   / PID   PPP Information Field    \
                  +-----+----....................----+
                  | x x | upper layer protocol data  |
                  +-----+----....................----+

      where:  C0 and 80 are representative LZS-DCP headers; nn, xx, yy,
              and zz are values determined by the packet's context.




Schneider & Friend           Informational                      [Page 5]

RFC 1967                        LZS-DCP                      August 1996


2.2.  Padding

      PPP padding is not allowed in a LZS-DCP packet.  However, on
      compressed packets, padding may be accomplished by extending the
      data field with zeros following the last compressed data octet
      (see Section 2.1.1).  This is referred to as LZS Padding.  The
      LCB, if present, MUST be the octet preceding the frame CRC.

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 clearing 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 one or more compression Histories are negotiated, the packet
      sequence MUST be preserved within specific History Numbers.  There
      is no sequence requirement between different History Numbers.

      When using one or more compression histories, the implementation
      MUST rely on either a lower layer reliable link protocol (RFC
      1663), use a technique to keep the compressor and decompressor
      histories in synchronization, or both.  The LZS-DCP protocol
      provides the Request-Req and Request-Ack bits in the DCP header
      for this purpose.  Since this synchronization is done on a per
      history basis, the history number fields are required to be the
      same size in both directions of the link.  Any data contained in
      the packet is processed after the signaling bits are processed.

      The transmitter MAY clear a Compression History at any time.

      The transmitter MUST clear a history after a receiving a Reset-
      Request for a given History Number.

2.4.  Data Expansion

      The maximum expansion of Stac LZS is 12.5%.

      A Maximum Receive Unit (MRU) MAY be negotiated that is 12.5%
      larger than the size of a normal packet.  Then, packets can always
      be sent compressed regardless of expansion.



Schneider & Friend           Informational                      [Page 6]