doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc1976.txt b/doc/rfc/rfc1976.txt
new file mode 100644
index 0000000..e7d6c5a
--- /dev/null
+++ b/doc/rfc/rfc1976.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+