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]
