GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1976

Network Working Group K. Schneider Request for Comments: 1976 S. Venters Category: Informational ADTRAN, Inc.

                                                           August 1996
PPP 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 Contents

   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. 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 a

Schneider & 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-Identifier

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 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 in
 Section 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 data

Schneider & 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           Yes

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 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:         100

5. 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 in Section 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 1996

7. 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)", RFC
        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 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.com

Schneider & Venters Informational [Page 9] RFC 1976 PPP DCE August 1996

Authors' 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.com

Schneider & Venters Informational [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1976.txt · Last modified: 1996/08/13 17:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki