rfc1967.txt

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


RFC 1967                        LZS-DCP                      August 1996


      The transmitter MAY send an uncompressed LZS-DCP packet at any
      time, although the typical use of uncompressed LZS-DCP packets is
      as an anti-expansion mechanism.

      When the expansion plus compression header exceeds the size of the
      peer's MRU for the link, the data MUST be sent as an uncompressed
      LZS-DCP packet.

      An uncompressed LZS-DCP packet is transmitted according to the
      format shown in Section 2.1, with the C/U bit set to 0
      (Uncompressed-Data).  If the Configuration Option Field 'Process
      Mode', is set to a value of 1 (Process-Uncompressed), uncompressed
      LZS-DCP packets are processed by both the compressor and the
      decompressor, updating the histories of each. If the Process Mode
      Field is set to a value of 0 (None), and the compressor has
      modified its history before sending the uncompressed packet, the
      compressor history MUST be clear.

2.5.  Packet Format

   A summary of the LZS-DCP packet format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          PPP Protocol         |   DCP-Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       (History Number)        |  (Seq Num)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     (LCB)     |
   +-+-+-+-+-+-+-+-+

2.5.1.  PPP Protocol

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

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







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


2.5.2.  DCP-Header

      The DCP-Header is nominally one octet in length, but may be
      extended through the use of the extension bit.

      The format of the DCP-Header is as follows:

         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |  E  | C/U | R-A | R-R | Res | Res | Res | C/D |
      +-----+-----+-----+-----+-----+-----+-----+-----+

      E - Extension Bit

         The E bit is the extension bit.  If set to 0, it indicates that
         another octet of the DCP-Header is present.  Currently, this
         bit is always set to 1, since the DCP-Header field is only one
         octet long.

      C/U - Compressed/Uncompressed Bit

         The C/U indicates whether the data field contains compressed or
         uncompressed data.  A value of 1 indicates compressed data
         (often referred to as a compressed packet), and a value of 0
         indicates uncompressed data (or an uncompressed packet).

      R-A - Reset-Ack

         The R-A bit is used to inform the decompressing peer that
         the history buffer specified by the history number in the
         packet was in the cleared state just before the data contained
         in the packet was processed by the compression transformation
         (see section 3., Sending Compressed Datagrams).  This bit MUST
         be set to a value of "1" to indicate a Reset-Ack, and to
         acknowledge a receive failure (R-R) (see section 3., Sending
         Compressed Datagrams).  This bit is specific to the history
         number of the packet containing it.

      R-R - Reset-Request

         The R-R bit is used to request that the compressing peer
         clear the history buffer specified by the history number in the
         packet.  This bit MUST be set to a value of "1" to indicate a
         Reset-Request, and to respond to a receive failure (R-R) (see
         section 3., Sending Compressed Datagrams).  This bit is
         specific to the history number of the packet containing it.





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


      Res - Reserved

         These bits are reserved and MUST be set to 0

      C/D - Control/Data

         This bit is used by DCP to provide in-band negotiation in
         applications where out-of-band negotiation methods are not
         provided (i.e. Frame Relay).  Since CCP provides an out of band
         negotiating mechanism, this feature is not used in this
         application.  All packets MUST set this bit to a value of 0,
         which signifies that the packet is a data packet.  (Packets
         containing only Reset- Requests are classified as data
         packets.)

2.5.3.  History Number

      The number of the compression history which was used, ranging from
      1 to the negotiated value in the History Count field.

      If the negotiated History Count is less than 2, this field is
      removed.  If the negotiated History Count is 2 or more, but less
      than 256, this field is 1 octet.  If 256 or more histories are
      negotiated, this field is 2 octets, most significant octet first.

      If multiple histories are used in one direction on a link, the
      history number field MUST be present on all packets in both
      directions, and sized according to the largest number of histories
      in either direction.

      If multiple histories are used, this field MUST be present in
      uncompressed as well as compressed packets.

2.5.4.  Sequence Number

      The sequence number field is one octet in length.  When the check
      mode field is set to the "Sequence Number" or "Sequence Number +
      LCB" options, the sequence number field MUST be present in all
      data compression packets that contain a data field.

      The value of the sequence number field (the sequence number of the
      packet) MUST begin with "1" and increment modulo 256 on successive
      packets that contain data fields.  This number is relative to the
      history number used.

      On receipt of a packet with the R-A bit set to "0", if the
      sequence number of the packet is any number other than (N+1) mod
      256, where N is the sequence number of the last packet received



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


      for the same history, or an initial value of "0", a receive
      failure for that history has occurred.  The receive failure MUST
      be handled according to the synchronization procedure in section
      3.5.

      The sequence number MUST NOT be reset by the transmitter when a
      packet containing a Reset-Ack is sent. The decompressor MUST
      resynchronize its sequence number reference for the indicated
      history when a packet containing a Reset-Ack is received.

