diff options
Diffstat (limited to 'doc/rfc/rfc1967.txt')
| -rw-r--r-- | doc/rfc/rfc1967.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc1967.txt b/doc/rfc/rfc1967.txt new file mode 100644 index 0000000..5d50c22 --- /dev/null +++ b/doc/rfc/rfc1967.txt @@ -0,0 +1,1011 @@ + + + + + + +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 (hardware.sales@stac.com) 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] + +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 + + + below, and the remainder of the datagram is discarded. If no + receive failure is detected, the data is assigned to the indicated + decompression history buffer and processed according to process + mode field and C/U bit. + + If the C/U bit is set to "1", a single octet containing the value + 0x00 MUST be appended to the data field and the resulting + compressed data block MUST be decompressed according to ANSI + X3.241-1994. If the LCB field is present on the received + datagram, an LCB for the uncompressed data MUST be computed and + checked against the received LCB according to section 2.1. If a + receive failure has occurred, it MUST be handled according to the + History Resynchronization Mechanism described below. + + If the C/U bit is set to "0" and the process mode field is set to + the value Process-Uncompressed ("1"), the specified decompression + history buffer MUST be updated with the received uncompressed + data. + + If the C/U bit is set to "0" and process mode field is set to the + value None ("0"), the specified decompression history buffer MUST + NOT be modified. + + If the R-A bit is set to "1", the receiving decompressor MAY be + reset to an initial state. (However, due to the characteristics + of the Stac LZS algorithm, a decompressor reset is not required). + After reset, any compressed or uncompressed data contained in the + packet is processed. + + On the occurrence of a receive failure, an implementation MUST + transmit a packet with the R-R bit set to "1" (a Reset-Request) + and with the history number matching the history that had the + failure. The data field may be present if data is waiting to be + transported for that history, or the R-R bit may be set in a + packet transmitted without sequence number, data, or LCB fields. + Once a receive failure has occurred, the data in any subsequent + packets received for that history MUST be discarded until a packet + containing a Reset-Ack is received. It is the responsibility of + the receiver to ensure the reliability of the reset request- + acknowledge mechanism. This may require the transmission of an + additional Reset-Request before a Reset-Ack will be received. + +3.3. History Maintenance + + The History Count field determines the number of history buffers + to be maintained for the compression protocol. For example, each + history buffer could represent a separate logical connection + between the data compression peers. When maintaining a history, + + + +Schneider & Friend Informational [Page 13] + +RFC 1967 LZS-DCP August 1996 + + + the peers MUST use link error detection and signaling to ensure + that both the compressor and decompressor copies of each history + buffer are always identical. + + Setting the History Count field to the value "0" indicates that + the compression is to be on a connectionless basis. In this case, + a single history buffer is used and MUST be cleared at the + beginning of every datagram. The compressing entity MUST set the + R-A bit on all outgoing datagrams. + + When the History Count field is set to the value "1", a single + history buffer is maintained by each of the data compression + peers. (A single logical connection.) + + When the History Count field is set to a value greater than "1", + separate history buffers, error detection states, and signaling + states are maintained by the decompressing entity for each + history. The compressing peer may transmit data on any number of + separate histories, up to the value of the History Count field. + +3.4. Anti-Expansion Mechanism + + When one or more histories are negotiated and the Process Mode + field is set to None ("0"), there are 2 options on how to handle + packets that expand: + + 1) Send the expanded data and keep the history, thus allowing + loss of current bandwidth but preserving future bandwidth on + the link. + 2) Send the uncompressed data and clear the history, thus + conserving current bandwidth, but allowing possible loss of + future bandwidth on the link. + + When 1 or more histories are negotiated and the Process Mode field + is set to Process-Uncompressed ("1"), there is an additional + option: + + 3) Send the uncompressed data and do not clear the compression + history; the decompressor will update its history, thus + conserving the current bandwidth and future bandwidth on the + link. + +3.5. History Resynchronization Mechanism + + The DCP-Header includes R-R (Reset-Request) and R-A (Reset-Ack) + bits in order to provide a mechanism for indicating a receiver + failure in one direction of a compressed link without affecting + traffic in the other direction. A receive failure is determined + + + +Schneider & Friend Informational [Page 14] + +RFC 1967 LZS-DCP August 1996 + + + using the sequence number and/or LCB mechanism, according to the + value of the check mode field. + + Reset-Requests and Reset-Acks are specific to the history number + of the packet containing them. + + Reset-Request/Reset-Ack history synchronization signaling is + provided to recover from a loss of synchronization between peers, + especially in unreliable transport layers. As with all + compression algorithms, the decompressor can not recover from + dropped, erroneous, or mis-ordered datagrams, and will propagate + errors catastrophically until both peers are reset to an initial + state. + + The LZS-DCP protocol provides a means to detect these error + conditions: LCB for erroneous datagrams, and sequence number for + dropped or mis-ordered datagrams. There is a means for correcting + a loss of synchronization: clear both the failing compression and + decompression histories, and follow the transmitter and receiver + processes in sections 3.1. and 3.2. + +4. Configuration Option Format + + The LZS-DCP Configuration Option negotiates the use of LZS-DCP on the + link. By default or ultimate disagreement, no compression is used. + This Configuration Option is used in CCP, and can be used in other + negotiation mechanisms [2]. + + All implementations MUST support the default values. + + A summary of the LZS-DCP Configuration Option format is 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | History Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Check Mode | Process Mode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 23 + + Length + + 6 + + + +Schneider & Friend Informational [Page 15] + +RFC 1967 LZS-DCP August 1996 + + + History Count + + The History Count field is two octets, most significant octet + first, and specifies the maximum number of Compression Histories. + + The value 0 indicates that the implementation expects the peer to + clear the Compression History at the beginning of every packet. + If this value is selected, the transmitter MUST set the Reset-Ack + bit of every packet that contains compressed data. + + The value 1 is the default value and is used to indicate that only + one history is maintained. + + Other valid values range from 2 to 65535. The peer is not + required to send as many histories as the implementation indicates + that it can accept. However, it should be noted that resources + are allocated in each peer to support the number of negotiated + histories in this field. + +Check Mode + + The Check Mode indicates support of LCB and/or Sequence checking. + The use of check mode None (0) MUST NOT be used for history counts + greater than zero. + + 0 None + 1 LCB + 2 Sequence Number + 3 Sequence Number + LCB (default) + + Process Mode + + The Process Mode specifies how uncompressed packets are handled. + A value of None (0) indicates that uncompressed packets are not + processed by the decompressor. A value of Process-Uncompressed + + (1) indicates that uncompressed packets are processed by the + decompressor to update the history. + + 0 None (default) + 1 Process-Uncompressed + +Security Considerations + + Security issues are not discussed in this memo. + + + + + + +Schneider & Friend Informational [Page 16] + +RFC 1967 LZS-DCP August 1996 + + +Acknowledgments + + This document is based on, and uses much of the text of [5]. + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, Daydreamer, July 1994. + + [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC + 1962, June 1996. + + [3] Lempel, A., and J. Ziv, "A Universal Algorithm for Sequential + Data Compression", IEEE Transactions On Information Theory, + Vol. IT-23, No. 3, May 1977. + + [4] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July + 1994. + + [5] Friend, R., and W. Simpson, "PPP Stac LZS Compression + Protocol", RFC 1974, August 1996. + + [6] Motorola Information Systems Group, "Data Compression Protocol + (DCP) Proposal", TR-30.1 ad hoc contribution (email + reflector), September 21, 1995. + + [7] ANSI X3.241-1994, "American National Standard Data Compression + Method, Adaptive Coding with Sliding Window of Information + Interchange". + +Chair's Address + + The working group can be contacted via the current chair: + + Karl Fox + Ascend Communications + 3518 Riverside Drive, Suite 101 + Columbus, Ohio 43221 + + EMail: karl@ascend.com + + + + + + + + + + + +Schneider & Friend Informational [Page 17] + +RFC 1967 LZS-DCP August 1996 + + +Authors' Addresses + + Questions about this memo can also be directed to: + + Kevin Schneider + Adtran, Inc. + 901 Explorer Blvd. + Huntsville, AL 25806 + + Phone: (205) 971-8024 + EMail: kschneider@adtran.com + + + Robert Friend + Stac Technology + 12636 High Bluff Drive + San Diego, CA 92130-2093 + + Phone: (619) 794-4542 + EMail: rfriend@stac.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schneider & Friend Informational [Page 18] + |