idnits 2.17.1 draft-ietf-pppext-wcp-00.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-24) 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 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. ** There are 39 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 162 has weird spacing: '... as the maste...' -- 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 (November 1995) is 10388 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) ** Obsolete normative reference: RFC 1548 (ref. '1') (Obsoleted by RFC 1661) -- No information found for draft-ieft-pppext-compression - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Wing Lam 2 Internet Draft Keith Mader 3 Bay Networks 4 November 1995 6 PPP WAN Compression Protocol 7 draft-ietf-pppext-wcp-00.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol 12 Working Group of the Internet Engineering Task Force (IETF). 13 Comments should be submitted to the ietf-ppp@merit.edu mailing 14 list. 16 Distribution of this memo is unlimited. 18 This document is an Internet Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 Areas, and its Working Groups. Note that other groups may also 21 distribute working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months, and may be updated, replaced, or obsoleted by other 25 documents at any time. It is not appropriate to use Internet 26 Drafts as reference material, or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To learn the current status of any Internet Draft, please check 30 the ``1id-abstracts.txt'' listing contained in the internet- 31 drafts Shadow Directories on on nic.ddn.mil, ds.internic.net, 32 venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the 33 current status of any Internet Draft. 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method 38 for transporting multi-protocol datagrams over point-to-point 39 links. The PPP Compression Control Protocol [2] provides a 40 method for negotiating data compression over PPP links. 42 This document describes the use of the WAN Compression Protocol 43 (WCP) to provide an algorithm independent transport for 44 compressed datagrams over point-to-point links. 46 1. Conventions 48 The following language conventions are used in the items of 49 specification in this document: 51 o Must, Shall or Mandatory -- the item is an absolute 52 requirement of the specification. 54 o Should or Recommended -- the item should generally be followed 55 for all but exceptional circumstances. 57 o May or Optional -- the item is truly optional and may be 58 followed or ignored according to the needs of the implementor. 60 All drawings in this document are drawn with the left-most bit as 61 the high order bit for transmission. For example: 63 0 1 2 3 4 5 6 7 bits 64 +---+---+---+---+---+---+---+---+ 66 +---+---+---+---+---+---+---+---+ 67 | flag (7E hexadecimal) | 68 +---+---+---+---+---+---+---+---+ 69 | address 0x'FF' | 70 +---+---+---+---+---+---+---+---+ 71 : : 72 : : 73 +---+---+---+---+---+---+---+---+ 75 Drawings that would be too large to fit into one page if each 76 octet were presented on a single line are drawn with two octets 77 per line. These are also drawn with the left-most bit as the 78 high order bit for transmission. There will be a "|" to 79 distinguish between octets as shown in the following example. 81 |--- octet one ---|--- octet two ---| 82 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 83 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 85 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 86 | flag 0x'7E' | address 0x'FF' | 87 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 88 : : 89 : : 90 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 92 2. Introduction 94 This document describes the WAN Compression Protocol (WCP), which 95 is a transport protocol designed specifically for carrying 96 compressed packets across WAN links. The primary features of WCP 97 include the negotiation of compression algorithms and parameters, 98 the transport of compressed packets, and the detection and 99 retransmission of lost or corrupted packets. 101 The negotiation feature of WCP allows various compression 102 algorithms to be used. It also allows for the various algorithm 103 specific compression parameters (such as dictionary size, 104 compression mode) to be negotiated. 106 The transport mechanism of WCP provides the means for 107 transporting compressed packets, as well as non compressed 108 packets. Compressed packets are sent when the compressed version 109 of a packet is smaller than the original non compressed packet. 110 However, when the compressed version of a packet is larger than 111 the original non compressed packet, WCP transports the original 112 packet instead. The transport mechanism also provides unique 113 identification of packets compressed using continuous or per 114 packet compression methods. 116 WCP is a sequenced, non-windowed protocol that does not rely on 117 positive acknowledgments. In transporting packets across the 118 network, WCP employs a 12-bit sequence number to detect packet 119 loss. Upon detection of packet loss, WCP selectively requests 120 the retransmission of the lost packets thus avoiding a reset of 121 the compression dictionary. 123 3. WCP Frame Format 125 Before any WCP packets may be communicated, PPP must reach the 126 Network-Layer Protocol phase [1], and the Compression Control 127 Protocol must reach the Opened state. 129 When WCP is negotiated as the compression algorithm, the PPP 130 protocol field indicates type 0x'00FD' (compressed datagram). 132 Exactly one WCP datagram is encapsulated in the PPP Information 133 field. The compressed form of the original PPP datagram starting 134 with the PPP Protocol field is carried in the data portion of the 135 WCP frame. The format shall be as follows: 137 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 138 | address 0x'FF' | control 0x'03' | 139 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 140 | PPP Protocol 0x'00FD' | 141 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 142 | WCP header | 143 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 144 | Data | 145 : . : 146 : . : 147 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 148 | FCS | 149 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 151 4. WCP Procedures 153 All WCP procedures involve a WCP connection. A WCP connection is 154 the association of two ends of a point-to-point link. A WCP 155 connection consists of two rather independent sub-connections. 156 Each of these sub-connections define the association of the 157 compressor on one side of the connection and the decompressor on 158 the other side of the connection. These sub-connections are 159 independent in that operations on one of the sub-connections, for 160 example the compression algorithm used, does not imply the same 161 for the other. With the various procedures of WCP, the 162 decompressor side of a sub-connection behaves as the master by 163 initiating requests to the compressor, while the compressor side 164 of a sub-connection behaves as the slave by responding to 165 requests made by the decompressor. 167 During the process of transporting compressed data over a 168 connection, WCP transitions through several distinct phases. 169 Each of these phases, and the conditions and WCP packets 170 associated with each phase are described in the following 171 sections. 173 4.1. Connection Phase 175 WCP begins its operation in the connection phase. This phase is 176 initiated with a connect request message being sent on the PPP 177 link. The format of this message and appropriate responses are 178 as follows: 180 Connect Request Message Format 181 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 182 | 1 1 1 1 0 1 0 0| TID octet 1 | 183 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 184 | TID octet 2 | WCP Revision | 185 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 186 | Initiator | Sequence Size | 187 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 188 | Algorithm Count | Algorithm 1 | 189 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 190 : | : 191 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 192 | Algorithm n | 193 +--+--+--+--+--+--+--+--+ 194 Connect Acknowledge Message Format 195 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 196 | 1 1 1 1 0 1 0 1| TID octet 1 | 197 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 198 | TID octet 2 | WCP Revision | 199 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 200 | Sequence Size | Algorithm | 201 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 202 | ReXmit Enable | 203 +--+--+--+--+--+--+--+--+ 205 Connect NAK Message Format 206 +---+---+---+---+---+---+---+---+ 207 | 1 1 1 1 0 1 1 0 | 208 +---+---+---+---+---+---+---+---+ 210 Connect Request messages, as well as other WCP control messages, 211 use a 16 bit transaction identifier (TID). Each side of the WCP 212 connection should initialize the TID to zero and increment its 213 value by one for each subsequent control message request. 215 There are 5 fields defined in a connect request message. These 216 fields are as follows: 218 o Revision -- this field specifies the supported revision of the 219 WCP protocol being used. The current value is 2. Future 220 revisions to WCP shall append any changes to the end of the 221 existing message format and increment the revision number by 222 one. If the receiver of a connect message supports a version 223 lower than the specified revision, it should process the 224 message using its current lower version. The sender of a 225 connect acknowledge should respond with the version that is 226 currently being supported. The receiver of a connect request 227 message may send a connect nak message if it can not support 228 the requested version. 230 o Initiator -- this field specifies whether the sender of the 231 connect request has initiated the request on its own or as a 232 result of a connect request from the other half of the WCP 233 connection. When the compressor of one side receives a 234 connect request message with this field set, the decompressor 235 must also enter the connection phase and generate a connect 236 request with the initiator field clear. This is useful when 237 configuration has changed on one side of the WCP connection 238 that may effect the negotiated values on the other side of the 239 WCP connection. Support of this field is optional. 240 Implementations not supporting the initiator field must set 241 the field to zero. 243 o Sequence Size -- this field specifies the size of the sequence 244 number used in WCP data packets. The current value of 1, 245 indicating a 12 bit sequence number, must be supported. If 246 the receiver of a connect request message supports a value 247 lower than indicated in the request, the receiver should reply 248 with a connect acknowledge message indicating the supported 249 value. The receiver may send a connect nak if it can not 250 support the requested sequence size. 252 o Number of Algorithms -- this field specifies the number of 253 algorithms contained in the connect request message. 255 o Algorithms -- these fields specify the various compression 256 algorithms supported in order of preference, by the sender of 257 the connect request message. The receiver of this message 258 should choose among these algorithms and indicate it 259 preference in the connect acknowledgment. The receiver of the 260 connect request must reply with a connect nak if it can not 261 support any of the requested algorithms. The values of the 262 various algorithms is listed in the appendix. 264 There are 4 fields defined in a connect acknowledge message. 265 These fields are as follows: 267 o Revision -- this field specifies the supported revision of the 268 WCP protocol being used. 270 o Sequence Size -- this field specifies the supported sequence 271 size being used. 273 o Algorithm -- this field specifies the negotiated compression 274 algorithm being used. 276 o ReXmit Enable -- this field specifies whether the sender of 277 this message maintains a transmission history. The receiver 278 of a connect acknowledge message with this field set should 279 request retransmission of lost or corrupted packets. The 280 receiver of a connect acknowledge message with this field set 281 to zero must not generate retransmit request messages. 283 The sender of the connect request message should retry if neither 284 a connect acknowledge or a connect nak is received. It should 285 stop retrying after a period of time T1. A recommended retry 286 interval is n seconds for the nth retry, where n is less than 30, 287 and then 30 thereafter. A recommended value for T1 is 10 288 minutes. 290 The receiver of a connect acknowledgment may choose to initiate a 291 disconnect sequence if any of the values specified are not 292 acceptable. It must also ignore any connect acknowledgment 293 received with a TID that does not match the expected TID. 295 4.2. Initialization Phase 297 The decompressor, upon entering the initialization phase, sends 298 an initialization request message to the compressor on the other 299 end of the WCP connection. The compressor should respond with an 300 initialization acknowledgment message containing the acceptable 301 parameters. When an initialization ack message is not received in 302 time T2, a new initialization request must be sent. If the 303 maximum retry count N2 is reached, the decompressor enters the 304 disconnect phase. The recommended value to T2 is 2 seconds, and 305 the recommended value for N2 is 10. 307 The exact format of the initialization request and acknowledgment 308 messages are algorithm specific, but must follow the general 309 structure. Specifically, each initialization request message 310 must minimally contain a TID. Each initialization acknowledgment 311 message must minimally contain a TID. The format of 312 initialization request and acknowledge messages for various 313 compression algorithms are described in the appendix. 315 The format of the initialization request and initialization 316 acknowledgment for the MagnaLink compression algorithm are as 317 follows: 319 Init Request Message Format 320 (MagnaLink example) 321 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 322 | 1 1 1 1 1 0 0 1| TID octet 1 | 323 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 324 | TID octet 2 | Algorithm Revision | 325 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 326 | Initiator | Dictionary Size | 327 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 328 | PPC Enable | PIB Enable | 329 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 331 Init Acknowledge Message Format 332 (MagnaLink Example) 333 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 334 | 1 1 1 1 1 0 1 0| TID octet 1 | 335 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 336 | TID octet 2 | Algorithm Revision | 337 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 338 | Dictionary Size | PPC Enable | 339 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 340 | PIB Enable | 341 +--+--+--+--+--+--+--+--+ 343 The fields of the MagnaLink initialization request message are as 344 follows: 346 o Algorithm Revision -- this field specifies the version of the 347 compression algorithm being supported. The current value of 348 this field is one. 350 o Dictionary Size -- this field specifies the size of the 351 compression/decompression dictionary. A one in this field 352 indicates the use of an 8K dictionary, and a two in this field 353 specifies a 32K dictionary. All other values are reserved. 354 An 8K dictionary must be supported. The receiver of the 355 initialization request may set the dictionary size field in 356 the initialization acknowledgment message to one if a 32K 357 dictionary is not supported. 359 o PPC Enable -- this field specifies if the sender of the 360 initialization request message wishes to perform packet by 361 packet compression for this WCP connection. A one in this 362 field indicates packet by packet compression mode. This mode 363 must be supported. A zero in this field identifies continuous 364 compression mode. The receiver of the initialization request 365 must set this field in the initialization ack message if this 366 field is set in the request message. 368 o PIB Enable -- this field specifies if the sender of the 369 initialization request wishes to perform protocol integrity 370 byte checking. A zero in this field indicates that no PIB 371 checking should be performed. This mode must be supported. A 372 one in this field indicates that PIB checking should be 373 performed. The receiver of the initialization request must 374 set this field in the initialization ack message to zero if 375 this field is clear in the request message. 377 The initialization phase may be re-entered if either side of the 378 WCP connection wishes to re-negotiate any of all of the 379 initialization values. For example, if the decompressor on one 380 side of the WCP connection is running in CPC mode and detects a 381 high level of packet loss over time, it may choose to enter PPC 382 mode by re-entering the initialization phase. 384 4.3. Data Transfer Phase 386 The data transfer phase is entered when the initialization phase 387 has completed. 389 There are eight messages defined for carrying compressed data. 390 These messages are formed by the combination of the following 391 three attributes: 393 o CPC/PPC -- indicates if the compressed data was generated 394 using continuous packet compression (CPC) or packet by packet 395 compression (PPC). The CPC mode compression maintains 396 dictionary information across packet boundaries whereas the 397 PPC mode re-initializes the dictionary for each new packet. 399 o Compressed/Non-Compressed -- indicates if the packet contains 400 compressed or original data. If the packet is non-compressed 401 and CPC mode is indicated, the decompressor must update the 402 dictionary to include the non-compressed data in order to 403 maintain dictionary synchronization. 405 o TPPC -- indicates a request to enter transient packet by 406 packet compression (TPPC) mode. This signals to the receiver, 407 that subsequent packets should be compressed using PPC mode. 408 Support for TPPC is optional however implementations not 409 supporting TPPC must be able to receive and process packets 410 indicated as TPPC. 412 The format of packets sent during the data transfer phase are as 413 follows: 415 CPC Compressed Message Format 416 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 417 | 0 0 0 0 Sequence Number | 418 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 419 | Data | 420 : . : 421 : . : 422 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 424 CPC Non-Compressed Message Format 425 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 426 | 0 0 0 1 Sequence Number | 427 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 428 | Data | 429 : . : 430 : . : 431 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 432 CPC Compressed TPPC Message Format 433 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 434 | 0 0 1 0 Sequence Number | 435 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 436 | Data | 437 : . : 438 : . : 439 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 441 CPC Non-Compressed TPPC Message Format 442 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 443 | 0 0 1 1 Sequence Number | 444 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 445 | Data | 446 : . : 447 : . : 448 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 450 PPC Compressed Message Format 451 +---+---+---+---+---+---+---+---+ 452 | 1 1 1 1 0 0 0 0 | 453 +---+---+---+---+---+---+---+---+ 454 | Data | 455 : . : 456 : . : 457 +---+---+---+---+---+---+---+---+ 458 PPC Non-Compressed Message Format 459 +---+---+---+---+---+---+---+---+ 460 | 1 1 1 1 0 0 0 1 | 461 +---+---+---+---+---+---+---+---+ 462 | Data | 463 : . : 464 : . : 465 +---+---+---+---+---+---+---+---+ 467 PPC Compressed TPPC Message Format 468 +---+---+---+---+---+---+---+---+ 469 | 1 1 1 1 0 0 1 0 | 470 +---+---+---+---+---+---+---+---+ 471 | Data | 472 : . : 473 : . : 474 +---+---+---+---+---+---+---+---+ 476 PPC Non-Compressed TPPC Message Format 477 +---+---+---+---+---+---+---+---+ 478 | 1 1 1 1 0 0 1 1 | 479 +---+---+---+---+---+---+---+---+ 480 | Data | 481 : . : 482 : . : 483 +---+---+---+---+---+---+---+---+ 485 Each CPC outbound data packet is submitted to the compressor and 486 a sequence number is assigned to it. The sequence number is 487 initialized to zero and wraps at the maximum value. It is 488 incremented by one for each packet packet transmitted on the WCP 489 connection. When a packet is compressed successfully (i.e. 490 compression does not expand the packet) it is sent out as a CPC 491 compressed packet. 493 The receiver examines each CPC packet for proper sequencing. 494 Correctly sequenced packets are decompressed. If an out of 495 sequence packet is received, a retransmit request is sent for 496 each missing packet and the decompressor enters the retransmit 497 phase. If retransmission is not possible, a reset request may be 498 sent instead. 500 The corresponding compressor at the end of the WCP connection 501 which enters the retransmit or reset phase should signal the 502 remote compressor to temporarily enter packet by packet mode by 503 setting the TPPC flags in transmitted data packets. This signal 504 should persist until the data phase is re-entered. 506 4.4. Retransmit Phase 508 There are 4 message types defined for carrying retransmitted 509 compressed data. These messages are formed by the combination of 510 the following two attributes: 512 o Compressed/Non-Compressed -- this field indicates if the 513 packet is in a compressed or non-compressed form. 515 o Aged -- this field indicates if the packet is an aged packet 516 and as such is only transmitted to maintain synchronization of 517 the compression dictionary. 519 The format of the messages sent during the retransmission phase 520 are as follows: 522 Retransmit Compressed Message Format 523 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 524 | 0 1 0 0 Sequence Number | 525 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 526 | Data | 527 : . : 528 : . : 529 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 530 Retransmit Non-Compressed Message Format 531 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 532 | 0 1 0 1 Sequence Number | 533 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 534 | Data | 535 : . : 536 : . : 537 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 539 Retransmit Compressed Aged Message Format 540 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 541 | 0 1 1 0 Sequence Number | 542 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 543 | Data | 544 : . : 545 : . : 546 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 548 Retransmit Non-Compressed Aged Message Format 549 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 550 | 0 1 1 1 Sequence Number | 551 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 552 | Data | 553 : . : 554 : . : 555 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 557 Retransmit Request Message Format 558 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 559 | 1 0 0 0 Sequence Number | 560 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 561 Retransmit NAK Message Format 562 +---+---+---+---+---+---+---+---+ 563 | 1 1 1 1 1 1 0 1 | 564 +---+---+---+---+---+---+---+---+ 566 When an out of sequence packet is received, the decompressor 567 should send a retransmit request message for each packet missing 568 between the expected sequence number and the out of sequence 569 packet received. The receiver should send a reset request 570 instead, if the out of sequence packet is greater than K from the 571 expected value. A recommended value for K is 127. 573 The decompressor, upon entering the retransmit state, must hold 574 all incoming packets and expects the correct sequence of 575 retransmitted packets. If an out of sequence retransmitted 576 packet is received, or the desired sequence number is not 577 received in a period of T3, an implementation may choose to 578 retry, or enter the reset phase. If the number of retries 579 exceeds N3, the decompressor must enter the reset phase. The 580 recommended value for T3 is 2 seconds. The recommended value for 581 N3 is 2. 583 When a retransmit request is received, the transmission history 584 is searched for the requested packet. If the desired packet is 585 found, the packet is retransmitted. If the desired packet is not 586 found in the transmission history, a retransmit NAK message is 587 returned. 589 When the last packets of a packet stream are lost and the 590 compressor subsequently remains idle, the decompressor will not 591 be able to detect that packets are missing. When the 592 decompressor eventually is able to detect the packet loss, the 593 retransmit request might result in the transmission of stale 594 packets. To avoid this problem, an aging mechanism is defined. 596 When a packet is saved in the transmission history, the packet 597 should be time stamped. When a packet is retrieved from the 598 transmission history for the purpose of retransmission, the time 599 stamp should be checked. If the time stamp is older than a 600 period of T4, the packet should be sent as being aged. The 601 decompressor processes aged packets similarly to normal 602 retransmitted packets to allow the dictionary to remain 603 synchronized. However the packet should be dropped after it has 604 been decompressed. A recommended value for T4 is 7 seconds. 606 4.5. Reset Phase 608 Only the decompressor may send a reset request and enter the 609 reset phase. The decompressor may send a reset request when it 610 is unable to synchronize with the compressor, such as when N3 is 611 exceeded, or when a retransmit NAK is received. While waiting 612 for the reset acknowledge message, the decompressor discards all 613 CPC mode packets. If a reset acknowledge does not arrive in 614 period T2, a new reset request should be transmitted. If the 615 maximum retry count N2 is reached, the disconnect phase is 616 entered. 618 The format of messages sent during the reset phase are as 619 follows: 621 Reset Request Message Format 622 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 623 | 1 1 1 1 1 0 1 1| TID octet 1 | 624 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 625 | TID octet 2 | 626 +--+--+--+--+--+--+--+--+ 628 Reset Acknowledge Message Format 629 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 630 | 1 1 1 1 1 1 0 0| TID octet 1 | 631 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 632 | TID octet 2 | 633 +--+--+--+--+--+--+--+--+ 635 4.6. Disconnect Phase 637 The disconnect request and disconnect acknowledge are used to 638 disconnect a WCP connection. The sender of a disconnect request 639 should use the same retry mechanism described for the connection 640 phase. In addition, the sender of a disconnect request message 641 may attempt to restart the PPP connection if it is not successful 642 in receiving a disconnect acknowledge within the retry period. 644 The format of the disconnect request and disconnect acknowledge 645 messages are as follows: 647 Disconnect Request Message Format 648 +---+---+---+---+---+---+---+---+ 649 | 1 1 1 1 0 1 1 1 | 650 +---+---+---+---+---+---+---+---+ 652 Disconnect Acknowledge Message Format 653 +---+---+---+---+---+---+---+---+ 654 | 1 1 1 1 1 0 0 0 | 655 +---+---+---+---+---+---+---+---+ 657 5. WCP Frame Relay Encapsulation 659 It is intended that all of the concepts discussed earlier in this 660 document apply when WCP is run over other link types. When WCP 661 is utilized over frame relay links, the compression NLPID of 662 X'B0' is used to identify WCP. The format shall be as follows: 664 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 665 | flag 0x'7E' | Q.922 address* | 666 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 667 | Q.922 address | Control X'03' | 668 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 669 | Optional Pad X'00' | NLPID X'B0' | 670 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 671 | WCP Header | 672 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 673 | Data | 674 : : 675 : : 676 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 677 | FCS | 678 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 680 * Q.922 addresses, as presently defined, are two octets and 681 contain a 10-bit DLCI. In some networks Q.922 addresses may 682 optionally be increased to three or four octets. 684 6. Security Considerations 686 Security issues are not discussed in this memo. 688 7. References 690 [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", 691 RFC1548, December 1993. 693 [2] Rand, D., "The PPP Compression Control Protocol(CCP)", work 694 in progress, draft-ieft-pppext-compression-03.txt. 696 8. Appendix 698 8.1. WCP Recommended Values 700 Parameter Recommended Value Description 701 --------- ----------------- ----------- 702 T1 10 minutes Connect retry period 704 T2 2 seconds Init, Reset timer 706 N2 10 Init, Reset retry counter 708 T3 2 seconds Retransmit timer 710 N3 2 Retransmit retry counter 712 T4 7 seconds Stale packet timer 714 K 127 Sequence range value 716 8.2. Initialization Phase Messages For Other Algorithms 718 *** Add other algorithms here... *** 720 Chair's Address 722 The working group can be contacted via the current chair: 724 Fred Baker 725 Cisco Systems 726 519 Lado Drive 727 Santa Barbara, California 93111 729 EMail: fred@cisco.com 731 Author's Address 733 Questions about this memo can also be directed to: 735 Wing Lam 736 Bay Networks, Inc. 737 2 Federal Street 738 Billerica, Massachusetts 01821 740 Email: wlam@baynetworks.com 742 Keith Mader 743 Bay Networks, Inc. 744 2 Federal Street 745 Billerica, Massachusetts 01821 747 Email: kmader@baynetworks.com