As per Relevance of the word compression, we have this rfc below:
Network Working Group K.
Request for Comments: 1976 S.
Category: Informational ADTRAN, Inc
August 1996
PPP for Data Compression in Data Circuit-Terminating Equipment (DCE
Status of This
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links.
defines an extensible Link Control Protocol, and proposes a family
Network Control Protocols for establishing and configuring
network-layer protocols
The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides
standard method for encapsulating and transporting serial data over
PPP link. The PPP Compression Control Protocol [3] provides
standard method for selecting and using a compression protocol
provide for data compression on a PPP link
This document defines a specific set of parameters for
protocols and an LCP extension to define a standard way of using
for data compression of serial data in Data Circuit-
Equipment (DCE).
Table of
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 3
2. Modes of Operation .................................... 3
3. PPP Link Control Protocol Extension ................... 4
4. Required PPP Elements ................................. 4
4.1 Required Configuration Options and Parameters ... 5
5. Mode-1 Requirements ................................... 6
5.1 Detailed Mode-1 Example ......................... 7
6. Initial Handshake Operation ........................... 8
7. Security .............................................. 9
8. References ............................................ 9
CHAIR'S ADDRESS .............................................. 9
Schneider & Venters Informational [Page 1]
RFC 1976 PPP DCE August 1996
AUTHORS' ADDRESSES ........................................... 10
1.
This document is a product of the TR30.1 ad hoc committee
compression of synchronous data. It represents a component of
proposal to use PPP to provide compression of synchronous serial
in DSU/CSUs
PPP [1] has three main components
1. A method for encapsulating multi-protocol datagrams
2. A Link Control Protocol (LCP) for establishing, configuring
and testing the data-link connection
3. A family of Network Control Protocols for establishing
configuring different network-layer protocols
In addition to providing support for multi-protocol datagrams,
Point-to-Point Protocol (PPP) [1] has defined an effective and
negotiating mechanism that can be used on point to point links.
used in conjunction with the PPP Compression Control Protocol [3]
one of the PPP Compression Protocols [4], PPP provides
interoperable method of employing data compression on a point-to
point link
The PPP Serial Data Transport Protocol (PPP-SDTP) and the PPP
Data Control Protocol (PPP-SDCP) [2] have been developed to
serial data to be carried within a PPP packet. PPP-SDTP uses
terminal adaption header based on that of ITU-T Recommendation V.120
[5].
1.1. Specification of
In this document, several words are used to signify the
of the specification. These words are often capitalized
MUST This word, or the adjective "required", means that
definition is an absolute requirement of the specification
MUST NOT This phrase means that the definition is an
prohibition of the specification
SHOULD This word, or the adjective "recommended", means that
may exist valid reasons in particular circumstances
ignore this item, but the full implications must
understood and carefully weighed before choosing
Schneider & Venters Informational [Page 2]
RFC 1976 PPP DCE August 1996
different course
MAY This word, or the adjective "optional", means that
item is one of an allowed set of alternatives.
implementation which does not include this option MUST
prepared to interoperate with another implementation
does include the option
1.2.
This document frequently uses the following terms
datagram The unit of transmission in the network layer (such as IP).
A datagram may be encapsulated in one or more
passed to the data link layer
frame The unit of transmission at the data link layer. A
may include a header and/or a trailer, along with
number of units of data
packet The basic unit of encapsulation, which is passed across
interface between the network layer and the data
layer. A packet is usually mapped to a frame;
exceptions are when data link layer fragmentation is
performed, or when multiple packets are incorporated into
single frame
peer The other end of the point-to-point link
silently
This means the implementation discards the packet
further processing. The implementation SHOULD provide
capability of logging the error, including the contents
the silently discarded packet, and SHOULD record the
in a statistics counter
2. Modes of
This document provides for three modes of operation for DCE devices
Mode-0 represents transparent operation; Mode-1 a simplified
predefined compression format; and Mode-2, a full PPP
providing compression of serial data
Mode-0 represents the operating mode of currently deployed DCEs
operate in transparent mode, without any DCE-to-DCE protocols
Mode-1 devices implement data compression upon detecting an
handshake, which is implemented via an newly defined
Configuration Option called the DCE-Identifier. The DCE-
Schneider & Venters Informational [Page 3]
RFC 1976 PPP DCE August 1996
is used both to distinguish DCE devices from PPP bridges and routers
and to all Mode-1 and Mode-2 DCE devices to interoperate, via
Mode parameter. In Mode-1, the parameters of operation are
negotiable. Mode-2 devices implement the full LCP state machine
are therefore capable of negotiating alternatives to the default
of paramaters and options. Mode-2 devices must also support Mode-1
operation, and fall-back to such operation when connected to a Mode-1
device. The mechanism of the Mode-1/Mode-2 handshake is given
Section 7.
3. PPP Link Control Protocol
The use of PPP in Compression DCE requires the use of an
LCP Configuration Option
25 DCE-
DCE-
The presence of this option indicates that the system sending
is Data Circuit-Terminating Equipment (DCE) that desires
establish a serial data compression link
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
25
3
1 Mode-1 (No Additional Negotiation
2 Mode-2 (Full PPP Negotiation and State Machine
4. Required PPP
Unlike PPP's native bridge/router environment, the
requirement for use of PPP in DCE equipment is not
interoperability, but rather interoperability with effective
Schneider & Venters Informational [Page 4]
RFC 1976 PPP DCE August 1996
compression. With this in mind, it is desirable to specify a
PPP feature set, that is somewhat different than that of a normal
bridge/router requirement
This different feature set includes: support for compression,
of a single default compression algorithm, support of Protocol-
compression, support of Address-and-Control-Field-Compression
support of PPP-SDTP, etc
The minimum feature set includes the following protocols
PPP Link Control Protocol (Mode-1 must include a subset) [1]
PPP in HDLC-like Framing [6]
PPP Compression Control Protocol (Mode-2 only) [3]
PPP LZS-DCP Compression Protocol [4]
PPP Serial Data Transport Protocol [2]
PPP Serial Data Control Protocol (Mode-2 only) [2]
The Stacker-LZS algorithm from Stac Electronics was chosen as
default compression algorithm for DCE devices. This decision
made by the TR30.1 ad hoc based on licensing issues (agreeing
non-discriminatory and reasonable terms), compression ratios,
efficient use of processor and memory resources, and
scalability. A compression protocol incorporating in-
synchronization signaling was defined for the Stacker algorithm
selected for the default compression protocol. This protocol
known as the PPP LZS-DCP Compression Protocol [4]. Although the
LZS-DCP Compression Protocol specifies a number of formats
history management options, only the default format with a
history must be implemented
4.1. Required Configuration Options and
To ensure that implementations are able to interoperate
effective data compression, a required set of Configuration
are specified. These Options are assumed in Mode-1, and
negotiated in Mode-2, using the standard PPP negotiation
machine. (Mode-1 uses a fixed packet format with a predetermined
of values for LCP, LZS-DCP, and SDTP
Options/parameters. The required values listed in this section
the predefined values.)
The following LCP Configuration Options [7] MUST be supported
Maximum-Receive-Unit 1550
Address/Control-Field-Compression
Protocol-Field-Compression
Schneider & Venters Informational [Page 5]
RFC 1976 PPP DCE August 1996
The following CCP Configuration Option MUST be supported
Compression-Type 23 (LZS-DCP
The following default LZS-DCP Configuration Options MUST
supported
Check-Mode 3 (sequence + LCB
History-Count 1 (single history
Process-Mode 0 (None
The default SDTP/SDCP Configuration Options MUST be supported.
are
Packet-Format: Header-
Header-Type: H-
Multiple-Packets:
Multi-Port:
Transport-Mode: HDLC-
Maximum-Frame-Size: 10,000
Allow-Odd-Frames:
FCS-Type: Transparent-
Flow-Expiration-Time: 100
5. Mode-1
DSUs that use only Mode-1 (non-negotiate mode) use only
predetermined set of PPP packets. In addition to a fixed data
format, two fixed formats are used to differentiate between Mode-1
devices and Mode-0 (transparent) devices. Mode-1 devices
designed to operate using compression if a peer has the
capability, or revert to transparent operation (Mode-0) if the
does not support standard compression
Mode-1 devices use LZS-DCP Compression Packets as specified in [4].
These packets include the capabilities of DCP: Reset-Request
Acknowledge, Compressed/Transparent, etc. Since the packets
signalling, these packets can be sent with an empty data field
signal a reset request if no data packets are ready for piggy-
signalling
Exactly one LZS-DCP packet is encapsulated in the PPP
field, where the PPP Protocol field indicates type 00FD (
Protocol). Exactly one SDTP packet is transported by each LZS-
data packet
Schneider & Venters Informational [Page 6]
RFC 1976 PPP DCE August 1996
Operation in Mode-1 implies a set of predetermined values for LCP
LZS-DCP, and SDTP configuration options and parameters, using
values listed in the preceding section
The following PPP packets are permitted and recognized
LCP Configure-Request with DCE Mode-1 Configuration
LCP Configure-Ack with DCE Mode-1 Configuration
LZS-DCP Packet with the data field containing an SDTP
LZS-DCP Packet with an empty data
Protocol-Field-Compression and Address-and-Control-Field-
is used on all packets except the handshake packets (LCP packets).
Any Mode-1 or Mode-2 DCE that receives a Mode-1 request
Acknowledge the request
5.1. Detailed Mode-1
Detailed Example when using Mode-1 on a point-to-point leased
circuit switched link (using PPP in HDLC-like Framing [6]) (
shown is after flags and inserted 0s are removed; lower case
and numbers represent actual values, uppercase represent data
whose values may vary from packet to packet; parentheses
a field indicate that the field may not be present in all packets
that type):
LCP Configure-Request
Config. Opt
Addr. Ctl. PID Code ID Length Type Lngth
+----+----+-------+----+----+-------+----+----+----+-----+
| ff | 03 | c0 21 | 01 | 00 | 00 07 | 21 | 03 | 01 | FCS |
+----+----+-------+----+----+-------+----+----+----+-----+
LCP Configure-Ack
Config. Opt
Addr. Ctl. PID Code ID Length Type Lngth
+----+----+-------+----+----+-------+----+----+----+-----+
| ff | 03 | c0 21 | 02 | 00 | 00 07 | 21 | 03 | 01 | FCS |
+----+----+-------+----+----+-------+----+----+----+-----+
LZS-DCP Packet
PID
+----+----+------+------ -+-------+-----+
| fd | HD | (SQ) | (DATA) | (LCB) | FCS |
+----+----+------+--------+-------+-----+
Schneider & Venters Informational [Page 7]
RFC 1976 PPP DCE August 1996
The DATA field contains a compressed or uncompressed SDTP-PDU
The LCB field is only present on a packet containing
data. The Sequence Number and Data fields are only present
packets that contain data
+----+------+----+
SDTP-PDU: | 49 | DATA | HD |
+----+------+----+
6. Initial Handshake
When a unit is powered up, or when the lower layer signals that
peer has gone out of service and returned, the handshake procedure
initiated. The handshake procedure for Mode-1 and Mode-2 devices
described below
Mode-1:
When starting Mode-1, each DCE sends out an LCP Configure-
packet containing only the DCE-Identifier LCP Configuration
described in Section 3, with the with the Mode Field set to
value of 1. When a DCE device receives such a packet, it
answer with an LCP Configure-Ack packet. In each of
packets, the identifier field is set to 0. If the originator
the Configure-Request packet does not receive a Configure-
response within a user configurable time T1, the unit MUST
to transparent (Mode-0) operation
Mode-2:
A Mode-2 device will first try to operate in Mode-2 by
PPP normally, following the state machine described in [1].
LCP Configure-Request MUST include the DCE-
Configuration Option with the Mode Field set to 2. If the
receives a Configure-Reject Packet Containing the DCE-Identifier
the unit MUST revert immediately to transparent (Mode-0)
operation. If the LCP state machine times out because a
was not received in user configurable time T2, or if a Mode-1
Configuration-Request packet is received, the unit attempts
operate in Mode-1 by following the procedure listed above
ultimately reverting to Mode-0 operation if the Mode-1
times out
In either case, the unit is not prohibited from sending
Configuration-Request packets before the applicable timer (T1, T2)
expires. A unit may also initiate the handshake procedure at
time
Schneider & Venters Informational [Page 8]
RFC 1976 PPP DCE August 1996
7. Security
Security issues are not discussed in this memo
8.
[1] Simpson, W., ed., "The Point-to-Point Protocol (PPP)",
51, RFC 1661, July 1994.
[2] Schneider, K., and S. Venters, "PPP Serial Data
Protocol (PPP-SDTP)", RFC 1963, August 1996.
[3] Rand, D., "The PPP Compression Control Protocol (CCP)",
1962, June 1996.
[4] Lutz, R., "PPP LZS-DCP Compression Protocol", RFC 1967
August 1996.
[5] CCITT Recommendation V.120, "Support by an ISDN of
Terminal Equipment with V-Series Type Interfaces
Provision for Statistical Multiplexing (revised 1992)", ITU-T
1993.
[6] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
January 1994.
[7] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.
Chair's
The working group can be contacted via the current chair
Karl
Ascend
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.
Schneider & Venters Informational [Page 9]
RFC 1976 PPP DCE August 1996
Authors'
Questions about this memo can also be directed to
Kevin
Adtran, Inc
901 Explorer Blvd
Huntsville, AL 35806-2807
Phone: (205) 971-8000
EMail: kevin@adtran.
Stuart
Adtran, Inc
901 Explorer Blvd
Huntsville, AL 35806-2807
Phone: (205) 971-8000
EMail: sventers@adtran.
Schneider & Venters Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
