Network Working Group Wing Lam Internet Draft Keith Mader Bay Networks November 1995 PPP WAN Compression Protocol draft-ietf-pppext-wcp-00.txt Status of this Memo This document is a submission to the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet Draft, please check the ``1id-abstracts.txt'' listing contained in the internet- drafts Shadow Directories on on nic.ddn.mil, ds.internic.net, venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current status of any Internet Draft. Lam, Mader Expires in Six Months [Page i] Internet Draft WAN Compression Protocol November 1995 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 for negotiating data compression over PPP links. This document describes the use of the WAN Compression Protocol (WCP) to provide an algorithm independent transport for compressed datagrams over point-to-point links. Lam, Mader Expires in Six Months [Page ii] Internet Draft WAN Compression Protocol November 1995 1. Conventions The following language conventions are used in the items of specification in this document: o Must, Shall or Mandatory -- the item is an absolute requirement of the specification. o Should or Recommended -- the item should generally be followed for all but exceptional circumstances. o May or Optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor. All drawings in this document are drawn with the left-most bit as the high order bit for transmission. For example: 0 1 2 3 4 5 6 7 bits +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | flag (7E hexadecimal) | +---+---+---+---+---+---+---+---+ | address 0x'FF' | +---+---+---+---+---+---+---+---+ : : : : +---+---+---+---+---+---+---+---+ Drawings that would be too large to fit into one page if each octet were presented on a single line are drawn with two octets per line. These are also drawn with the left-most bit as the high order bit for transmission. There will be a "|" to distinguish between octets as shown in the following example. Lam, Mader Expires in Six Months [Page 1] Internet Draft WAN Compression Protocol November 1995 |--- octet one ---|--- octet two ---| 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | flag 0x'7E' | address 0x'FF' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ : : : : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2. Introduction This document describes the WAN Compression Protocol (WCP), which is a transport protocol designed specifically for carrying compressed packets across WAN links. The primary features of WCP include the negotiation of compression algorithms and parameters, the transport of compressed packets, and the detection and retransmission of lost or corrupted packets. The negotiation feature of WCP allows various compression algorithms to be used. It also allows for the various algorithm specific compression parameters (such as dictionary size, compression mode) to be negotiated. The transport mechanism of WCP provides the means for transporting compressed packets, as well as non compressed packets. Compressed packets are sent when the compressed version of a packet is smaller than the original non compressed packet. However, when the compressed version of a packet is larger than the original non compressed packet, WCP transports the original packet instead. The transport mechanism also provides unique identification of packets compressed using continuous or per packet compression methods. WCP is a sequenced, non-windowed protocol that does not rely on positive acknowledgments. In transporting packets across the network, WCP employs a 12-bit sequence number to detect packet loss. Upon detection of packet loss, WCP selectively requests the retransmission of the lost packets thus avoiding a reset of the compression dictionary. Lam, Mader Expires in Six Months [Page 2] Internet Draft WAN Compression Protocol November 1995 3. WCP Frame Format Before any WCP packets may be communicated, PPP must reach the Network-Layer Protocol phase [1], and the Compression Control Protocol must reach the Opened state. When WCP is negotiated as the compression algorithm, the PPP protocol field indicates type 0x'00FD' (compressed datagram). Exactly one WCP datagram is encapsulated in the PPP Information field. The compressed form of the original PPP datagram starting with the PPP Protocol field is carried in the data portion of the WCP frame. The format shall be as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | address 0x'FF' | control 0x'03' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PPP Protocol 0x'00FD' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WCP header | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | FCS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4. WCP Procedures All WCP procedures involve a WCP connection. A WCP connection is the association of two ends of a point-to-point link. A WCP connection consists of two rather independent sub-connections. Each of these sub-connections define the association of the compressor on one side of the connection and the decompressor on the other side of the connection. These sub-connections are independent in that operations on one of the sub-connections, for example the compression algorithm used, does not imply the same for the other. With the various procedures of WCP, the decompressor side of a sub-connection behaves as the master by initiating requests to the compressor, while the compressor side Lam, Mader Expires in Six Months [Page 3] Internet Draft WAN Compression Protocol November 1995 of a sub-connection behaves as the slave by responding to requests made by the decompressor. During the process of transporting compressed data over a connection, WCP transitions through several distinct phases. Each of these phases, and the conditions and WCP packets associated with each phase are described in the following sections. 4.1. Connection Phase WCP begins its operation in the connection phase. This phase is initiated with a connect request message being sent on the PPP link. The format of this message and appropriate responses are as follows: Connect Request Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 0 1 0 0| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | WCP Revision | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Initiator | Sequence Size | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Algorithm Count | Algorithm 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ : | : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Algorithm n | +--+--+--+--+--+--+--+--+ Lam, Mader Expires in Six Months [Page 4] Internet Draft WAN Compression Protocol November 1995 Connect Acknowledge Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 0 1 0 1| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | WCP Revision | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Sequence Size | Algorithm | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ReXmit Enable | +--+--+--+--+--+--+--+--+ Connect NAK Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 1 1 0 | +---+---+---+---+---+---+---+---+ Connect Request messages, as well as other WCP control messages, use a 16 bit transaction identifier (TID). Each side of the WCP connection should initialize the TID to zero and increment its value by one for each subsequent control message request. There are 5 fields defined in a connect request message. These fields are as follows: o Revision -- this field specifies the supported revision of the WCP protocol being used. The current value is 2. Future revisions to WCP shall append any changes to the end of the existing message format and increment the revision number by one. If the receiver of a connect message supports a version lower than the specified revision, it should process the message using its current lower version. The sender of a connect acknowledge should respond with the version that is currently being supported. The receiver of a connect request message may send a connect nak message if it can not support the requested version. o Initiator -- this field specifies whether the sender of the connect request has initiated the request on its own or as a result of a connect request from the other half of the WCP Lam, Mader Expires in Six Months [Page 5] Internet Draft WAN Compression Protocol November 1995 connection. When the compressor of one side receives a connect request message with this field set, the decompressor must also enter the connection phase and generate a connect request with the initiator field clear. This is useful when configuration has changed on one side of the WCP connection that may effect the negotiated values on the other side of the WCP connection. Support of this field is optional. Implementations not supporting the initiator field must set the field to zero. o Sequence Size -- this field specifies the size of the sequence number used in WCP data packets. The current value of 1, indicating a 12 bit sequence number, must be supported. If the receiver of a connect request message supports a value lower than indicated in the request, the receiver should reply with a connect acknowledge message indicating the supported value. The receiver may send a connect nak if it can not support the requested sequence size. o Number of Algorithms -- this field specifies the number of algorithms contained in the connect request message. o Algorithms -- these fields specify the various compression algorithms supported in order of preference, by the sender of the connect request message. The receiver of this message should choose among these algorithms and indicate it preference in the connect acknowledgment. The receiver of the connect request must reply with a connect nak if it can not support any of the requested algorithms. The values of the various algorithms is listed in the appendix. There are 4 fields defined in a connect acknowledge message. These fields are as follows: o Revision -- this field specifies the supported revision of the WCP protocol being used. o Sequence Size -- this field specifies the supported sequence size being used. o Algorithm -- this field specifies the negotiated compression algorithm being used. Lam, Mader Expires in Six Months [Page 6] Internet Draft WAN Compression Protocol November 1995 o ReXmit Enable -- this field specifies whether the sender of this message maintains a transmission history. The receiver of a connect acknowledge message with this field set should request retransmission of lost or corrupted packets. The receiver of a connect acknowledge message with this field set to zero must not generate retransmit request messages. The sender of the connect request message should retry if neither a connect acknowledge or a connect nak is received. It should stop retrying after a period of time T1. A recommended retry interval is n seconds for the nth retry, where n is less than 30, and then 30 thereafter. A recommended value for T1 is 10 minutes. The receiver of a connect acknowledgment may choose to initiate a disconnect sequence if any of the values specified are not acceptable. It must also ignore any connect acknowledgment received with a TID that does not match the expected TID. 4.2. Initialization Phase The decompressor, upon entering the initialization phase, sends an initialization request message to the compressor on the other end of the WCP connection. The compressor should respond with an initialization acknowledgment message containing the acceptable parameters. When an initialization ack message is not received in time T2, a new initialization request must be sent. If the maximum retry count N2 is reached, the decompressor enters the disconnect phase. The recommended value to T2 is 2 seconds, and the recommended value for N2 is 10. The exact format of the initialization request and acknowledgment messages are algorithm specific, but must follow the general structure. Specifically, each initialization request message must minimally contain a TID. Each initialization acknowledgment message must minimally contain a TID. The format of initialization request and acknowledge messages for various compression algorithms are described in the appendix. The format of the initialization request and initialization acknowledgment for the MagnaLink compression algorithm are as Lam, Mader Expires in Six Months [Page 7] Internet Draft WAN Compression Protocol November 1995 follows: Init Request Message Format (MagnaLink example) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 1 0 0 1| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | Algorithm Revision | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Initiator | Dictionary Size | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PPC Enable | PIB Enable | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Init Acknowledge Message Format (MagnaLink Example) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 1 0 1 0| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | Algorithm Revision | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Dictionary Size | PPC Enable | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PIB Enable | +--+--+--+--+--+--+--+--+ The fields of the MagnaLink initialization request message are as follows: o Algorithm Revision -- this field specifies the version of the compression algorithm being supported. The current value of this field is one. o Dictionary Size -- this field specifies the size of the compression/decompression dictionary. A one in this field indicates the use of an 8K dictionary, and a two in this field specifies a 32K dictionary. All other values are reserved. An 8K dictionary must be supported. The receiver of the initialization request may set the dictionary size field in Lam, Mader Expires in Six Months [Page 8] Internet Draft WAN Compression Protocol November 1995 the initialization acknowledgment message to one if a 32K dictionary is not supported. o PPC Enable -- this field specifies if the sender of the initialization request message wishes to perform packet by packet compression for this WCP connection. A one in this field indicates packet by packet compression mode. This mode must be supported. A zero in this field identifies continuous compression mode. The receiver of the initialization request must set this field in the initialization ack message if this field is set in the request message. o PIB Enable -- this field specifies if the sender of the initialization request wishes to perform protocol integrity byte checking. A zero in this field indicates that no PIB checking should be performed. This mode must be supported. A one in this field indicates that PIB checking should be performed. The receiver of the initialization request must set this field in the initialization ack message to zero if this field is clear in the request message. The initialization phase may be re-entered if either side of the WCP connection wishes to re-negotiate any of all of the initialization values. For example, if the decompressor on one side of the WCP connection is running in CPC mode and detects a high level of packet loss over time, it may choose to enter PPC mode by re-entering the initialization phase. 4.3. Data Transfer Phase The data transfer phase is entered when the initialization phase has completed. There are eight messages defined for carrying compressed data. These messages are formed by the combination of the following three attributes: o CPC/PPC -- indicates if the compressed data was generated using continuous packet compression (CPC) or packet by packet compression (PPC). The CPC mode compression maintains dictionary information across packet boundaries whereas the Lam, Mader Expires in Six Months [Page 9] Internet Draft WAN Compression Protocol November 1995 PPC mode re-initializes the dictionary for each new packet. o Compressed/Non-Compressed -- indicates if the packet contains compressed or original data. If the packet is non-compressed and CPC mode is indicated, the decompressor must update the dictionary to include the non-compressed data in order to maintain dictionary synchronization. o TPPC -- indicates a request to enter transient packet by packet compression (TPPC) mode. This signals to the receiver, that subsequent packets should be compressed using PPC mode. Support for TPPC is optional however implementations not supporting TPPC must be able to receive and process packets indicated as TPPC. The format of packets sent during the data transfer phase are as follows: CPC Compressed Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 0 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ CPC Non-Compressed Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 0 1 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Lam, Mader Expires in Six Months [Page 10] Internet Draft WAN Compression Protocol November 1995 CPC Compressed TPPC Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 1 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ CPC Non-Compressed TPPC Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 1 1 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ PPC Compressed Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 0 0 0 | +---+---+---+---+---+---+---+---+ | Data | : . : : . : +---+---+---+---+---+---+---+---+ Lam, Mader Expires in Six Months [Page 11] Internet Draft WAN Compression Protocol November 1995 PPC Non-Compressed Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 0 0 1 | +---+---+---+---+---+---+---+---+ | Data | : . : : . : +---+---+---+---+---+---+---+---+ PPC Compressed TPPC Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 0 1 0 | +---+---+---+---+---+---+---+---+ | Data | : . : : . : +---+---+---+---+---+---+---+---+ PPC Non-Compressed TPPC Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 0 1 1 | +---+---+---+---+---+---+---+---+ | Data | : . : : . : +---+---+---+---+---+---+---+---+ Each CPC outbound data packet is submitted to the compressor and a sequence number is assigned to it. The sequence number is initialized to zero and wraps at the maximum value. It is incremented by one for each packet packet transmitted on the WCP connection. When a packet is compressed successfully (i.e. compression does not expand the packet) it is sent out as a CPC compressed packet. The receiver examines each CPC packet for proper sequencing. Correctly sequenced packets are decompressed. If an out of Lam, Mader Expires in Six Months [Page 12] Internet Draft WAN Compression Protocol November 1995 sequence packet is received, a retransmit request is sent for each missing packet and the decompressor enters the retransmit phase. If retransmission is not possible, a reset request may be sent instead. The corresponding compressor at the end of the WCP connection which enters the retransmit or reset phase should signal the remote compressor to temporarily enter packet by packet mode by setting the TPPC flags in transmitted data packets. This signal should persist until the data phase is re-entered. 4.4. Retransmit Phase There are 4 message types defined for carrying retransmitted compressed data. These messages are formed by the combination of the following two attributes: o Compressed/Non-Compressed -- this field indicates if the packet is in a compressed or non-compressed form. o Aged -- this field indicates if the packet is an aged packet and as such is only transmitted to maintain synchronization of the compression dictionary. The format of the messages sent during the retransmission phase are as follows: Retransmit Compressed Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 1 0 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Lam, Mader Expires in Six Months [Page 13] Internet Draft WAN Compression Protocol November 1995 Retransmit Non-Compressed Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 1 0 1 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Retransmit Compressed Aged Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 1 1 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Retransmit Non-Compressed Aged Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 1 1 1 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Retransmit Request Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 0 0 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Lam, Mader Expires in Six Months [Page 14] Internet Draft WAN Compression Protocol November 1995 Retransmit NAK Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 1 | +---+---+---+---+---+---+---+---+ When an out of sequence packet is received, the decompressor should send a retransmit request message for each packet missing between the expected sequence number and the out of sequence packet received. The receiver should send a reset request instead, if the out of sequence packet is greater than K from the expected value. A recommended value for K is 127. The decompressor, upon entering the retransmit state, must hold all incoming packets and expects the correct sequence of retransmitted packets. If an out of sequence retransmitted packet is received, or the desired sequence number is not received in a period of T3, an implementation may choose to retry, or enter the reset phase. If the number of retries exceeds N3, the decompressor must enter the reset phase. The recommended value for T3 is 2 seconds. The recommended value for N3 is 2. When a retransmit request is received, the transmission history is searched for the requested packet. If the desired packet is found, the packet is retransmitted. If the desired packet is not found in the transmission history, a retransmit NAK message is returned. When the last packets of a packet stream are lost and the compressor subsequently remains idle, the decompressor will not be able to detect that packets are missing. When the decompressor eventually is able to detect the packet loss, the retransmit request might result in the transmission of stale packets. To avoid this problem, an aging mechanism is defined. When a packet is saved in the transmission history, the packet should be time stamped. When a packet is retrieved from the transmission history for the purpose of retransmission, the time stamp should be checked. If the time stamp is older than a period of T4, the packet should be sent as being aged. The decompressor processes aged packets similarly to normal retransmitted packets to allow the dictionary to remain synchronized. However the packet should be dropped after it has been decompressed. A recommended value for T4 is 7 seconds. Lam, Mader Expires in Six Months [Page 15] Internet Draft WAN Compression Protocol November 1995 4.5. Reset Phase Only the decompressor may send a reset request and enter the reset phase. The decompressor may send a reset request when it is unable to synchronize with the compressor, such as when N3 is exceeded, or when a retransmit NAK is received. While waiting for the reset acknowledge message, the decompressor discards all CPC mode packets. If a reset acknowledge does not arrive in period T2, a new reset request should be transmitted. If the maximum retry count N2 is reached, the disconnect phase is entered. The format of messages sent during the reset phase are as follows: Reset Request Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 1 0 1 1| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | +--+--+--+--+--+--+--+--+ Reset Acknowledge Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 1 1 0 0| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | +--+--+--+--+--+--+--+--+ 4.6. Disconnect Phase The disconnect request and disconnect acknowledge are used to disconnect a WCP connection. The sender of a disconnect request should use the same retry mechanism described for the connection phase. In addition, the sender of a disconnect request message may attempt to restart the PPP connection if it is not successful in receiving a disconnect acknowledge within the retry period. Lam, Mader Expires in Six Months [Page 16] Internet Draft WAN Compression Protocol November 1995 The format of the disconnect request and disconnect acknowledge messages are as follows: Disconnect Request Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 1 1 1 | +---+---+---+---+---+---+---+---+ Disconnect Acknowledge Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 0 0 | +---+---+---+---+---+---+---+---+ 5. WCP Frame Relay Encapsulation It is intended that all of the concepts discussed earlier in this document apply when WCP is run over other link types. When WCP is utilized over frame relay links, the compression NLPID of Lam, Mader Expires in Six Months [Page 17] Internet Draft WAN Compression Protocol November 1995 X'B0' is used to identify WCP. The format shall be as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | flag 0x'7E' | Q.922 address* | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Q.922 address | Control X'03' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Optional Pad X'00' | NLPID X'B0' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WCP Header | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : : : : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | FCS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ * Q.922 addresses, as presently defined, are two octets and contain a 10-bit DLCI. In some networks Q.922 addresses may optionally be increased to three or four octets. 6. Security Considerations Security issues are not discussed in this memo. 7. References [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC1548, December 1993. [2] Rand, D., "The PPP Compression Control Protocol(CCP)", work in progress, draft-ieft-pppext-compression-03.txt. Lam, Mader Expires in Six Months [Page 18] Internet Draft WAN Compression Protocol November 1995 8. Appendix 8.1. WCP Recommended Values Parameter Recommended Value Description --------- ----------------- ----------- T1 10 minutes Connect retry period T2 2 seconds Init, Reset timer N2 10 Init, Reset retry counter T3 2 seconds Retransmit timer N3 2 Retransmit retry counter T4 7 seconds Stale packet timer K 127 Sequence range value 8.2. Initialization Phase Messages For Other Algorithms *** Add other algorithms here... *** Lam, Mader Expires in Six Months [Page 19] Internet Draft WAN Compression Protocol November 1995 Chair's Address The working group can be contacted via the current chair: Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 EMail: fred@cisco.com Author's Address Questions about this memo can also be directed to: Wing Lam Bay Networks, Inc. 2 Federal Street Billerica, Massachusetts 01821 Email: wlam@baynetworks.com Keith Mader Bay Networks, Inc. 2 Federal Street Billerica, Massachusetts 01821 Email: kmader@baynetworks.com Lam, Mader Expires in Six Months [Page 20]