home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1976.txt < prev    next >
Text File  |  1996-08-15  |  20KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       K. Schneider
  8. Request for Comments: 1976                                    S. Venters
  9. Category: Informational                                     ADTRAN, Inc.
  10.                                                              August 1996
  11.  
  12.  
  13.   PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)
  14.  
  15. Status of This Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  24.    transporting multi-protocol datagrams over point-to-point links.  PPP
  25.    defines an extensible Link Control Protocol, and proposes a family of
  26.    Network Control Protocols for establishing and configuring different
  27.    network-layer protocols.
  28.  
  29.    The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a
  30.    standard method for encapsulating and transporting serial data over a
  31.    PPP link.  The PPP Compression Control Protocol [3] provides a
  32.    standard method for selecting and using a compression protocol to
  33.    provide for data compression on a PPP link.
  34.  
  35.    This document defines a specific set of parameters for these
  36.    protocols and an LCP extension to define a standard way of using PPP
  37.    for data compression of serial data in Data Circuit-Terminating
  38.    Equipment (DCE).
  39.  
  40. Table of Contents
  41.  
  42.      1.     Introduction ..........................................    2
  43.         1.1       Specification of Requirements ...................    2
  44.         1.2       Terminology .....................................    3
  45.      2.     Modes of Operation ....................................    3
  46.      3.     PPP Link Control Protocol Extension ...................    4
  47.      4.     Required PPP Elements .................................    4
  48.         4.1       Required Configuration Options and Parameters ...    5
  49.      5.     Mode-1 Requirements ...................................    6
  50.         5.1       Detailed Mode-1 Example .........................    7
  51.      6.     Initial Handshake Operation ...........................    8
  52.      7.     Security ..............................................    9
  53.      8.     References ............................................    9
  54.      CHAIR'S ADDRESS ..............................................    9
  55.  
  56.  
  57.  
  58. Schneider & Venters          Informational                      [Page 1]
  59.  
  60. RFC 1976                        PPP DCE                      August 1996
  61.  
  62.  
  63.      AUTHORS' ADDRESSES ...........................................   10
  64.  
  65. 1.  Introduction
  66.  
  67.    This document is a product of the TR30.1 ad hoc committee on
  68.    compression of synchronous data.  It represents a component of a
  69.    proposal to use PPP to provide compression of synchronous serial data
  70.    in DSU/CSUs.
  71.  
  72.    PPP [1] has three main components:
  73.  
  74.       1. A method for encapsulating multi-protocol datagrams.
  75.  
  76.       2. A Link Control Protocol (LCP) for establishing, configuring,
  77.          and testing the data-link connection.
  78.  
  79.       3. A family of Network Control Protocols for establishing and
  80.          configuring different network-layer protocols.
  81.  
  82.    In addition to providing support for multi-protocol datagrams, the
  83.    Point-to-Point Protocol (PPP) [1] has defined an effective and robust
  84.    negotiating mechanism that can be used on point to point links.  When
  85.    used in conjunction with the PPP Compression Control Protocol [3] and
  86.    one of the PPP Compression Protocols [4], PPP provides an
  87.    interoperable method of employing data compression on a point-to-
  88.    point link.
  89.  
  90.    The PPP Serial Data Transport Protocol (PPP-SDTP) and the PPP Serial
  91.    Data Control Protocol (PPP-SDCP) [2] have been developed to allow
  92.    serial data to be carried within a PPP packet.  PPP-SDTP uses a
  93.    terminal adaption header based on that of ITU-T Recommendation V.120
  94.    [5].
  95.  
  96. 1.1.  Specification of Requirements
  97.  
  98.    In this document, several words are used to signify the requirements
  99.    of the specification.  These words are often capitalized.
  100.  
  101.    MUST      This word, or the adjective "required", means that the
  102.              definition is an absolute requirement of the specification.
  103.  
  104.    MUST NOT  This phrase means that the definition is an absolute
  105.              prohibition of the specification.
  106.  
  107.    SHOULD    This word, or the adjective "recommended", means that there
  108.              may exist valid reasons in particular circumstances to
  109.              ignore this item, but the full implications must be
  110.              understood and carefully weighed before choosing a
  111.  
  112.  
  113.  
  114. Schneider & Venters          Informational                      [Page 2]
  115.  
  116. RFC 1976                        PPP DCE                      August 1996
  117.  
  118.  
  119.              different course.
  120.  
  121.    MAY       This word, or the adjective "optional", means that this
  122.              item is one of an allowed set of alternatives.  An
  123.              implementation which does not include this option MUST be
  124.              prepared to interoperate with another implementation which
  125.              does include the option.
  126.  
  127. 1.2.  Terminology
  128.  
  129.    This document frequently uses the following terms:
  130.  
  131.    datagram  The unit of transmission in the network layer (such as IP).
  132.              A datagram may be encapsulated in one or more packets
  133.              passed to the data link layer.
  134.  
  135.    frame     The unit of transmission at the data link layer.  A frame
  136.              may include a header and/or a trailer, along with some
  137.              number of units of data.
  138.  
  139.    packet    The basic unit of encapsulation, which is passed across the
  140.              interface between the network layer and the data link
  141.              layer.  A packet is usually mapped to a frame; the
  142.              exceptions are when data link layer fragmentation is being
  143.              performed, or when multiple packets are incorporated into a
  144.              single frame.
  145.  
  146.    peer      The other end of the point-to-point link.
  147.  
  148.    silently discard
  149.              This means the implementation discards the packet without
  150.              further processing.  The implementation SHOULD provide the
  151.              capability of logging the error, including the contents of
  152.              the silently discarded packet, and SHOULD record the event
  153.              in a statistics counter.
  154.  
  155. 2.  Modes of Operation
  156.  
  157.    This document provides for three modes of operation for DCE devices:
  158.    Mode-0 represents transparent operation; Mode-1 a simplified,
  159.    predefined compression format; and Mode-2, a full PPP implementation
  160.    providing compression of serial data.
  161.  
  162.    Mode-0 represents the operating mode of currently deployed DCEs that
  163.    operate in transparent mode, without any DCE-to-DCE protocols.
  164.    Mode-1 devices implement data compression upon detecting an initial
  165.    handshake, which is implemented via an newly defined LCP
  166.    Configuration Option called the DCE-Identifier.  The DCE-Identifier
  167.  
  168.  
  169.  
  170. Schneider & Venters          Informational                      [Page 3]
  171.  
  172. RFC 1976                        PPP DCE                      August 1996
  173.  
  174.  
  175.    is used both to distinguish DCE devices from PPP bridges and routers,
  176.    and to all Mode-1 and Mode-2 DCE devices to interoperate, via its
  177.    Mode parameter.  In Mode-1, the parameters of operation are not
  178.    negotiable.  Mode-2 devices implement the full LCP state machine and
  179.    are therefore capable of negotiating alternatives to the default set
  180.    of paramaters and options.  Mode-2 devices must also support Mode-1
  181.    operation, and fall-back to such operation when connected to a Mode-1
  182.    device.  The mechanism of the Mode-1/Mode-2 handshake is given in
  183.    Section 7.
  184.  
  185. 3.  PPP Link Control Protocol Extension
  186.  
  187.    The use of PPP in Compression DCE requires the use of an additional
  188.    LCP Configuration Option:
  189.  
  190.       25  DCE-Identifier
  191.  
  192.  
  193.    DCE-Identifier
  194.  
  195.       The presence of this option indicates that the system sending it
  196.       is Data Circuit-Terminating Equipment (DCE) that desires to
  197.       establish a serial data compression link.
  198.  
  199.        0                   1                   2
  200.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  201.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.       |     Type      |    Length     |      Mode     |
  203.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  204.  
  205.       Type
  206.  
  207.          25
  208.  
  209.       Length
  210.  
  211.          3
  212.  
  213.       Mode
  214.  
  215.          1   Mode-1 (No Additional Negotiation)
  216.          2   Mode-2 (Full PPP Negotiation and State Machine)
  217.  
  218. 4.  Required PPP Elements
  219.  
  220.    Unlike PPP's native bridge/router environment, the minimum
  221.    requirement for use of PPP in DCE equipment is not simply
  222.    interoperability, but rather interoperability with effective data
  223.  
  224.  
  225.  
  226. Schneider & Venters          Informational                      [Page 4]
  227.  
  228. RFC 1976                        PPP DCE                      August 1996
  229.  
  230.  
  231.    compression.  With this in mind, it is desirable to specify a minimum
  232.    PPP feature set, that is somewhat different than that of a normal PPP
  233.    bridge/router requirement.
  234.  
  235.    This different feature set includes: support for compression, support
  236.    of a single default compression algorithm, support of Protocol-Field
  237.    compression, support of Address-and-Control-Field-Compression,
  238.    support of PPP-SDTP, etc.
  239.  
  240.    The minimum feature set includes the following protocols:
  241.  
  242.       PPP Link Control Protocol (Mode-1 must include a subset) [1]
  243.       PPP in HDLC-like Framing [6]
  244.       PPP Compression Control Protocol (Mode-2 only) [3]
  245.       PPP LZS-DCP Compression Protocol [4]
  246.       PPP Serial Data Transport Protocol [2]
  247.       PPP Serial Data Control Protocol (Mode-2 only) [2]
  248.  
  249.    The Stacker-LZS algorithm from Stac Electronics was chosen as the
  250.    default compression algorithm for DCE devices.  This decision was
  251.    made by the TR30.1 ad hoc based on licensing issues (agreeing to
  252.    non-discriminatory and reasonable terms), compression ratios, its
  253.    efficient use of processor and memory resources, and speed
  254.    scalability.  A compression protocol incorporating in-band
  255.    synchronization signaling was defined for the Stacker algorithm and
  256.    selected for the default compression protocol.  This protocol is
  257.    known as the PPP LZS-DCP Compression Protocol [4].  Although the PPP
  258.    LZS-DCP Compression Protocol specifies a number of formats and
  259.    history management options, only the default format with a single
  260.    history must be implemented.
  261.  
  262. 4.1.  Required Configuration Options and Parameters
  263.  
  264.    To ensure that implementations are able to interoperate with
  265.    effective data compression, a required set of Configuration Options
  266.    are specified.  These Options are assumed in Mode-1, and are
  267.    negotiated in Mode-2, using the standard PPP negotiation state
  268.    machine.  (Mode-1 uses a fixed packet format with a predetermined set
  269.    of values for LCP, LZS-DCP, and SDTP Configuration
  270.    Options/parameters.  The required values listed in this section are
  271.    the predefined values.)
  272.  
  273.    The following LCP Configuration Options [7] MUST be supported:
  274.  
  275.       Maximum-Receive-Unit                 1550
  276.       Address/Control-Field-Compression    Yes
  277.       Protocol-Field-Compression           Yes
  278.  
  279.  
  280.  
  281.  
  282. Schneider & Venters          Informational                      [Page 5]
  283.  
  284. RFC 1976                        PPP DCE                      August 1996
  285.  
  286.  
  287.    The following CCP Configuration Option MUST be supported:
  288.  
  289.       Compression-Type                      23 (LZS-DCP)
  290.  
  291.    The following default LZS-DCP Configuration Options MUST be
  292.    supported:
  293.  
  294.       Check-Mode                    3 (sequence + LCB)
  295.       History-Count                 1 (single history)
  296.       Process-Mode                  0 (None)
  297.  
  298.    The default SDTP/SDCP Configuration Options MUST be supported.  They
  299.    are:
  300.  
  301.       Packet-Format:                Header-Last
  302.       Header-Type:                  H-Only
  303.       Multiple-Packets:             Off
  304.       Multi-Port:                   Off
  305.       Transport-Mode:               HDLC-Synchronous
  306.       Maximum-Frame-Size:           10,000 bytes
  307.       Allow-Odd-Frames:             Off
  308.       FCS-Type:                     Transparent-Transport
  309.       Flow-Expiration-Time:         100
  310.  
  311. 5.  Mode-1 Requirements
  312.  
  313.    DSUs that use only Mode-1 (non-negotiate mode) use only a
  314.    predetermined set of PPP packets.  In addition to a fixed data packet
  315.    format, two fixed formats are used to differentiate between Mode-1
  316.    devices and Mode-0 (transparent) devices.  Mode-1 devices are
  317.    designed to operate using compression if a peer has the same
  318.    capability, or revert to transparent operation (Mode-0) if the peer
  319.    does not support standard compression.
  320.  
  321.    Mode-1 devices use LZS-DCP Compression Packets as specified in [4].
  322.    These packets include the capabilities of DCP:  Reset-Request and
  323.    Acknowledge, Compressed/Transparent, etc.  Since the packets include
  324.    signalling, these packets can be sent with an empty data field to
  325.    signal a reset request if no data packets are ready for piggy-backed
  326.    signalling.
  327.  
  328.    Exactly one LZS-DCP packet is encapsulated in the PPP Information
  329.    field, where the PPP Protocol field indicates type 00FD (Compression
  330.    Protocol).  Exactly one SDTP packet is transported by each LZS-DCP
  331.    data packet.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Schneider & Venters          Informational                      [Page 6]
  339.  
  340. RFC 1976                        PPP DCE                      August 1996
  341.  
  342.  
  343.    Operation in Mode-1 implies a set of predetermined values for LCP,
  344.    LZS-DCP, and SDTP configuration options and parameters, using the
  345.    values listed in the preceding section.
  346.  
  347.    The following PPP packets are permitted and recognized:
  348.  
  349.       LCP Configure-Request with DCE Mode-1 Configuration Option
  350.       LCP Configure-Ack with DCE Mode-1 Configuration Option
  351.       LZS-DCP Packet with the data field containing an SDTP packet
  352.       LZS-DCP Packet with an empty data field
  353.  
  354.    Protocol-Field-Compression and Address-and-Control-Field-Compression
  355.    is used on all packets except the handshake packets (LCP packets).
  356.  
  357.    Any Mode-1 or Mode-2 DCE that receives a Mode-1 request MUST
  358.    Acknowledge the request.
  359.  
  360. 5.1.  Detailed Mode-1 Example
  361.  
  362.    Detailed Example when using Mode-1 on a point-to-point leased or
  363.    circuit switched link (using PPP in HDLC-like Framing [6]) (data
  364.    shown is after flags and inserted 0s are removed; lower case letters
  365.    and numbers represent actual values, uppercase represent data fields
  366.    whose values may vary from packet to packet; parentheses surrounding
  367.    a field indicate that the field may not be present in all packets of
  368.    that type):
  369.  
  370.       LCP Configure-Request:
  371.                                                Config. Opt.
  372.       Addr. Ctl.  PID    Code ID   Length Type Lngth Mode
  373.       +----+----+-------+----+----+-------+----+----+----+-----+
  374.       | ff | 03 | c0 21 | 01 | 00 | 00 07 | 21 | 03 | 01 | FCS |
  375.       +----+----+-------+----+----+-------+----+----+----+-----+
  376.  
  377.       LCP Configure-Ack:
  378.  
  379.                                                Config. Opt.
  380.       Addr. Ctl.  PID    Code ID   Length Type Lngth Mode
  381.       +----+----+-------+----+----+-------+----+----+----+-----+
  382.       | ff | 03 | c0 21 | 02 | 00 | 00 07 | 21 | 03 | 01 | FCS |
  383.       +----+----+-------+----+----+-------+----+----+----+-----+
  384.  
  385.       LZS-DCP Packet:
  386.  
  387.        PID  DCP
  388.       +----+----+------+------ -+-------+-----+
  389.       | fd | HD | (SQ) | (DATA) | (LCB) | FCS |
  390.       +----+----+------+--------+-------+-----+
  391.  
  392.  
  393.  
  394. Schneider & Venters          Informational                      [Page 7]
  395.  
  396. RFC 1976                        PPP DCE                      August 1996
  397.  
  398.  
  399.       The DATA field contains a compressed or uncompressed SDTP-PDU.
  400.       The LCB field is only present on a packet containing compressed
  401.       data.  The Sequence Number and Data fields are only present on
  402.       packets that contain data.
  403.  
  404.                         +----+------+----+
  405.             SDTP-PDU:   | 49 | DATA | HD |
  406.                         +----+------+----+
  407.  
  408. 6.  Initial Handshake Operation
  409.  
  410.    When a unit is powered up, or when the lower layer signals that the
  411.    peer has gone out of service and returned, the handshake procedure is
  412.    initiated.  The handshake procedure for Mode-1 and Mode-2 devices is
  413.    described below.
  414.  
  415.    Mode-1:
  416.  
  417.       When starting Mode-1, each DCE sends out an LCP Configure-Request
  418.       packet containing only the DCE-Identifier LCP Configuration Option
  419.       described in Section 3, with the with the Mode Field set to a
  420.       value of 1.  When a DCE device receives such a packet, it must
  421.       answer with an LCP Configure-Ack packet.  In each of these
  422.       packets, the identifier field is set to 0.  If the originator of
  423.       the Configure-Request packet does not receive a Configure-Ack
  424.       response within a user configurable time T1, the unit MUST revert
  425.       to transparent (Mode-0) operation.
  426.  
  427.    Mode-2:
  428.  
  429.       A Mode-2 device will first try to operate in Mode-2 by starting
  430.       PPP normally, following the state machine described in [1].  The
  431.       LCP Configure-Request MUST include the DCE-Identifier
  432.       Configuration Option with the Mode Field set to 2.  If the unit
  433.       receives a Configure-Reject Packet Containing the DCE-Identifier,
  434.       the unit MUST revert immediately to transparent (Mode-0)
  435.       operation.  If the LCP state machine times out because a response
  436.       was not received in user configurable time T2, or if a Mode-1
  437.       Configuration-Request packet is received, the unit attempts to
  438.       operate in Mode-1 by following the procedure listed above,
  439.       ultimately reverting to Mode-0 operation if the Mode-1 procedure
  440.       times out.
  441.  
  442.    In either case, the unit is not prohibited from sending multiple
  443.    Configuration-Request packets before the applicable timer (T1, T2)
  444.    expires.  A unit may also initiate the handshake procedure at any
  445.    time.
  446.  
  447.  
  448.  
  449.  
  450. Schneider & Venters          Informational                      [Page 8]
  451.  
  452. RFC 1976                        PPP DCE                      August 1996
  453.  
  454.  
  455. 7.  Security Considerations
  456.  
  457.    Security issues are not discussed in this memo.
  458.  
  459. 8.  References
  460.  
  461.    [1]    Simpson, W., ed., "The Point-to-Point Protocol (PPP)", STD
  462.           51, RFC 1661, July 1994.
  463.  
  464.    [2]    Schneider, K., and S. Venters, "PPP Serial Data Transport
  465.           Protocol (PPP-SDTP)", RFC 1963, August 1996.
  466.  
  467.    [3]    Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
  468.           1962, June 1996.
  469.  
  470.    [4]    Lutz, R., "PPP LZS-DCP Compression Protocol", RFC 1967
  471.           August 1996.
  472.  
  473.    [5]    CCITT Recommendation V.120, "Support by an ISDN of Data
  474.           Terminal Equipment with V-Series Type Interfaces with
  475.           Provision for Statistical Multiplexing (revised 1992)", ITU-T,
  476.           1993.
  477.  
  478.    [6]    Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
  479.           January 1994.
  480.  
  481.    [7]    Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.
  482.  
  483. Chair's Address
  484.  
  485.    The working group can be contacted via the current chair:
  486.  
  487.    Karl Fox
  488.    Ascend Communications
  489.    3518 Riverside Drive, Suite 101
  490.    Columbus, Ohio 43221
  491.  
  492.    EMail: karl@ascend.com
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Schneider & Venters          Informational                      [Page 9]
  507.  
  508. RFC 1976                        PPP DCE                      August 1996
  509.  
  510.  
  511. Authors' Addresses
  512.  
  513.    Questions about this memo can also be directed to:
  514.  
  515.    Kevin Schneider
  516.    Adtran, Inc.
  517.    901 Explorer Blvd.
  518.    Huntsville, AL 35806-2807
  519.  
  520.    Phone: (205) 971-8000
  521.    EMail:  kevin@adtran.com
  522.  
  523.  
  524.    Stuart Venters
  525.    Adtran, Inc.
  526.    901 Explorer Blvd.
  527.    Huntsville, AL 35806-2807
  528.  
  529.    Phone: (205) 971-8000
  530.    EMail: sventers@adtran.com
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Schneider & Venters          Informational                     [Page 10]
  563.  
  564.