Movatterモバイル変換

Network Working Group                                       K. SchneiderRequest for Comments: 1976                                    S. VentersCategory: Informational                                     ADTRAN, Inc.                                                             August 1996PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)Status of This Memo   This memo provides information for the Internet community.  This memo   does not specify an Internet standard of any kind.  Distribution of   this memo is unlimited.Abstract   The Point-to-Point Protocol (PPP) [1] provides a standard method for   transporting multi-protocol datagrams over point-to-point links.  PPP   defines an extensible Link Control Protocol, and proposes a family of   Network Control Protocols for establishing and configuring different   network-layer protocols.   The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a   standard method for encapsulating and transporting serial data over a   PPP link.  The PPP Compression Control Protocol [3] provides a   standard method for selecting and using a compression protocol to   provide for data compression on a PPP link.   This document defines a specific set of parameters for these   protocols and an LCP extension to define a standard way of using PPP   for data compression of serial data in Data Circuit-Terminating   Equipment (DCE).Table of Contents1.     Introduction ..........................................21.1       Specification of Requirements ...................21.2       Terminology .....................................32.     Modes of Operation ....................................33.     PPP Link Control Protocol Extension ...................44.     Required PPP Elements .................................44.1       Required Configuration Options and Parameters ...55.     Mode-1 Requirements ...................................65.1       Detailed Mode-1 Example .........................76.     Initial Handshake Operation ...........................87.     Security ..............................................98.     References ............................................9     CHAIR'S ADDRESS ..............................................9Schneider & Venters          Informational                      [Page 1]

RFC 1976                        PPP DCE                      August 1996     AUTHORS' ADDRESSES ...........................................101.  Introduction   This document is a product of the TR30.1 ad hoc committee on   compression of synchronous data.  It represents a component of a   proposal to use PPP to provide compression of synchronous serial data   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 and         configuring different network-layer protocols.   In addition to providing support for multi-protocol datagrams, the   Point-to-Point Protocol (PPP) [1] has defined an effective and robust   negotiating mechanism that can be used on point to point links.  When   used in conjunction with the PPP Compression Control Protocol [3] and   one of the PPP Compression Protocols [4], PPP provides an   interoperable method of employing data compression on a point-to-   point link.   The PPP Serial Data Transport Protocol (PPP-SDTP) and the PPP Serial   Data Control Protocol (PPP-SDCP) [2] have been developed to allow   serial data to be carried within a PPP packet.  PPP-SDTP uses a   terminal adaption header based on that of ITU-T Recommendation V.120   [5].1.1.  Specification of Requirements   In this document, several words are used to signify the requirements   of the specification.  These words are often capitalized.   MUST      This word, or the adjective "required", means that the             definition is an absolute requirement of the specification.   MUST NOT  This phrase means that the definition is an absolute             prohibition of the specification.   SHOULD    This word, or the adjective "recommended", means that there             may exist valid reasons in particular circumstances to             ignore this item, but the full implications must be             understood and carefully weighed before choosing aSchneider & Venters          Informational                      [Page 2]

RFC 1976                        PPP DCE                      August 1996             different course.   MAY       This word, or the adjective "optional", means that this             item is one of an allowed set of alternatives.  An             implementation which does not include this option MUST be             prepared to interoperate with another implementation which             does include the option.1.2.  Terminology   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 packets             passed to the data link layer.   frame     The unit of transmission at the data link layer.  A frame             may include a header and/or a trailer, along with some             number of units of data.   packet    The basic unit of encapsulation, which is passed across the             interface between the network layer and the data link             layer.  A packet is usually mapped to a frame; the             exceptions are when data link layer fragmentation is being             performed, or when multiple packets are incorporated into a             single frame.   peer      The other end of the point-to-point link.   silently discard             This means the implementation discards the packet without             further processing.  The implementation SHOULD provide the             capability of logging the error, including the contents of             the silently discarded packet, and SHOULD record the event             in a statistics counter.2.  Modes of Operation   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 implementation   providing compression of serial data.   Mode-0 represents the operating mode of currently deployed DCEs that   operate in transparent mode, without any DCE-to-DCE protocols.   Mode-1 devices implement data compression upon detecting an initial   handshake, which is implemented via an newly defined LCP   Configuration Option called the DCE-Identifier.  The DCE-IdentifierSchneider & 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 its   Mode parameter.  In Mode-1, the parameters of operation are not   negotiable.  Mode-2 devices implement the full LCP state machine and   are therefore capable of negotiating alternatives to the default set   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 inSection 7.3.  PPP Link Control Protocol Extension   The use of PPP in Compression DCE requires the use of an additional   LCP Configuration Option:      25  DCE-Identifier   DCE-Identifier      The presence of this option indicates that the system sending it      is Data Circuit-Terminating Equipment (DCE) that desires to      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     |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      Type         25      Length         3      Mode         1   Mode-1 (No Additional Negotiation)         2   Mode-2 (Full PPP Negotiation and State Machine)4.  Required PPP Elements   Unlike PPP's native bridge/router environment, the minimum   requirement for use of PPP in DCE equipment is not simply   interoperability, but rather interoperability with effective dataSchneider & Venters          Informational                      [Page 4]