2.5.5.  Data

      The data field MUST contain a single datagram in either compressed
      or uncompressed form, depending on the state of the C/U bit in the
      Header.  This length of this field is always be an integer number
      of octets.  This field is required in all packets that do not have
      the R-R bit set to "1".

      If the C/U bit is set to "0", the data field contains the
      uncompressed form of the datagram.

      If the C/U bit is set to "1", the form of the data field is one
      block of compressed data as defined in 3.2 of X3.241-1994, with
      the following exceptions:  1) the end marker may be followed with
      additional octets containing only zeros;  2) if the final octet in
      the block of compressed data has a value of "0", then it MAY be
      removed from the data field.

      There is only one end marker per block of compressed data.

2.5.6.  Longitudinal Check Byte

      The LCB field is one octet in length, and if present MUST be the
      last octet in the data compression packet.  When the check-mode
      field is set to "LCB" or "Sequence Number + LCB", this field MUST
      be present in all packets where the data field contains compressed
      data.  This field MUST NOT be present in data compression packets
      where the data field contains uncompressed data.  This field
      contains the result of the LCB calculation, in accordance with the
      following paragraph.

      The LCB octet is the Exclusive-OR of FF(hex) and each octet of the
      uncompressed datagram (prior to the compression transformation).
      On receipt, the receiver computes the Exclusive-OR of FF(hex) and
      each octet of the decompressed packet.  If this value does not
      match the received LCB, then a receive failure for that history
      has occurred.  The receive failure is handled according to the
      history synchronization procedure in section 3.5.



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


2.5.7.  Compressed Data

   The Stac LZS compression algorithm is Defined in ANSI X3.241-1994
   [7]. The format of the compressed data is repeated here for
   informational purposes ONLY.

   <Compressed Stream> := [<Compressed String>] <End Marker>
   <Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>

   <Raw Byte> := <b><b><b><b><b><b><b><b>          (8-bit byte)
   <Compressed Bytes> := <Offset> <Length>

   <Offset> := 1 <b><b><b><b><b><b><b> |           (7-bit offset)
               0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
   <End Marker> := 110000000
   <b> := 1 | 0

   <Length> :=
   00        = 2     1111 0110      = 14
   01        = 3     1111 0111      = 15
   10        = 4     1111 1000      = 16
   1100      = 5     1111 1001      = 17
   1101      = 6     1111 1010      = 18
   1110      = 7     1111 1011      = 19
   1111 0000 = 8     1111 1100      = 20
   1111 0001 = 9     1111 1101      = 21
   1111 0010 = 10    1111 1110      = 22
   1111 0011 = 11    1111 1111 0000 = 23
   1111 0100 = 12    1111 1111 0001 = 24
   1111 0101 = 13     ...

3.  Sending Compressed Datagrams

   The reliable and efficient transport of datagrams on the data link
   depends on the following processes.

3.1.  Transmitter Process

      The compression operation results in either compressed or
      uncompressed data.  When a network datagram is received, it is
      assigned to a particular history buffer and processed according to
      ANSI X3.241-1994 to form compressed data or used as is to form
      uncompressed data.  Prior to the compression operation, if a
      Reset-Request is outstanding for the history buffer to be used,
      the buffer is cleared.  In performing the compression operation,
      if the process mode field is set to the value None ("0"), the
      history MUST only be updated if the result is compressed data.  If
      process mode field is set to the value Process-Uncompressed ("1"),



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


      the history MUST be updated when either compressed data or
      uncompressed data is produced.  Uncompressed data MAY be sent at
      any time.  Uncompressed data MUST be sent if compression causes
      enough expansion to cause the data compression datagram size to
      exceed the Information field's MRU.

      If the Process Mode field is set to the value None ("0") and the
      compressor has modified the history buffer before sending an
      uncompressed datagram, the history buffer MUST be cleared before
      the next datagram is processed.

      The output of the compression operation is placed in the
      information field of the datagram.  The C/U bit is set according
      to whether the data field contains compressed or uncompressed
      data.  If the sequence number field is present according the value
      of the check mode field, the sequence number counter for the
      applicable history number MUST be incremented and its value placed
      in the sequence number field.  If the data field contains
      compressed data, and Check Mode field is set accordingly, the LCB
      field is present and its value is computed as specified in section
      2.2.6.

      Upon reception of a packet containing a Reset-Request, the
      transmitting compressor MUST be cleared to an initial state, which
      includes clearing the history buffer.  If the data field of the
      packet containing the Reset-Request contains data, it is delivered
      to the local receiver as a normal data packet.  In addition to the
      reset of the compressor, a packet MUST be transmitted with Reset-
      Ack bit set to 1.  The data field of this packet MUST be filled
      with data.  If no data is ready for transmission, the transmitter
      MUST wait until data is ready before sending the Reset-Ack.

      If the history buffer is in the clear state (the history buffer
      contains no data bytes) prior to performing the compression
      operation, the resulting compressed or uncompressed packet MUST be
      sent with the R-A bit set to "1".

3.2.  Receiver Process

      When a data compression datagram is received from the peer, the
      R-R and R-A bits MUST be checked.  If the R-R bit is set, the
      local compression engine MUST be signaled that a Reset-Request has
      been received for the history specified by the history number
      field.  If the R-A bit is set, any outstanding receive failure for
      the specified history MUST be cleared.  If no receive failure is
      outstanding, and the sequence number field is present, its value
      checked. If a receive failure has occurred, it MUST be handled
      according to the history resynchronization mechanism described



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