[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 RFC 1976

Network Working Group                                    Kevin Schneider
Internet Draft                                            Stuart Venters
                                                            ADTRAN, Inc.
expires May 1995                                           November 1994



  PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)
                 draft-ietf-pppext-dce-compress-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.

   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.  Internet Drafts 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.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories 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.

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



Schneider & Venters         expires May 1995                    [Page i]

DRAFT                           PPP DCE                    November 1994


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













































Schneider & Venters         expires May 1995                   [Page ii]

DRAFT                           PPP DCE                    November 1994


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         expires May 1995                    [Page 1]

DRAFT                           PPP DCE                    November 1994


             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.














Schneider & Venters         expires May 1995                    [Page 2]

DRAFT                           PPP DCE                    November 1994


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

      21  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

         21




Schneider & Venters         expires May 1995                    [Page 3]

DRAFT                           PPP DCE                    November 1994


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





Schneider & Venters         expires May 1995                    [Page 4]

DRAFT                           PPP DCE                    November 1994


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

   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



Schneider & Venters         expires May 1995                    [Page 5]

DRAFT                           PPP DCE                    November 1994


   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.

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





Schneider & Venters         expires May 1995                    [Page 6]

DRAFT                           PPP DCE                    November 1994


      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 |
      +----+----+------+--------+-------+-----+

      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



Schneider & Venters         expires May 1995                    [Page 7]

DRAFT                           PPP DCE                    November 1994


      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.



7.  Security

   Security issues are not addressed in this memo.



8.  References


   [1]    Simpson, W.A., ed., "The Point-to-Point Protocol (PPP)", RFC
          1661 (STD 51), July 1994.

   [2]    Schneider, K. and Venters, S., "PPP Serial Data Transport
          Protocol (PPP-SDTP)", work in progress.

   [3]    Rand, D., "The PPP Compression Control Protocol (CCP)", work
          in progress.

   [4]    Lutz, R., "PPP LZS-DCP Compression Protocol", work in
          progress.

   [5]    CCITT Recommendation V.120, "Support by an ISDN of Data



Schneider & Venters         expires May 1995                    [Page 8]

DRAFT                           PPP DCE                    November 1994


          Terminal Equipment with V-Series Type Interfaces with
          Provision for Statistical Multiplexing (revised 1992)", ITU-T,
          1993.

   [6]    Simpson, W.A., "PPP in HDLC-like Framing", RFC 1662 (STD 51),
          January 1994.

   [7]    Simpson, W.A., "PPP LCP Extensions", RFC 1570, January 1994.


Chair's Address

   The working group can be contacted via the current chair:

      Fred Baker
      Senior Software Engineer
      Cisco Systems
      519 Lado Drive
      Santa Barbara, California 93111
      (805) 681-0115

      EMail: fred@cisco.com



Author's Address

   Questions about this memo can also be directed to:

      Kevin Schneider
      Stuart Venters

      Adtran, Inc.
      901 Explorer Blvd.
      Huntsville, AL 35806-2807

      (205) 971-8000

      Email:  kevin@adtran.com
              sventers@adtran.com











Schneider & Venters         expires May 1995                    [Page 9]
DRAFT                           PPP DCE                    November 1994


                           Table of Contents


     1.     Introduction ..........................................    1
        1.1       Specification of Requirements ...................    1
        1.2       Terminology .....................................    2

     2.     Modes of Operation ....................................    3

     3.     PPP Link Control Protocol Extension ...................    3

     4.     Required PPP Elements .................................    4
        4.1       Required Configuration Options and Parameters

     5.     Mode-1 Requirements ...................................    5
        5.1       Detailed Mode-1 Example .........................    6

     6.     Initial Handshake Operation ...........................    7

     7.     Security ..............................................    8

     8.     References ............................................    8

     CHAIR'S ADDRESS ..............................................    9

     AUTHOR'S ADDRESS .............................................    9


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/