RFC 1977 (rfc1977) - Page 3 of 25


PPP BSD Compression Protocol



Alternative Format: Original Text Document

< Previous
Next >


RFC 1977                    PPP BSD Compress                 August 1996


   Reliability and Sequencing

      BSD Compress requires the packets to be delivered in sequence.  It
      relies on Reset-Request and Reset-Ack CCP packets or on
      renegotiation of the Compression Control Protocol [2] to indicate
      loss of synchronization between the transmitter and receiver.  The
      HDLC FCS detects corrupted packets and the normal mechanisms
      discard them.  Missing or out of order packets are detected by the
      sequence number in each packet.  The packet sequence number ought
      to be checked before decoding the packet.

      Instead of transmitting a Reset-Request packet when detecting a
      decompression error, the receiver MAY momentary force CCP to drop
      out of the Opened state by transmitting a new CCP Configure-
      Request.  This method is more expensive than using Reset-Requests.

      When the receiver first encounters an unexpected sequence number
      it SHOULD send a Reset-Request CCP packet as defined in the
      Compression Control Protocol.  When the transmitter sends the
      Reset-Ack or when the receiver receives a Reset-ACK, they must
      reset the sequence number to zero, clear the compression
      dictionary, and resume sending and receiving compressed packets.
      The receiver MUST discard all compressed packets after detecting
      an error and until it receives a Reset-Ack.  This strategy can be
      thought of as abandoning the transmission of one "file" and
      starting the transmission of a new "file."

      The transmitter must clear its compression dictionary and respond
      with a Reset-Ack each time it receives a Reset-Request, because it
      cannot know if previous Reset-Acks reached the receiver.  The
      receiver MUST clear its compression dictionary each time it
      receives a Reset-Ack, because the transmitter will have cleared
      its compression dictionary.

      When the link is busy, one decompression error is usually followed
      by several more before the Reset-Ack can be received.  It is
      undesirable to transmit Reset-Requests more frequently than the
      round-trip-time of the link, because redundant Reset-Requests
      cause unnecessary compression dictionary clearing.  The receiver
      MAY transmit an additional Reset-Request each time it receives a
      compressed or uncompressed packet until it finally receives a
      Reset-Ack, but the receiver ought not transmit another Reset-
      Request until the Reset-Ack for the previous one is late.  The
      receiver MUST transmit enough Reset-Request packets to ensure that
      the transmitter receives at least one.  For example, the receiver
      might choose to not transmit another Reset-Request until after one
      second (or, of course, a Reset-Ack has been received and
      decompression resumed).



Schryver                     Informational


< Previous
Next >


Web Standards & Support:

Link to and support eLook.org Powered by LoadedWeb Web Hosting
Valid XHTML 1.0! Valid CSS! eLook.org FireFox Extensions