RFC 1976                        PPP DCE                      August 1996   compression.  With this in mind, it is desirable to specify a minimum   PPP feature set, that is somewhat different than that of a normal PPP   bridge/router requirement.   This different feature set includes: support for compression, support   of a single default compression algorithm, support of Protocol-Field   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 the   default compression algorithm for DCE devices.  This decision was   made by the TR30.1 ad hoc based on licensing issues (agreeing to   non-discriminatory and reasonable terms), compression ratios, its   efficient use of processor and memory resources, and speed   scalability.  A compression protocol incorporating in-band   synchronization signaling was defined for the Stacker algorithm and   selected for the default compression protocol.  This protocol is   known as the PPP LZS-DCP Compression Protocol [4].  Although the PPP   LZS-DCP Compression Protocol specifies a number of formats and   history management options, only the default format with a single   history must be implemented.4.1.  Required Configuration Options and Parameters   To ensure that implementations are able to interoperate with   effective data compression, a required set of Configuration Options   are specified.  These Options are assumed in Mode-1, and are   negotiated in Mode-2, using the standard PPP negotiation state   machine.  (Mode-1 uses a fixed packet format with a predetermined set   of values for LCP, LZS-DCP, and SDTP Configuration   Options/parameters.  The required values listed in this section are   the predefined values.)   The following LCP Configuration Options [7] MUST be supported:      Maximum-Receive-Unit                 1550      Address/Control-Field-Compression    Yes      Protocol-Field-Compression           YesSchneider & 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 be   supported:      Check-Mode                    3 (sequence + LCB)      History-Count                 1 (single history)      Process-Mode                  0 (None)   The default SDTP/SDCP Configuration Options MUST be supported.  They   are:      Packet-Format:                Header-Last      Header-Type:                  H-Only      Multiple-Packets:             Off      Multi-Port:                   Off      Transport-Mode:               HDLC-Synchronous      Maximum-Frame-Size:           10,000 bytes      Allow-Odd-Frames:             Off      FCS-Type:                     Transparent-Transport      Flow-Expiration-Time:         1005.  Mode-1 Requirements   DSUs that use only Mode-1 (non-negotiate mode) use only a   predetermined set of PPP packets.  In addition to a fixed data packet   format, two fixed formats are used to differentiate between Mode-1   devices and Mode-0 (transparent) devices.  Mode-1 devices are   designed to operate using compression if a peer has the same   capability, or revert to transparent operation (Mode-0) if the peer   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 and   Acknowledge, Compressed/Transparent, etc.  Since the packets include   signalling, these packets can be sent with an empty data field to   signal a reset request if no data packets are ready for piggy-backed   signalling.   Exactly one LZS-DCP packet is encapsulated in the PPP Information   field, where the PPP Protocol field indicates type 00FD (Compression   Protocol).  Exactly one SDTP packet is transported by each LZS-DCP   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 the   values listed in the preceding section.   The following PPP packets are permitted and recognized:      LCP Configure-Request with DCE Mode-1 Configuration Option      LCP Configure-Ack with DCE Mode-1 Configuration Option      LZS-DCP Packet with the data field containing an SDTP packet      LZS-DCP Packet with an empty data field   Protocol-Field-Compression and Address-and-Control-Field-Compression   is used on all packets except the handshake packets (LCP packets).   Any Mode-1 or Mode-2 DCE that receives a Mode-1 request MUST   Acknowledge the request.5.1.  Detailed Mode-1 Example   Detailed Example when using Mode-1 on a point-to-point leased or   circuit switched link (using PPP in HDLC-like Framing [6]) (data   shown is after flags and inserted 0s are removed; lower case letters   and numbers represent actual values, uppercase represent data fields   whose values may vary from packet to packet; parentheses surrounding   a field indicate that the field may not be present in all packets of   that type):      LCP Configure-Request:                                               Config. Opt.      Addr. Ctl.  PID    Code ID   Length Type Lngth Mode      +----+----+-------+----+----+-------+----+----+----+-----+      | 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 Mode      +----+----+-------+----+----+-------+----+----+----+-----+      | ff | 03 | c0 21 | 02 | 00 | 00 07 | 21 | 03 | 01 | FCS |      +----+----+-------+----+----+-------+----+----+----+-----+      LZS-DCP Packet:       PID  DCP      +----+----+------+------ -+-------+-----+      | 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 compressed      data.  The Sequence Number and Data fields are only present on      packets that contain data.                        +----+------+----+            SDTP-PDU:   | 49 | DATA | HD |                        +----+------+----+6.  Initial Handshake Operation   When a unit is powered up, or when the lower layer signals that the   peer has gone out of service and returned, the handshake procedure is   initiated.  The handshake procedure for Mode-1 and Mode-2 devices is   described below.   Mode-1:      When starting Mode-1, each DCE sends out an LCP Configure-Request      packet containing only the DCE-Identifier LCP Configuration Option      described inSection 3, with the with the Mode Field set to a      value of 1.  When a DCE device receives such a packet, it must      answer with an LCP Configure-Ack packet.  In each of these      packets, the identifier field is set to 0.  If the originator of      the Configure-Request packet does not receive a Configure-Ack      response within a user configurable time T1, the unit MUST revert      to transparent (Mode-0) operation.   Mode-2:      A Mode-2 device will first try to operate in Mode-2 by starting      PPP normally, following the state machine described in [1].  The      LCP Configure-Request MUST include the DCE-Identifier      Configuration Option with the Mode Field set to 2.  If the unit      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 response      was not received in user configurable time T2, or if a Mode-1      Configuration-Request packet is received, the unit attempts to      operate in Mode-1 by following the procedure listed above,      ultimately reverting to Mode-0 operation if the Mode-1 procedure      times out.   In either case, the unit is not prohibited from sending multiple   Configuration-Request packets before the applicable timer (T1, T2)   expires.  A unit may also initiate the handshake procedure at any   time.Schneider & Venters          Informational                      [Page 8]

