home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1963 < prev    next >
Text File  |  1996-08-14  |  38KB  |  1,124 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       K. Schneider
  8. Request for Comments: 1963                                    S. Venters
  9. Category: Informational                                     ADTRAN, Inc.
  10.                                                              August 1996
  11.  
  12.  
  13.                PPP Serial Data Transport Protocol (SDTP)
  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.    This document describes a new Network level protocol (from the PPP
  30.    point of view), PPP Serial Data Transport Protocol, that provides
  31.    encapsulation and an associated control protocol for transporting
  32.    serial data streams over a PPP link.  This protocol was developed for
  33.    the purpose of using PPP's many features to provide a standard method
  34.    for synchronous data compression.  The encapsulation uses a header
  35.    structure based on that of the ITU-T Recommendation V.120 [2].
  36.  
  37. Table of Contents
  38.  
  39.      1.     Introduction ..........................................    2
  40.      2.     SDTP Packets ..........................................    3
  41.         2.1       Padding .........................................    4
  42.         2.2       Packet Formats ..................................    4
  43.      3.     Serial Data Control Protocol ..........................   11
  44.      4.     SDCP Configuration Option Format ......................   12
  45.         4.1       Packet-Format ...................................   13
  46.         4.2       Header-Type .....................................   13
  47.         4.3       Length-Field-Present ............................   14
  48.         4.4       Multi-Port ......................................   14
  49.         4.5       Transport-Mode ..................................   15
  50.         4.6       Maximum-Frame-Size ..............................   16
  51.         4.7       Allow-Odd-Frames ................................   16
  52.         4.8       FCS-Type ........................................   17
  53.         4.9       Flow-Expiration-Time ............................   18
  54.      SECURITY CONSIDERATIONS ......................................   19
  55.  
  56.  
  57.  
  58. Schneider & Venters          Informational                      [Page 1]
  59.  
  60. RFC 1963                        PPP SDTP                     August 1996
  61.  
  62.  
  63.      REFERENCES ...................................................   19
  64.      CHAIR'S ADDRESS ..............................................   20
  65.      AUTHORS' ADDRESSES ...........................................   20
  66.  
  67. 1.  Introduction
  68.  
  69.    This document is a product of the TR30.1 ad hoc committee on
  70.    compression of synchronous data.  It represents a component of a
  71.    proposal to use PPP to provide compression of synchronous data in
  72.    DSU/CSUs.
  73.  
  74.    In addition to providing support for multi-protocol datagrams, the
  75.    Point-to-Point Protocol (PPP) [1] has defined an effective and robust
  76.    negotiating mechanism that can be used on point to point links.  When
  77.    used in conjunction with the PPP Compression Control Protocol [3] and
  78.    one of the PPP Compression Protocols [4-10], PPP provides an
  79.    interoperable method of employing data compression on a point-to-
  80.    point link.
  81.  
  82.    This document provides a PPP encapsulation for serial data,
  83.    specifying a transport protocol, PPP Serial Data Transport Protocol
  84.    (PPP-SDTP), and an associated control protocol, PPP Serial Data
  85.    Control Protocol (PPP-SDCP).  When these protocols are added to above
  86.    mentioned PPP protocols, PPP can be used to provide compression of
  87.    serial data on a point-to-point link.
  88.  
  89.    This first edition of PPP-SDTP/SDCP covers HDLC-like synchronous
  90.    serial data and asynchronous serial data.  It does this by using a
  91.    terminal adaption header based on that of ITU-T Recommendation V.120
  92.    [2].  Support may be added in the future for other synchronous
  93.    protocols as the marketplace demands.
  94.  
  95.    The V.120 terminal adaption header allows transported data frames to
  96.    be split over several packets, supports the transport of DTE port
  97.    idle and error information, and optionally supports the transport of
  98.    DTE control state information.
  99.  
  100.    In addition to the V.120 Header, fields can be added to the packet
  101.    format through negotiation to provide support for features not
  102.    included in the V.120 header.  The extra fields are: a Length Field,
  103.    which is used to distinguish packets in compound frames, and a Port
  104.    field, which is used to provide multi-port multiplexing capability.
  105.    The protocol also allows reserved bits in the V.120 header to be used
  106.    to transport non-octet aligned frames and to provide a flow control
  107.    mechanism.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Schneider & Venters          Informational                      [Page 2]
  115.  
  116. RFC 1963                        PPP SDTP                     August 1996
  117.  
  118.  
  119.    To provide these features, PPP-SDTP permits a single frame format to
  120.    be selected from several possible formats by using PPP-SDCP
  121.    negotiation.  The terminal adaption header can be either fixed length
  122.    or variable length, to allow either simplicity or flexibility.
  123.  
  124.    The default frame format places the terminal adaption header at the
  125.    end of the packet.  This permits optimal transmitter timelines when
  126.    user frames are segmented and compression is also used in conjunction
  127.    with this protocol.
  128.  
  129. 2.  SDTP Packets
  130.  
  131.    Before any SDTP packets may be communicated, PPP must reach the
  132.    Network-Layer Protocol phase, and the SDTP Control Protocol must
  133.    reach the Opened state.
  134.  
  135.    By default, exactly one SDTP packet is encapsulated in the PPP
  136.    Information field, where the PPP Protocol field indicates type hex
  137.    0049 (PPP-SDTP).  If the Length-Field-Present Configuration Option
  138.    and the LCP Compound-Frames Configuration Option are successfully
  139.    negotiated, multiple SDTP packets may be placed in the PPP
  140.    Information field, and they are distinguished by the presence of
  141.    Length fields in each packet.
  142.  
  143.    The maximum length of the SDTP datagram transmitted over a PPP link
  144.    is limited only by the negotiated Maximum-Frame-Size and the maximum
  145.    length of the Information field of a PPP encapsulated packet.  Note
  146.    that if compression is used on the PPP link, this the maximum length
  147.    of the SDTP datagram  may be larger or smaller than the maximum
  148.    length of the Information field of a PPP encapsulated packet,
  149.    depending on the particular compression algorithm and protocol used.
  150.  
  151.    ITU-T Recommendation V.120 [2] defines an adaption header that is
  152.    used with its asynchronous and synchronous modes of operation.  SDTP
  153.    packets include this header as a Header field to provide the protocol
  154.    adaption function.  Using negotiation, additional fields can be added
  155.    to the packet to provide sequencing and multiplexing capability
  156.    within SDTP. SDTP also has an option of using the reserved bits of
  157.    the header to provide a flow control mechanism and support for
  158.    transporting non-octet aligned data frames.
  159.  
  160.    The default SDTP packet format is designed to allow the efficient use
  161.    of the protocol's segmentation feature when combined with a PPP
  162.    Compression Protocol [4-10].  This format is a little different from
  163.    other PPP NCP's in that data is read from both ends of the packet.
  164.    The Header field is placed at the end of the SDTP packet, with the
  165.    order of the octets reversed.  This somewhat unique format has been
  166.    selected to allow optimal transmitter timelines when compression is
  167.  
  168.  
  169.  
  170. Schneider & Venters          Informational                      [Page 3]
  171.  
  172. RFC 1963                        PPP SDTP                     August 1996
  173.  
  174.  
  175.    used and transported data frames are split into multiple SDTP
  176.    packets.  In such a situation, the Header field contains the
  177.    information about whether the data is split into multiple packets or
  178.    not, so if it is located at the end of a packet, the decision can be
  179.    made after observing the compressed size of the packet.  The Header
  180.    field can then simply be run through the compressor after the
  181.    decision has been made.
  182.  
  183.    When the Header field is placed before the data, as in the optional
  184.    packet format, the transmitter must make the decision about whether
  185.    to split a frame over multiple packets without knowing about the
  186.    compressibility of the frame.  Therefore the optional format is
  187.    designed to be used when transported frames are not split into
  188.    multiple SDTP packets or where SDTP is not coupled with compression.
  189.    It is believed that this format may be useful for some hardware
  190.    implementations.
  191.  
  192. 2.1.  Padding
  193.  
  194.    If padding is used, SDTP packets require the use of the Length Field
  195.    or the previous negotiation of the LCP Self-Describing-Padding
  196.    Configuration Option [11].
  197.  
  198. 2.2.  Packet Formats
  199.  
  200.    The default SDTP packet format is shown below. The fields are
  201.    transmitted from left to right.
  202.  
  203.     0                   1                   2                   3
  204.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  205.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  206.    |        PPP Protocol ID        |    Transported Data ...
  207.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  208.    | Header -  H   |
  209.    +-+-+-+-+-+-+-+-+
  210.  
  211.    The two complete frame formats are shown below:  Header-Last and
  212.    Header-First.  Header-Last is the default packet format. The
  213.    additional fields provided support for:  Control State Information
  214.    (CS), multiple packets and multi-port multiplexing.  Again, the
  215.    fields are transmitted from left to right.  Descriptions of the
  216.    fields follow the packet formats.
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Schneider & Venters          Informational                      [Page 4]
  227.  
  228. RFC 1963                        PPP SDTP                     August 1996
  229.  
  230.  
  231.    Header-Last
  232.  
  233.     0                   1                   2                   3
  234.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  235.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  236.    |        PPP Protocol ID        |          (Length)             |
  237.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238.    |    (Port)     |  Transported Data / (Odd-Pad) ...
  239.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  240.    | Header - (CS) :       H       |
  241.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  242.  
  243.    Header-First
  244.  
  245.     0                   1                   2                   3
  246.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  247.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  248.    |        PPP Protocol ID        |          (Length)             |
  249.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  250.    |    (Port)     | Header  -  H  :     (CS)      |
  251.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  252.    |  Transported Data / (Odd-Pad) ...
  253.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  254.  
  255.  
  256.    PPP Protocol ID
  257.  
  258.       The PPP Protocol ID field is described in the Point-to-Point
  259.       Protocol Encapsulation [1].
  260.  
  261.       When the SDTP Protocol is successfully negotiated by the SDTP
  262.       Control Protocol (SDCP), the value is 0049 hex.  This value may be
  263.       compressed to one octet when Protocol-Field-Compression is
  264.       negotiated, or if one of the PPP compression protocols [4-10] is
  265.       used.
  266.  
  267.    Length
  268.  
  269.       The optional Length field is present in every SDTP packet upon
  270.       successful negotiation of the Length-Field-Present Configuration
  271.       Option.
  272.  
  273.       The value of the Length field is the combined lengths of the
  274.       Length, Port (if present), Header, Transmitted Data, and Odd-Pad
  275.       (if present) fields in octets.
  276.  
  277.       The length of the Length field defaults to one octet.  Valid
  278.       lengths are from 2 to 255 octets, since each packet must include
  279.  
  280.  
  281.  
  282. Schneider & Venters          Informational                      [Page 5]
  283.  
  284. RFC 1963                        PPP SDTP                     August 1996
  285.  
  286.  
  287.       at least a one octet Header field.
  288.  
  289.       If desired, the length field can be negotiated to be two octets in
  290.       length.  In that case, valid lengths are from 2 to 65535 octets,
  291.       and the field is transmitted most significant octet first.
  292.  
  293.       In either case, a length of 0 means that the combined length is
  294.       the same as the length of the remainder of the PPP Information
  295.       Field.
  296.  
  297.    Port
  298.  
  299.       The optional Port field is present in every SDTP packet upon
  300.       successful negotiation of the Multi-Port Option.
  301.  
  302.       The length of the Port field is one octet. Valid Port numbers are
  303.       0 to 254.  Port number 255 is reserved for control purposes (see
  304.       section on flow control).
  305.  
  306.    Header
  307.  
  308.       The Header field is the terminal adaption header from ITU-T
  309.       Recommendation V.120.  As specified in that document, it contains
  310.       up to two octets: The terminal adaption header octet (H), and the
  311.       optional header extension for control state information (CS).
  312.       SDTP only supports the protocol sensitive operation of V.120; bit
  313.       transparent operation is not supported.  The descriptions of the
  314.       header bits provided below are derived from the descriptions
  315.       provided in Recommendation V.120.  In addition to the bit
  316.       definitions of V.120, SDTP optionally permits the use of reserved
  317.       bits to be used for flow control and to provide support for non-
  318.       octet aligned frames.
  319.  
  320.       The length of the Header field is either one or two octets, and is
  321.       determined by the value of the E bit in the first octet.  By
  322.       default, the E-bit must be set in the H octet and the CS octet is
  323.       not present.  A Configuration Option may be negotiated to allow
  324.       the use of the CS octet, or even to require its presence in every
  325.       packet.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Schneider & Venters          Informational                      [Page 6]
  339.  
  340. RFC 1963                        PPP SDTP                     August 1996
  341.  
  342.  
  343.       H (V.120 Terminal Adaption Header)
  344.  
  345.          The format of the first octet of the Header field is shown
  346.          below:
  347.  
  348.             0     1     2     3     4     5     6     7
  349.          +-----+-----+-----+-----+-----+-----+-----+-----+
  350.          |  E  | BR  | Res | FC  | C2  | C1  |  B  |  F  |
  351.          +-----+-----+-----+-----+-----+-----+-----+-----+
  352.  
  353.          E - Extension Bit
  354.  
  355.             The E bit is the extension bit.  If set to 0, it indicates
  356.             that the Control-2 field is present.
  357.  
  358.          BR - Break / HDLC Idle Bit
  359.  
  360.             In asynchronous mode, the BR bit indicates the invocation of
  361.             the BREAK function by the DTE.  A value of 1 indicates
  362.             BREAK.
  363.  
  364.             In synchronous HDLC mode, the BR bit is used to indicate
  365.             that DTE port is receiving HDLC idle condition.  A value of
  366.             1 indicates this idle condition.
  367.  
  368.          Res - Reserved
  369.  
  370.  
  371.             This bit is reserved and MUST be set to 0.  (This is a
  372.             reserved bit in V.120.)
  373.  
  374.  
  375.          FC - Flow Control
  376.  
  377.             This bit can be used for flow control of SDTP traffic on the
  378.             network, for applications which require it.  When SDTP is
  379.             used in conjunction with data compression, flow control may
  380.             be needed.  Reasons for this could be that the DTE port uses
  381.             an X.21 interface (and therefore does not have independent
  382.             control of DTE transmit and receive clocks), or simply that
  383.             the underlying link layer (such as PPP in HDLC-like Framing)
  384.             does not include a mechanism for network flow control, so
  385.             some flow control mechanism is needed.
  386.  
  387.             This bit set to a value of 0 indicates that the receiver is
  388.             ready to receive data (Flow-On). A value of 1 indicates that
  389.             the receiver does not wish to receive data and the
  390.             transmitting peer should stop sending it (Flow-Off).  Flow
  391.  
  392.  
  393.  
  394. Schneider & Venters          Informational                      [Page 7]
  395.  
  396. RFC 1963                        PPP SDTP                     August 1996
  397.  
  398.  
  399.             control operates on a per port basis.  Flow control messages
  400.             on Port 255 affect all ports.
  401.  
  402.             To ensure that a missed Flow-On message cannot cause a
  403.             hangup condition, a Flow-Off is defined to expire after a
  404.             time of T1 seconds.  If a unit desires to keep its peer in
  405.             the Flow-Off state for more than T1 seconds, it MUST
  406.             transmit another Flow-Off message after every period of T1
  407.             seconds.  A unit that receives a Flow-Off message may resume
  408.             transmitting T1 seconds after the last Flow-Off was
  409.             received.  The value of T1 is controlled by the Flow-
  410.             Expiration-Time Configuration Option.  The default value is
  411.             10 seconds.  There is not a separate value for T1 for each
  412.             port; all ports use the same T1 value.
  413.  
  414.             (This bit is a reserved bit in V.120, which requires the bit
  415.             to be set to a value of zero.  The above definition of flow
  416.             control provides compatibility with this definition when
  417.             flow control is not used.)
  418.  
  419.  
  420.          C1, C2 - Error Control Bits
  421.  
  422.             The C1 and C2 bits are used for DTE port Error detection and
  423.             transmission.  Their meaning is defined in the following
  424.             table:
  425.  
  426.             +----+----+--------------+--------------+
  427.             |         |           Meaning           |
  428.             +----+----+--------------+--------------+
  429.             | C1 | C2 | Synchronous  | Asynchronous |
  430.             +----+----+--------------+--------------+
  431.             |  0 |  0 | No Error     | No Error     |
  432.             |    |    |     Detected |     Detected |
  433.             +----+----+--------------+--------------+
  434.             |  0 |  1 | FCS Error    | Stop-bit     |
  435.             |    |    |      (DTE)   |     Error    |
  436.             +----+----+--------------+--------------+
  437.             |  1 |  0 | Abort        | Parity Error |
  438.             |    |    |              | on the Last  |
  439.             |    |    |              | Character in |
  440.             |    |    |              | Frame        |
  441.             +----+----+--------------+--------------+
  442.             |  1 |  1 | DTE Overrun* | Stop-bit and |
  443.             |    |    |              | Parity Error |
  444.             +----+----+--------------+--------------+
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Schneider & Venters          Informational                      [Page 8]
  451.  
  452. RFC 1963                        PPP SDTP                     August 1996
  453.  
  454.  
  455.             Appropriate responses to these bits are provided in Sections
  456.             2.2.1 and 2.2.2 of the V.120 standard (where R reference
  457.             point is translated to mean DTE port.)
  458.  
  459.  
  460.          B, F - Segmentation Bits
  461.  
  462.             The B and F bits are used for segmenting and reassembly of
  463.             the transported frames in synchronous HDLC mode.  Setting
  464.             the B bit to 1 indicates that the packet contains the
  465.             beginning of a transported frame or a Begin Frame.  Setting
  466.             the F bit indicates that the packet contains the final
  467.             portion of a transported frame, or a Final Frame. A packet
  468.             that contains neither the beginning of a frame nor the end
  469.             is said to contain a Middle Frame.  For asynchronous mode
  470.             and bit transparent mode operation both bits MUST be set to
  471.             1.  The following table summarizes the use of these bits:
  472.  
  473.             +---+---+--------------+----------------+
  474.             |       |         Application           |
  475.             +---+---+--------------+----------------+
  476.             | B | F | Synchronous  | Asynchronous   |
  477.             +---+---+--------------+----------------+
  478.             | 1 | 0 | Begin Frame  | Not Applicable |
  479.             +---+---+--------------+----------------+
  480.             | 0 | 0 | Middle Frame | Not Applicable |
  481.             +---+---+--------------+----------------+
  482.             | 1 | 0 | Final Frame  | Not Applicable |
  483.             +---+---+--------------+----------------+
  484.             | 1 | 1 | Single Frame | Required       |
  485.             +---+---+--------------+----------------+
  486.  
  487.  
  488.       CS (V.120 optional Header Extension for Control State Information)
  489.  
  490.          The format of the second Header octet (CS) is shown below:
  491.             0     1     2     3     4     5     6     7
  492.          +-----+-----+-----+-----+-----+-----+-----+-----+
  493.          |  E  | DR  | SR  | RR  | Res |(Odd-Pad Length) |
  494.          +-----+-----+-----+-----+-----+-----+-----+-----+
  495.  
  496.          E - Extension Bit
  497.  
  498.             The E bit is the extension bit, and allows further extension
  499.             of the Header field.  It is set to 1, to indicate no further
  500.             extension of the Header field.
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Schneider & Venters          Informational                      [Page 9]
  507.  
  508. RFC 1963                        PPP SDTP                     August 1996
  509.  
  510.  
  511.          DR - Data Ready
  512.  
  513.             This bit set to 1 indicates that the DTE port is activated.
  514.  
  515.          SR - Send Ready
  516.  
  517.             This bit set to 1 indicates that the DTE is ready to send
  518.             data.
  519.  
  520.          RR - Receive Ready
  521.  
  522.             This bit set to 1 indicates that the DTE is ready to receive
  523.             data.  It can be used for DTE flow control in half-duplex
  524.             transmissions.
  525.  
  526.          Res - Reserved
  527.  
  528.             This bit is reserved and set to 0. (This is a V.120 reserved
  529.             bit.)
  530.  
  531.          Odd-Pad Length (Optional)
  532.  
  533.             The Odd-Pad Length field is used when non-octet aligned HDLC
  534.             frames are allowed.  It is a 3-bit field, that can take on
  535.             the values of 0 through 7.  Its value is the length of the
  536.             Odd-Pad field in bits.  This value is determined as the
  537.             number of bits necessary to have the combined length of the
  538.             Transported Data Field and the Odd-Pad Field be aligned with
  539.             an octet boundary.
  540.  
  541.             If non-octet aligned frames are not allowed, this field is
  542.             not used and all bits are set to the value of 0.  (These
  543.             bits are reserved in V.120.)
  544.  
  545.    Transported Data
  546.  
  547.       The transported data field contains the transported serial data.
  548.  
  549.       When the serial data type has been negotiated to be HDLC-like
  550.       synchronous, this field will contain all or part of a transported
  551.       HDLC-like frame.
  552.  
  553.       A sample transported HDLC frame is shown below.  The figure does
  554.       not show bits inserted for transparency.
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Schneider & Venters          Informational                     [Page 10]
  563.  
  564. RFC 1963                        PPP SDTP                     August 1996
  565.  
  566.  
  567.        0                   1                   2                   3
  568.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  569.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  570.       | Flag:01111110 | (Address, Control and Information Fields) ...
  571.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  572.       |             (FCS)                                             |
  573.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+
  574.       | Flag:01111110 |
  575.       +-+-+-+-+-+-+-+-+
  576.  
  577.       Only the data between the flags is transported.  The flags are not
  578.       transported.  The FCS is tranported unless the FCS-Mode
  579.       Configuration Option has been successfully negotiated otherwise.
  580.  
  581.    Odd-Pad
  582.  
  583.       The optional Odd-Pad (Odd Frame Pad) field is used when the
  584.       transported data frame is non-octet aligned, and the Allow-Odd-
  585.       Frames Option has been successfully negotiated.  It contains the
  586.       bits that are required to pad the Transported Data field out to an
  587.       octet boundary.  The Odd-Pad field is in the high order bits of
  588.       the last octet of the Transported Data field.  The values of these
  589.       bits are all zero.
  590.  
  591. 3.  Serial Data Control Protocol
  592.  
  593.    The Serial Data Control Protocol (SDCP) is responsible for
  594.    configuring, enabling and disabling the SDTP modules on both ends of
  595.    the point-to-point link.  SDCP uses the same packet exchange
  596.    mechanism and state machine as the Link Control Protocol.  SDCP
  597.    packets may not be exchanged until PPP has reached the Network-Layer
  598.    Protocol phase.  SDCP packets received before this phase is reached
  599.    SHOULD be silently discarded.
  600.  
  601.    The Serial Data Control Protocol is exactly the same as the Link
  602.    Control Protocol [1] with the following exceptions:
  603.  
  604.    Frame Modifications
  605.  
  606.       The packet may utilize any modifications to the basic frame format
  607.       which have been negotiated during the Link Establishment phase.
  608.  
  609.    Data Link Layer Protocol Field
  610.  
  611.       Exactly one SDCP packet is encapsulated in the PPP Information
  612.       field, where the PPP Protocol field indicates type hex 8049 (PPP-
  613.       SDCP).
  614.  
  615.  
  616.  
  617.  
  618. Schneider & Venters          Informational                     [Page 11]
  619.  
  620. RFC 1963                        PPP SDTP                     August 1996
  621.  
  622.  
  623.    Code Field
  624.  
  625.       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  626.       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack,
  627.       and Code-Reject) are used.  other Codes SHOULD be treated as
  628.       unrecognized and SHOULD result in Code-Rejects.
  629.  
  630.    Timeouts
  631.  
  632.       SDCP packets may not be exchanged until PPP has reached the
  633.       Network-Layer Protocol phase.  An implementation SHOULD be
  634.       prepared to wait for Authentication and Link Quality Determination
  635.       to finish before timing out waiting for a Configure-Ack or other
  636.       response.  It is suggested that an implementation give up only
  637.       after user intervention or a configurable amount of time.
  638.  
  639.    Configuration Option Types
  640.  
  641.       SDCP has a distinct set of Configuration Options which are defined
  642.       in this document.
  643.  
  644. 4.  SDCP Configuration Option Format
  645.  
  646.    SDCP Configuration Options allow modifications to the default SDCP
  647.    characteristics to be negotiated.  If a Configuration Option is not
  648.    included in a Configure-Request packet, the default value for that
  649.    Configuration Option is assumed.
  650.  
  651.    SDCP uses the same Configuration Option format defined in LCP [1],
  652.    with a separate set of Options.
  653.  
  654.    The Option Types are:
  655.  
  656.       1   Packet-Format
  657.       2   Header-Type
  658.       3   Length-Field-Present
  659.       4   Multi-Port
  660.       5   Transport-Mode
  661.       6   Maximum-Frame-Size
  662.       7   Allow-Odd-Frames
  663.       8   FCS-Type
  664.       9   Flow-Expiration-Time
  665.  
  666.    Note that Option Types 5-8 are specific to a single port and require
  667.    port numbers in their format.  Option Types 6-8 are specific to the
  668.    HDLC-Synchronous Transport-Mode.
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Schneider & Venters          Informational                     [Page 12]
  675.  
  676. RFC 1963                        PPP SDTP                     August 1996
  677.  
  678.  
  679. 4.1.  Packet-Format
  680.  
  681.    This option selects whether the Header field precedes or follows the
  682.    data field.  When the Header field follows the data field, the order
  683.    of its octets are reversed.
  684.  
  685.     0                   1                   2
  686.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  687.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  688.    |     Type      |    Length     |     Format    |
  689.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  690.  
  691.    Type
  692.  
  693.       1
  694.  
  695.    Length
  696.  
  697.       3
  698.  
  699.    Format
  700.  
  701.       0   Header-Last   (default)
  702.       1   Header-First
  703.  
  704. 4.2.  Header-Type
  705.  
  706.    This option selects the type of the Header field.  The Header-Type of
  707.    H-and-CS means that the CS octet will be present if indicated by the
  708.    E-bit in the H-octet.  The Header-Type of H-and-CS-Always signifies
  709.    that both the H and CS octets are present in every packet.
  710.  
  711.     0                   1                   2
  712.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  713.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  714.    |     Type      |    Length     |  Header-Type  |
  715.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  716.  
  717.    Type
  718.  
  719.       2
  720.  
  721.    Length
  722.  
  723.       3
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Schneider & Venters          Informational                     [Page 13]
  731.  
  732. RFC 1963                        PPP SDTP                     August 1996
  733.  
  734.  
  735.    Header-Type
  736.  
  737.       0   H-Only (default)
  738.       1   H-and-CS
  739.       2   H-and-CS-Always
  740.  
  741. 4.3.  Length-Field-Present
  742.  
  743.    By default, a PPP Information Field contains only a single SDTP
  744.    packet, and an SDTP Packet does not contain a length field.
  745.    Successful negotiation of this option causes all SDTP packets to
  746.    contain the length field, and allows SDTP packets to be contained in
  747.    compound frames (see LCP Compound-Frames Configuration Option [11]).
  748.  
  749.    This option is required if the LCP Length-Field-Present Configuration
  750.    option has been negotiated.
  751.  
  752.    The size of the Length field is negotiated via the Length-Size
  753.    parameter.
  754.  
  755.     0                   1                   2
  756.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  757.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  758.    |     Type      |    Length     |  Length-Size  |
  759.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  760.  
  761.    Type
  762.  
  763.       3
  764.  
  765.    Length
  766.  
  767.       3
  768.  
  769.    Length-Size
  770.  
  771.       0   No Length Field (default)
  772.       1   Length field of 1 octet
  773.       2   Length field of 2 octets
  774.  
  775. 4.4.  Multi-Port
  776.  
  777.    By default, packets do not contain a port number and all packets are
  778.    sent to the default port, Port 0.  The Successful negotiation of the
  779.    Multi-Port configuration option means that every packet will contain
  780.    a port number.  The maximum port number, and hence the number of
  781.    ports, is negotiated by using the Max-Port-Num field.  A value of 0
  782.    specifies that a single port is to be used and no port field will be
  783.  
  784.  
  785.  
  786. Schneider & Venters          Informational                     [Page 14]
  787.  
  788. RFC 1963                        PPP SDTP                     August 1996
  789.  
  790.  
  791.    present in an SDTP packet.  (This is the same as not negotiating or
  792.    rejecting this option.) Port numbers begin with 0 and range to 254.
  793.    Port number 255 is reserved for control purposes (see section on flow
  794.    control).
  795.  
  796.    Protocol Specific negotiations which are on a per port basis, require
  797.    the port number to be specified as part of the configuration
  798.    negotiation.
  799.  
  800.     0                   1                   2
  801.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  802.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  803.    |     Type      |    Length     | Max-Port-Num  |
  804.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  805.  
  806.    Type
  807.  
  808.       4
  809.  
  810.    Length
  811.  
  812.       3
  813.  
  814.    Max-Port-Num
  815.  
  816.       The maximum port number that can be used.  The number of ports
  817.       present is Max-Port-Num + 1.  The value can range from 0 to 254.
  818.  
  819. 4.5.  Transport-Mode
  820.  
  821.    This parameter selects the mode of transport for the specified port.
  822.  
  823.     0                   1                   2                   3
  824.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  825.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  826.    |     Type      |    Length     |      Port     |     Mode      |
  827.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  828.  
  829.    Type
  830.  
  831.       5
  832.  
  833.    Length
  834.  
  835.       4
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Schneider & Venters          Informational                     [Page 15]
  843.  
  844. RFC 1963                        PPP SDTP                     August 1996
  845.  
  846.  
  847.    Port
  848.  
  849.       The port for which this option applies.
  850.  
  851.    Mode
  852.  
  853.       The transport mode to be used for this port.
  854.  
  855.          0   HDLC Synchronous (default)
  856.          1   Asynchronous
  857.  
  858. 4.6.  Maximum-Frame-Size
  859.  
  860.    This parameter specifies the maximum number of octets allowed in a
  861.    transported data frame.
  862.  
  863.     0                   1                   2                   3
  864.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  865.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  866.    |     Type      |    Length     |      Port     |
  867.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  868.    |                       Maximum-Frame-Size                      |
  869.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  870.  
  871.    Type
  872.  
  873.       6
  874.  
  875.    Length
  876.  
  877.       7
  878.  
  879.    Port
  880.  
  881.       The port for which this option applies.
  882.  
  883.    Maximum-Frame-Size
  884.  
  885.       The maximum allowed length of a transported data frame in octets.
  886.       Default is 10,000.  Negotiable range is 1 to 2**31 - 1. The value
  887.       0 is reserved to mean no limit.  This field is transmitted most
  888.       significant octet first.
  889.  
  890. 4.7.  Allow-Odd-Frames
  891.  
  892.    By default, only octet-aligned data frames are allowed for transport.
  893.    Successful negotiation of this option allows the transport of non-
  894.    octet aligned frames.  The size of the padding required to align the
  895.  
  896.  
  897.  
  898. Schneider & Venters          Informational                     [Page 16]
  899.  
  900. RFC 1963                        PPP SDTP                     August 1996
  901.  
  902.  
  903.    frames is carried in the CS Header octet.
  904.  
  905.    Use of Header-Type H-Only is not permitted in conjunction with this
  906.    option.
  907.  
  908.     0                   1                   2
  909.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  910.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  911.    |     Type      |    Length     |      Port     |
  912.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  913.  
  914.    Type
  915.  
  916.       7
  917.  
  918.    Length
  919.  
  920.       3
  921.  
  922.    Port
  923.  
  924.       The port for which this option applies.
  925.  
  926. 4.8.  FCS-Type
  927.  
  928.    By default, the transported data frame FCS is transported.  This
  929.    option allows the FCS to be removed by the transmitter and
  930.    regenerated by the receiver.
  931.  
  932.    It is important that implementations not use regeneration unless they
  933.    are using PPP Reliable Transmission [12] or operating over some other
  934.    layer that will provide reliable notification of a dropped packet.
  935.    Implementations are not permitted to send a incomplete or bad frame
  936.    to the user with a good (regenerated) FCS.
  937.  
  938.    This option also selects the type of user FCS that will be
  939.    regenerated.
  940.  
  941.     0                   1                   2                   3
  942.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  943.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  944.    |     Type      |    Length     |      Port     |    FCS-Type   |
  945.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  946.  
  947.    Type
  948.  
  949.       8
  950.  
  951.  
  952.  
  953.  
  954. Schneider & Venters          Informational                     [Page 17]
  955.  
  956. RFC 1963                        PPP SDTP                     August 1996
  957.  
  958.  
  959.    Length
  960.  
  961.       4
  962.  
  963.    Port
  964.  
  965.       The port for which this option applies.
  966.  
  967.    FCS-Type
  968.  
  969.          0   Transparent-Transport (Default)
  970.          1   16-bit ITU-T CRC
  971.          2   32-bit ITU-T CRC
  972.  
  973. 4.9.  Flow-Expiration-Time
  974.  
  975.    As described in section 2.2, Flow-Off messages expire after T1
  976.    seconds.  By default, T1 is 10 seconds.  This configuration option
  977.    allows the value of T1 to be changed.
  978.  
  979.     0                   1
  980.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  981.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  982.    |     Type      |    Length     |
  983.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  984.    |     Flow-Expiration-Time      |
  985.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  986.  
  987.    Type
  988.  
  989.       9
  990.  
  991.    Length
  992.  
  993.       5
  994.  
  995.    Flow-Expiration-Time
  996.  
  997.       The Flow-Expiration-Time field contains a 16 bit unsigned integer
  998.       which is used to specify the value to be assigned to T1 as
  999.       follows: T1 = Flow-Expiration-Time / 10 seconds.  Therefore this
  1000.       value is in units of 1/10 of a second, with allowable values from
  1001.       1 to 2^16-1 (0.1 to 6553.5 seconds).  It is transmitted most
  1002.       significant octet first.  The default value is 100 (10 seconds),
  1003.       which all must support.
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Schneider & Venters          Informational                     [Page 18]
  1011.  
  1012. RFC 1963                        PPP SDTP                     August 1996
  1013.  
  1014.  
  1015. Security Considerations
  1016.  
  1017.    Security issues are not discussed in this memo.
  1018.  
  1019. References
  1020.  
  1021.    [1]    Simpson, W., ed., "The Point-to-Point Protocol (PPP)", STD
  1022.           51, RFC 1661, July 1994.
  1023.  
  1024.    [2]    CCITT Recommendation V.120 (09/92), "Support by an ISDN of
  1025.           Data Terminal Equipment with V-Series Type Interfaces with
  1026.           Provision for Statistical Multiplexing", 1993.
  1027.  
  1028.    [3]    Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
  1029.           1962, June 1996.
  1030.  
  1031.    [4]    Friend, R., and W. Simpson, "PPP Stac LZS Compression
  1032.           Protocol", RFC 1974, August 1996.
  1033.  
  1034.    [5]    Rand, D., "PPP Predictor Compression Protocol", RFC 1978,
  1035.           August 1996.
  1036.  
  1037.    [6]    Petty, J., "PPP Hewlett-Packard Packet-by-Packet Compression
  1038.           (HP PPC) Protocol", Work in Progress.
  1039.  
  1040.    [7]    Carr, D., "PPP Gandalf FZA Compression Protocol", Work in
  1041.           Progress.
  1042.  
  1043.    [8]    Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
  1044.           August 1996.
  1045.  
  1046.    [9]    Schremp, et. al., "PPP Magnalink Variable Resource
  1047.           Compression", RFC 1975, August 1996.
  1048.  
  1049.    [10]   Schneider, K., "PPP Stacker LZS Compression Protocol using a
  1050.           DCP Header (LZS-DCP)", RFC 1967, August 1996.
  1051.  
  1052.    [11]   Simpson, W.A., "PPP LCP Extensions", RFC 1570, January 1994.
  1053.  
  1054.    [12]   Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Schneider & Venters          Informational                     [Page 19]
  1067.  
  1068. RFC 1963                        PPP SDTP                     August 1996
  1069.  
  1070.  
  1071. Chair's Address
  1072.  
  1073.    The working group can be contacted via the current chair:
  1074.  
  1075.    Karl Fox
  1076.    Ascend Communications
  1077.    3518 Riverside Drive, Suite 101
  1078.    Columbus, Ohio 43221
  1079.  
  1080.    EMail: karl@ascend.com
  1081.  
  1082. Authors' Addresses
  1083.  
  1084.    Questions about this memo should be directed to:
  1085.  
  1086.    Kevin Schneider
  1087.    Adtran, Inc.
  1088.    901 Explorer Blvd.
  1089.    Huntsville, AL 35806-2807
  1090.  
  1091.    Phone: (205) 971-8000
  1092.    EMail:  kevin@adtran.com
  1093.  
  1094.  
  1095.    Stuart Venters
  1096.    Adtran, Inc.
  1097.    901 Explorer Blvd.
  1098.    Huntsville, AL 35806-2807
  1099.  
  1100.    Phone: (205) 971-8000
  1101.    EMail: sventers@adtran.com
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Schneider & Venters          Informational                     [Page 20]
  1123.  
  1124.