idnits 2.17.1 draft-ietf-pppext-lzs-dcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 116: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 119: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 121: '...tem, but the full implications MUST be...' RFC 2119 keyword, line 125: '... MAY This word, or the adjecti...' (64 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1996) is 10177 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 808, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kevin Schneider 3 Internet Draft ADTRAN, Inc. 4 Robert Friend 5 Stac Technology 6 expires June 1996 8 PPP LZS-DCP Compression Protocol (LZS-DCP) 9 draft-ietf-pppext-lzs-dcp-01.txt 11 Status of this Memo 13 This document is a submission to the Point-to-Point Protocol Working 14 Group of the Internet Engineering Task Force (IETF). Comments should 15 be submitted to the ietf-ppp@merit.edu mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its Areas, 21 and its Working Groups. Note that other groups may also distribute 22 working documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material, or to cite them other than as a 28 ``working draft'' or ``work in progress.'' 30 Please check the 1id-abstracts.txt listing contained in the 31 internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, 32 vernera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current 33 status of any Internet Draft. 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method for 38 transporting multi-protocol datagrams over point-to-point links. 40 The PPP Compression Control Protocol [2] provides a method to 41 negotiate and utilize compression protocols over PPP encapsulated 42 links. 44 This document describes the use of the Stac LZS data compression 45 algorithm for compressing PPP encapsulated packets, using a DCP 46 header [6]. This protocol is an enhanced version of the non-DCP 47 (Option 17) PPP Stac LZS compression protocol [5], and will be 48 referred to as the LZS-DCP Compression Protocol. 50 DRAFT LZS-DCP December 1995 52 1. Introduction 54 Starting with a sliding window compression history, similar to LZ1 55 [3], Stac Electronics developed a compression algorithm identified as 56 Stac LZS. A PPP Compression Protocol for this compression algorithm 57 was developed and published [5]. That protocol was taken as a basis 58 for data compression work done in TIA for DSU/CSUs. As a part of 59 that standardization process, the concept of a portable Data 60 Compression Protocol (DCP) was introduced [6]. The resulting 61 (pending) TIA/EIA-655 standard uses this LZS-DCP protocol, which 62 incorporates DCP into a PPP compression protocol for Stac LZS. A 63 very similar protocol is currently out for ballot in the Frame Relay 64 Forum. (It is identical except for the size of the history number 65 field.) 67 This publication of the LZS-DCP compression protocol is in the 68 interest of providing a common compression protocol for Stac-LZS, and 69 to provide features that are not available with the LZS compression 70 protocol [5]. Some of the differences between the LZS-DCP and LZS 71 (compression type 17) protocols are as follows: 73 1) LZS-DCP provides an option which allows packets containing 74 uncompressible data to be transferred without requiring the 75 compression history to be cleared, potentially allowing a 76 higher compression ratio. A bit is included in the DCP 77 header to indicate whether the packet contains compressed or 78 uncompressed data. 80 2) LZS-DCP uses reset request and acknowledgment bits in the DCP 81 header that is included on each packet rather than using 82 CCP's reset request and acknowledge packets, which may result 83 in fewer discarded data packets during the REQ/ACK handshake. 85 3) LZS-DCP allows simultaneous use of both sequence numbers and 86 the LCB for compression error detection. 88 The Stac LZS compression algorithm supports both single and multiple 89 compression histories. A single compression history will require the 90 minimum amount of memory to implement, but may not provide as much 91 compression as a multiple history implementation. 93 Often, many streams of information are interleaved over the same 94 physical link. Each virtual connection will transmit data that is 95 independent of other virtual connections. Using multiple compression 96 histories can improve the compression ratio of a communication link 97 by associating separate compression histories with separate virtual 98 links of communication. 100 1.1. Licensing 102 DRAFT LZS-DCP December 1995 104 Source and object licenses are available on a non-discriminatory 105 basis. Hardware implementations are also available. Contact Stac 106 Electronics (hardware.sales@stac.com) for further information. 108 1.2. Specification of Requirements 110 In this document, several words are used to signify the requirements 111 of the specification. These words are often capitalized. 113 MUST This word, or the adjective "required", means that the 114 definition is an absolute requirement of the specification. 116 MUST NOT This phrase means that the definition is an absolute 117 prohibition of the specification. 119 SHOULD This word, or the adjective "recommended", means that there 120 may exist valid reasons in particular circumstances to 121 ignore this item, but the full implications MUST be 122 understood and carefully weighed before choosing a 123 different course. 125 MAY This word, or the adjective "optional", means that this 126 item is one of an allowed set of alternatives. An 127 implementation which does not include this option MUST be 128 prepared to interoperate with another implementation which 129 does include the option. 131 1.3. Terminology 133 This document frequently uses the following terms: 135 datagram The unit of transmission in the network layer (such as IP). 136 A datagram may be encapsulated in one or more packets 137 passed to the data link layer. 139 frame The unit of transmission at the data link layer. A frame 140 may include a header and/or a trailer, along with some 141 number of units of data. 143 packet The basic unit of encapsulation, which is passed across the 144 interface between the network layer and the data link 145 layer. A packet is usually mapped to a frame; the 146 exceptions are when data link layer fragmentation is being 147 performed, or when multiple packets are incorporated into a 148 single frame. 150 peer The other end of the point-to-point link. 152 silently discard 154 DRAFT LZS-DCP December 1995 156 This means the implementation discards the packet without 157 further processing. The implementation SHOULD provide the 158 capability of logging the error, including the contents of 159 the silently discarded packet, and SHOULD record the event 160 in a statistics counter. 162 2. LZS-DCP Packets 164 Before any LZS-DCP packets are communicated, PPP MUST reach the 165 Network-Layer Protocol phase, and the CCP Control Protocol MUST reach 166 the Opened state. 168 Exactly one LZS-DCP datagram is encapsulated in the PPP Information 169 field, where the PPP Protocol field indicates type hex 00FD 170 (compressed datagram) or type hex 00FB (Individual link compressed 171 datagram). Type hex 00FD is used when compression is negotiated over 172 a single physical link or when compression is negotiated over a 173 single bundle consisting of multiple physical links. Type hex 00FB 174 is used when compression is negotiated separately over individual 175 physical links to the same destination. For more information, please 176 refer to PPP Compression Control Protocol. 178 The maximum length of the LZS-DCP datagram transmitted over a PPP 179 link is the same as the maximum length of the Information field of a 180 PPP encapsulated packet. 182 Prior to compression, the uncompressed data begins with the PPP 183 Protocol ID Field. Protocol-Field-Compression MAY be used on this 184 value, if has been successfully negotiated for the link. 186 The PPP Protocol ID Field is followed by the original Information 187 field. The length of the uncompressed data field is limited only by 188 the allowed size of the compressed data field and the higher protocol 189 layers. 191 PPP Link Control Protocol packets MUST NOT be sent within LZS-DCP 192 packets. PPP Network Control Protocol packets MUST NOT be sent 193 within LZS-DCP packets. 195 2.1. Example LZS-DCP packets (shown using PPP in HDLC-like framing, 196 using Address-and-Control-Field-Compression and Protocol-Field- 197 Compression. - RFC 1662 ) 199 Compressed Packet: 201 DRAFT LZS-DCP December 1995 203 PPP | | PPP 204 PID | HDR SEQ DATA LCB | FCS 205 +-----+-----+-----+---................---+-----+-----+ 206 | F D | C 0 | n n | Compressed Data | y y | z z | 207 +-----+-----+-----+---................---+-----+-----+ 208 / \ 209 / Compression \ 210 / Transformation \ 211 / \ 212 /PPP \ 213 / PID PPP Information Field \ 214 +-----+----....................----+ 215 | x x | upper layer protocol data | 216 +-----+----....................----+ 218 Uncompressed Packet 220 PPP | | PPP 221 PID | HDR SEQ DATA | FCS 222 +-----+-----+-----+---................---+-----+ 223 | F D | 8 0 | n n | Un-compressed Data | z z | 224 +-----+-----+-----+---................---+-----+ 225 / \ 226 / \ 227 / \ 228 / \ 229 /PPP \ 230 / PID PPP Information Field \ 231 +-----+----....................----+ 232 | x x | upper layer protocol data | 233 +-----+----....................----+ 235 where: C0 and 80 are representative LZS-DCP headers; nn, xx, yy, 236 and zz are values determined by the packet's context. 238 2.2. Padding 240 PPP padding is not allowed in a LZS-DCP packet. However, on 241 compressed packets, padding may be accomplished by extending the 242 data field with zeros following the last compressed data octet 243 (see Section 2.1.1). This is referred to as LZS Padding. The 244 LCB, if present, MUST be the octet preceding the frame CRC. 246 2.3. Reliability and Sequencing 248 When no Compression History is kept, the algorithm does not depend 249 on a reliable link, and does not require that packets be delivered 250 in sequence. However, per packet compression results in a lower 251 compression ratio than it could be on a stream. 253 DRAFT LZS-DCP December 1995 255 Some reasons for clearing the history on a per packet basis 256 include: 258 - The link has a high error rate. 259 - The resources of the transmitter or receiver limit the ability 260 to maintain a compression history between packets. 262 When one or more compression Histories are negotiated, the packet 263 sequence MUST be preserved within specific History Numbers. There 264 is no sequence requirement between different History Numbers. 266 When using one or more compression histories, the implementation 267 MUST rely on either a lower layer reliable link protocol (RFC 268 1663), use a technique to keep the compressor and decompressor 269 histories in synchronization, or both. The LZS-DCP protocol 270 provides the Request-Req and Request-Ack bits in the DCP header 271 for this purpose. Since this synchronization is done on a per 272 history basis, the history number fields are required to be the 273 same size in both directions of the link. Any data contained in 274 the packet is processed after the signaling bits are processed. 276 The transmitter MAY clear a Compression History at any time. 278 The transmitter MUST clear a history after a receiving a Reset- 279 Request for a given History Number. 281 2.4. Data Expansion 283 The maximum expansion of Stac LZS is 12.5%. 285 A Maximum Receive Unit (MRU) MAY be negotiated that is 12.5% 286 larger than the size of a normal packet. Then, packets can always 287 be sent compressed regardless of expansion. 289 The transmitter MAY send an uncompressed LZS-DCP packet at any 290 time, although the typical use of uncompressed LZS-DCP packets is 291 as an anti-expansion mechanism. 293 When the expansion plus compression header exceeds the size of the 294 peer's MRU for the link, the data MUST be sent as an uncompressed 295 LZS-DCP packet. 297 An uncompressed LZS-DCP packet is transmitted according to the 298 format shown in Section 2.1, with the C/U bit set to 0 299 (Uncompressed-Data). If the Configuration Option Field 'Process 300 Mode', is set to a value of 1 (Process-Uncompressed), uncompressed 301 LZS-DCP packets are processed by both the compressor and the 302 decompressor, updating the histories of each. If the Process Mode 303 Field is set to a value of 0 (None), and the compressor has 304 modified its history before sending the uncompressed packet, the 305 compressor history MUST be clear. 307 DRAFT LZS-DCP December 1995 309 2.5. Packet Format 311 A summary of the LZS-DCP packet format is shown below. The fields 312 are transmitted from left to right. 314 0 1 2 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | PPP Protocol | DCP-Header | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | (History Number) | (Seq Num) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Data ... 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | (LCB) | 324 +-+-+-+-+-+-+-+-+ 326 2.5.1. PPP Protocol 328 The PPP Protocol field is described in the Point-to-Point Protocol 329 Encapsulation [1]. 331 When the LZS-DCP compression protocol is successfully negotiated 332 by the PPP Compression Control Protocol [2], the value is 00FD or 333 00FB hex. This value MAY be compressed when Protocol-Field- 334 Compression is negotiated. 336 2.5.2. DCP-Header 338 The DCP-Header is nominally one octet in length, but may be 339 extended through the use of the extension bit. 341 The format of the DCP-Header is as follows: 343 0 1 2 3 4 5 6 7 344 +-----+-----+-----+-----+-----+-----+-----+-----+ 345 | E | C/U | R-A | R-R | Res | Res | Res | C/D | 346 +-----+-----+-----+-----+-----+-----+-----+-----+ 348 E - Extension Bit 350 The E bit is the extension bit. If set to 0, it indicates that 351 another octet of the DCP-Header is present. Currently, this 352 bit is always set to 1, since the DCP-Header field is only one 353 octet long. 355 C/U - Compressed/Uncompressed Bit 357 The C/U indicates whether the data field contains compressed or 358 uncompressed data. A value of 1 indicates compressed data 359 (often referred to as a compressed packet), and a value of 0 361 DRAFT LZS-DCP December 1995 363 indicates uncompressed data (or an uncompressed packet). 365 R-A - Reset-Ack 367 The R-A bit is used to inform the decompressing peer that 368 the history buffer specified by the history number in the 369 packet was in the cleared state just before the data contained 370 in the packet was processed by the compression transformation 371 (see section 3., Sending Compressed Datagrams). This bit MUST 372 be set to a value of "1" to indicate a Reset-Ack, and to 373 acknowledge a receive failure (R-R) (see section 3., Sending 374 Compressed Datagrams). This bit is specific to the history 375 number of the packet containing it. 377 R-R - Reset-Request 379 The R-R bit is used to request that the compressing peer 380 clear the history buffer specified by the history number in the 381 packet. This bit MUST be set to a value of "1" to indicate a 382 Reset-Request, and to respond to a receive failure (R-R) (see 383 section 3., Sending Compressed Datagrams). This bit is 384 specific to the history number of the packet containing it. 386 Res - Reserved 387 These bits are reserved and MUST be set to 0 389 C/D - Control/Data 391 This bit is used by DCP to provide in-band negotiation in 392 applications where out-of-band negotiation methods are not 393 provided (i.e. Frame Relay). Since CCP provides an out of band 394 negotiating mechanism, this feature is not used in this 395 application. All packets MUST set this bit to a value of 0, 396 which signifies that the packet is a data packet. (Packets 397 containing only Reset- Requests are classified as data 398 packets.) 400 2.5.3. History Number 402 The number of the compression history which was used, ranging from 403 1 to the negotiated value in the History Count field. 405 If the negotiated History Count is less than 2, this field is 406 removed. If the negotiated History Count is 2 or more, but less 407 than 256, this field is 1 octet. If 256 or more histories are 408 negotiated, this field is 2 octets, most significant octet first. 410 If multiple histories are used in one direction on a link, the 412 DRAFT LZS-DCP December 1995 414 history number field MUST be present on all packets in both 415 directions, and sized according to the largest number of histories 416 in either direction. 418 If multiple histories are used, this field MUST be present in 419 uncompressed as well as compressed packets. 421 2.5.4. Sequence Number 423 The sequence number field is one octet in length. When the 424 check mode field is set to the "Sequence Number" or "Sequence 425 Number + LCB" options, the sequence number field MUST be present 426 in all data compression packets that contain a data field. 428 The value of the sequence number field (the sequence number of the 429 packet) MUST begin with "1" and increment modulo 256 on successive 430 packets that contain data fields. This number is relative to the 431 history number used. 433 On receipt of a packet with the R-A bit set to "0", if the 434 sequence number of the packet is any number other than (N+1) mod 435 256, where N is the sequence number of the last packet received 436 for the same history, or an initial value of "0", a receive 437 failure for that history has occurred. The receive failure MUST 438 be handled according to the synchronization procedure in section 439 3.5. 441 The sequence number MUST NOT be reset by the transmitter when a 442 packet containing a Reset-Ack is sent. The decompressor MUST 443 resynchronize its sequence number reference for the indicated 444 history when a packet containing a Reset-Ack is received. 446 2.5.5. Data 448 The data field MUST contain a single datagram in either 449 compressed or uncompressed form, depending on the state of the C/U 450 bit in the Header. This length of this field is always be an 451 integer number of octets. This field is required in all packets 452 that do not have the R-R bit set to "1". 454 If the C/U bit is set to "0", the data field contains the 455 uncompressed form of the datagram. 457 If the C/U bit is set to "1", the form of the data field is 458 one block of compressed data as defined in 3.2 of X3.241-1994, 459 with the following exceptions: 1) the end marker may be followed 460 with additional octets containing only zeros; 2) if the final 461 octet in the block of compressed data has a value of "0", then it 463 DRAFT LZS-DCP December 1995 465 MAY be removed from the data field. 467 There is only one end marker per block of compressed data. 469 2.5.6. Longitudinal Check Byte 471 The LCB field is one octet in length, and if present MUST be the 472 last octet in the data compression packet. When the check-mode 473 field is set to "LCB" or "Sequence Number + LCB", this field MUST 474 be present in all packets where the data field contains compressed 475 data. This field MUST NOT be present in data compression packets 476 where the data field contains uncompressed data. This field 477 contains the result of the LCB calculation, in accordance with the 478 following paragraph. 480 The LCB octet is the Exclusive-OR of FF(hex) and each octet of the 481 uncompressed datagram (prior to the compression transformation). 482 On receipt, the receiver computes the Exclusive-OR of FF(hex) 483 and each octet of the decompressed packet. If this value does not 484 match the received LCB, then a receive failure for that history 485 has occurred. The receive failure is handled according to the 486 history synchronization procedure in section 3.5. 488 2.5.7. Compressed Data 490 The Stac LZS compression algorithm is Defined in ANSI X3.241-1994 491 [7]. The format of the compressed data is repeated here for 492 informational purposes ONLY. 494 := [] 495 := 0 | 1 497 := (8-bit byte) 498 := 500 := 1 | (7-bit offset) 501 0 (11-bit offset) 502 := 110000000 503 := 1 | 0 505 := 506 00 = 2 1111 0110 = 14 507 01 = 3 1111 0111 = 15 508 10 = 4 1111 1000 = 16 509 1100 = 5 1111 1001 = 17 510 1101 = 6 1111 1010 = 18 511 1110 = 7 1111 1011 = 19 512 1111 0000 = 8 1111 1100 = 20 513 1111 0001 = 9 1111 1101 = 21 515 DRAFT LZS-DCP December 1995 517 1111 0010 = 10 1111 1110 = 22 518 1111 0011 = 11 1111 1111 0000 = 23 519 1111 0100 = 12 1111 1111 0001 = 24 520 1111 0101 = 13 ... 522 3. Sending Compressed Datagrams 524 The reliable and efficient transport of datagrams on the data link 525 depends on the following processes. 527 3.1. Transmitter Process 529 The compression operation results in either compressed or 530 uncompressed data. When a network datagram is received, it is 531 assigned to a particular history buffer and processed according 532 to ANSI X3.241-1994 to form compressed data or used as is to 533 form uncompressed data. Prior to the compression operation, if a 534 Reset-Request is outstanding for the history buffer to be used, 535 the buffer is cleared. In performing the compression operation, 536 if the process mode field is set to the value None ("0"), the 537 history MUST only be updated if the result is compressed data. 538 If process mode field is set to the value Process-Uncompressed 539 ("1"), the history MUST be updated when either compressed data or 540 uncompressed data is produced. Uncompressed data MAY be sent at 541 any time. Uncompressed data MUST be sent if compression causes 542 enough expansion to cause the data compression datagram size to 543 exceed the Information field's MRU. 545 If the Process Mode field is set to the value None ("0") and the 546 compressor has modified the history buffer before sending an 547 uncompressed datagram, the history buffer MUST be cleared before 548 the next datagram is processed. 550 The output of the compression operation is placed in the 551 information field of the datagram. The C/U bit is set 552 according to whether the data field contains compressed or 553 uncompressed data. If the sequence number field is present 554 according the value of the check mode field, the sequence number 555 counter for the applicable history number MUST be incremented and 556 its value placed in the sequence number field. If the data field 557 contains compressed data, and Check Mode field is set accordingly, 558 the LCB field is present and its value is computed as specified in 559 section 2.2.6. 561 Upon reception of a packet containing a Reset-Request, the 562 transmitting compressor MUST be cleared to an initial state, which 563 includes clearing the history buffer. If the data field of the 564 packet containing the Reset-Request contains data, it is delivered 565 to the local receiver as a normal data packet. In addition to the 566 reset of the compressor, a packet MUST be transmitted with Reset- 568 DRAFT LZS-DCP December 1995 570 Ack bit set to 1. The data field of this packet MUST be filled 571 with data. If no data is ready for transmission, the transmitter 572 MUST wait until data is ready before sending the Reset-Ack. 574 If the history buffer is in the clear state (the history buffer 575 contains no data bytes) prior to performing the compression 576 operation, the resulting compressed or uncompressed packet MUST 577 be sent with the R-A bit set to "1". 579 3.2. Receiver Process 581 When a data compression datagram is received from the peer, the 582 R-R and R-A bits MUST be checked. If the R-R bit is set, the 583 local compression engine MUST be signaled that a Reset-Request 584 has been received for the history specified by the history number 585 field. If the R-A bit is set, any outstanding receive failure for 586 the specified history MUST be cleared. If no receive failure is 587 outstanding, and the sequence number field is present, its value 588 checked. If a receive failure has occurred, it MUST be handled 589 according to the history resynchronization mechanism described 590 below, and the remainder of the datagram is discarded. If no 591 receive failure is detected, the data is assigned to the indicated 592 decompression history buffer and processed according to process 593 mode field and C/U bit. 595 If the C/U bit is set to "1", a single octet containing the value 596 0x00 MUST be appended to the data field and the resulting 597 compressed data block MUST be decompressed according to ANSI 598 X3.241-1994. If the LCB field is present on the received 599 datagram, an LCB for the uncompressed data MUST be computed and 600 checked against the received LCB according to section 2.1. If a 601 receive failure has occurred, it MUST be handled according to the 602 History Resynchronization Mechanism described below. 604 If the C/U bit is set to "0" and the process mode field is set to 605 the value Process-Uncompressed ("1"), the specified decompression 606 history buffer MUST be updated with the received uncompressed 607 data. 609 If the C/U bit is set to "0" and process mode field is set to the 610 value None ("0"), the specified decompression history buffer MUST 611 NOT be modified. 613 If the R-A bit is set to "1", the receiving decompressor MAY be 614 reset to an initial state. (However, due to the characteristics 615 of the Stac LZS algorithm, a decompressor reset is not required). 616 After reset, any compressed or uncompressed data contained in the 617 packet is processed. 619 On the occurrence of a receive failure, an implementation MUST 621 DRAFT LZS-DCP December 1995 623 transmit a packet with the R-R bit set to "1" (a Reset-Request) 624 and with the history number matching the history that had the 625 failure. The data field may be present if data is waiting to be 626 transported for that history, or the R-R bit may be set in a 627 packet transmitted without sequence number, data, or LCB fields. 628 Once a receive failure has occurred, the data in any subsequent 629 packets received for that history MUST be discarded until a 630 packet containing a Reset-Ack is received. It is the 631 responsibility of the receiver to ensure the reliability of the 632 reset request-acknowledge mechanism. This may require the 633 transmission of an additional Reset-Request before a Reset-Ack 634 will be received. 636 3.3. History Maintenance 638 The History Count field determines the number of history buffers 639 to be maintained for the compression protocol. For example, each 640 history buffer could represent a separate logical connection 641 between the data compression peers. When maintaining a history, 642 the peers MUST use link error detection and signaling to ensure 643 that both the compressor and decompressor copies of each history 644 buffer are always identical. 646 Setting the History Count field to the value "0" indicates that 647 the compression is to be on a connectionless basis. In this case, 648 a single history buffer is used and MUST be cleared at the 649 beginning of every datagram. The compressing entity MUST set the 650 R-A bit on all outgoing datagrams. 652 When the History Count field is set to the value "1", a single 653 history buffer is maintained by each of the data compression 654 peers. (A single logical connection.) 656 When the History Count field is set to a value greater than "1", 657 separate history buffers, error detection states, and signaling 658 states are maintained by the decompressing entity for each 659 history. The compressing peer may transmit data on any number of 660 separate histories, up to the value of the History Count field. 662 3.4. Anti-Expansion Mechanism 664 When one or more histories are negotiated and the Process Mode 665 field is set to None ("0"), there are 2 options on how to handle 666 packets that expand: 668 1) Send the expanded data and keep the history, thus allowing 669 loss of current bandwidth but preserving future bandwidth on 670 the link. 671 2) Send the uncompressed data and clear the history, thus 672 conserving current bandwidth, but allowing possible loss of 674 DRAFT LZS-DCP December 1995 676 future bandwidth on the link. 678 When 1 or more histories are negotiated and the Process Mode field 679 is set to Process-Uncompressed ("1"), there is an additional 680 option: 682 3) Send the uncompressed data and do not clear the compression 683 history; the decompressor will update its history, thus 684 conserving the current bandwidth and future bandwidth on the 685 link. 687 3.5. History Resynchronization Mechanism 689 The DCP-Header includes R-R (Reset-Request) and R-A (Reset-Ack) 690 bits in order to provide a mechanism for indicating a receiver 691 failure in one direction of a compressed link without affecting 692 traffic in the other direction. A receive failure is determined 693 using the sequence number and/or LCB mechanism, according to the 694 value of the check mode field. 696 Reset-Requests and Reset-Acks are specific to the history number 697 of the packet containing them. 699 Reset-Request/Reset-Ack history synchronization signaling is 700 provided to recover from a loss of synchronization between peers, 701 especially in unreliable transport layers. As with all 702 compression algorithms, the decompressor can not recover from 703 dropped, erroneous, or mis-ordered datagrams, and will propagate 704 errors catastrophically until both peers are reset to an initial 705 state. 707 The LZS-DCP protocol provides a means to detect these error 708 conditions: LCB for erroneous datagrams, and sequence number for 709 dropped or mis-ordered datagrams. There is a means for correcting 710 a loss of synchronization: clear both the failing compression and 711 decompression histories, and follow the transmitter and receiver 712 processes in sections 3.1. and 3.2. 714 4. Configuration Option Format 716 The LZS-DCP Configuration Option negotiates the use of LZS-DCP on the 717 link. By default or ultimate disagreement, no compression is used. 718 This Configuration Option is used in CCP, and can be used in other 719 negotiation mechanisms. 721 All implementations MUST support the default values. 723 A summary of the LZS-DCP Configuration Option format is shown below. 724 The fields are transmitted from left to right. 726 DRAFT LZS-DCP December 1995 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Type | Length | History Count | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Check Mode | Process Mode | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Type 738 23 740 Length 742 6 744 History Count 746 The History Count field is two octets, most significant octet 747 first, and specifies the maximum number of Compression Histories. 749 The value 0 indicates that the implementation expects the peer to 750 clear the Compression History at the beginning of every packet. 751 If this value is selected, the transmitter MUST set the Reset-Ack 752 bit of every packet that contains compressed data. 754 The value 1 is the default value and is used to indicate that only 755 one history is maintained. 757 Other valid values range from 2 to 65535. The peer is not 758 required to send as many histories as the implementation indicates 759 that it can accept. However, it should be noted that resources 760 are allocated in each peer to support the number of negotiated 761 histories in this field. 763 Check Mode 765 The Check Mode indicates support of LCB and/or Sequence checking. 766 The use of check mode None (0) MUST NOT be used for history counts 767 greater than zero. 769 0 None 770 1 LCB 771 2 Sequence Number 772 3 Sequence Number + LCB (default) 774 Process Mode 776 The Process Mode specifies how uncompressed packets are handled. 777 A value of None (0) indicates that uncompressed packets are not 778 processed by the decompressor. A value of Process-Uncompressed 780 DRAFT LZS-DCP December 1995 782 (1) indicates that uncompressed packets are processed by the 783 decompressor to update the history. 785 0 None (default) 786 1 Process-Uncompressed 788 Security Considerations 790 Security issues are not discussed in this memo. 792 Acknowledgments 794 This document is based on, and uses much of the text of [5]. 796 References 798 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 799 51, RFC 1661, Daydreamer, July 1995. 801 [2] Rand, D., "The PPP Compression Control Protocol (CCP)", work 802 in progress. 804 [3] Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential 805 Data Compression", IEEE Transactions On Information Theory, 806 Vol. IT-23, No. 3, May 1977. 808 [4] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 809 1995. 811 [5] Lutz, B., Simpson, B. "PPP Stac LZS Compression Protocol", 812 work in progress. 814 [6] Motorola Information Systems Group, "Data Compression Protocol 815 (DCP) Proposal", TR-30.1 ad hoc contribution (email 816 reflector), September 21, 1995. 818 [7] ANSI X3.241-1994, "American National Standard Data Compression 819 Method, Adaptive Coding with Sliding Window of Information 820 Interchange". 822 DRAFT LZS-DCP December 1995 824 Chair's Address 826 The working group can be contacted via the current chair: 828 Fred Baker 829 Senior Software Engineer 830 Cisco Systems 831 519 Lado Drive 832 Santa Barbara, California 93111 833 (805) 681-0115 835 EMail: fred@cisco.com 837 Author's Address 839 Questions about this memo can also be directed to: 841 Kevin Schneider 842 Adtran, Inc. 843 901 Explorer Blvd. 844 Huntsville, AL 25806 846 (205) 971-8024 848 Email: kschneider@adtran.com 850 Robert Friend 851 Stac Technology 852 12636 High Bluff Drive 853 San Diego, CA 92130-2093 855 (619) 794-4542 857 Email: rfriend@stac.com 859 DRAFT LZS-DCP December 1995 861 Table of Contents 863 1. Introduction .......................................... 1 864 1.1 Licensing ....................................... 1 865 1.2 Specification of Requirements ................... 2 866 1.3 Terminology ..................................... 2 868 2. LZS-DCP Packets ....................................... 3 869 2.1 Example LZS-DCP Packets ......................... 3 870 2.2 Padding ......................................... 4 871 2.3 Reliabliity and Squencing ....................... 4 872 2.4 Data Expansion .................................. 5 873 2.5 Packet Format ................................... 6 874 2.5.1 PPP Protocol .................................... 6 875 2.5.2 DCP-Header ...................................... 6 876 2.5.3 History Number .................................. 7 877 2.5.4 Sequence Number ................................. 8 878 2.5.5 Data ............................................ 8 879 2.5.6 Longitudinal Check Byte ......................... 9 880 2.5.7 Compressed Data ................................. 9 882 3. Sending Compressed Datagrams ..................... 10 883 3.1 Transmitter Process ............................. 10 884 3.2 Receiver Process ................................ 11 885 3.3 History Maintenance ............................. 12 886 3.4 Anti-Expansion Mechanism ........................ 12 887 3.5 History Resynchronization Mechanism ............. 13 889 4. Configuration Option Format ........................... 13 891 SECURITY CONSIDERATIONS ...................................... 15 893 REFERENCES ................................................... 15 895 CHAIR'S ADDRESS ........................................... 16 897 AUTHORS' ADDRESS ............................................. 16