RFC 1976                        PPP DCE                      August 19967.  Security Considerations   Security issues are not discussed in this memo.8.  References   [1]    Simpson, W., ed., "The Point-to-Point Protocol (PPP)", STD          51,RFC 1661, July 1994.   [2]    Schneider, K., and S. Venters, "PPP Serial Data Transport          Protocol (PPP-SDTP)",RFC 1963, August 1996.   [3]    Rand, D., "The PPP Compression Control Protocol (CCP)",RFC1962, June 1996.   [4]    Lutz, R., "PPP LZS-DCP Compression Protocol",RFC 1967          August 1996.   [5]    CCITT Recommendation V.120, "Support by an ISDN of Data          Terminal Equipment with V-Series Type Interfaces with          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 Address   The working group can be contacted via the current chair:   Karl Fox   Ascend Communications   3518 Riverside Drive, Suite 101   Columbus, Ohio 43221   EMail: karl@ascend.comSchneider & Venters          Informational                      [Page 9]

RFC 1976                        PPP DCE                      August 1996Authors' Addresses   Questions about this memo can also be directed to:   Kevin Schneider   Adtran, Inc.   901 Explorer Blvd.   Huntsville, AL 35806-2807   Phone: (205) 971-8000   EMail:  kevin@adtran.com   Stuart Venters   Adtran, Inc.   901 Explorer Blvd.   Huntsville, AL 35806-2807   Phone: (205) 971-8000   EMail: sventers@adtran.comSchneider & Venters          Informational                     [Page 10]