PPP Working Group                                             J. Carlson
Internet Draft                                       IronBridge Networks
Updates RFC 1619                                              P. Langner
expires in six months         Lucent Technologies Microelectronics Group
                                                           J. Manchester
                                                     Lucent Technologies
                                                           November 1998

                    PPP over Simple Data Link (SDL)
                 using SONET/SDH with ATM-like framing

Status of this Memo

   This document is the product of the Point-to-Point Protocol
   Extensions 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.

   This document is an Internet-Draft.  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 inappropriate to use Internet-
   Drafts as reference material or to cite them other than as "work in

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Carlson, et al.             expires May 1999                    [Page 1]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998


   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links, and
   RFCs 1662 [2] and 1619 [3] provide a means to carry PPP over
   Synchronous Optical Network (SONET) [5] and Synchronous Digital
   Hierarchy (SDH) [6] circuits.  This document extends these standards
   to include a new encapsulation for PPP called Simple Data Link (SDL)
   [7].  SDL provides a very low overhead alternative to standard HDLC
   encapsulation for SONET/SDH links.

   This document is the product of 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.


   This specification is intended for those implementations which desire
   to use the PPP encapsulation over high speed point-to-point circuits,
   both with so-called "dark fiber" and over public telecommunications
   networks.  Because this enhanced PPP encapsulation has very low
   overhead, it is anticipated that significantly higher throughput can
   be attained compared to other SONET/SDH payload mappings, at a
   significantly lower cost for line termination equipment.

Carlson, et al.             expires May 1999                    [Page 2]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

Table of Contents

   1.         Introduction ........................................    4
   2.         Physical Layer Requirements .........................    4
      2.1.    Payload Types .......................................    4
      2.2.    Control Signals .....................................    5
      2.3.    Synchronization Modes ...............................    6
      2.4.    Simple-Data-Link LCP Option .........................    6
      2.5.    Framing .............................................    7
      2.6.    Synchronization Procedure ...........................    9
      2.7.    Scrambler Operation .................................   10
      2.8.    CRC Generation ......................................   11
      2.9.    Error Correction ....................................   12
   3.         Performance Analysis ................................   13
      3.1     Mean Time To Frame (MTTF) ...........................   13
      3.2     Mean Time To Synchronization (MTTS) .................   14
      3.3     Probability of False Frame (PFF) ....................   15
      3.4     Probability of False Synchronization (PFS) ..........   15
      3.5     Probability of Loss of Frame (PLS) ..................   15
   4.         Configuration Details ...............................   15
   APPENDICES .....................................................   16
      A.      CRC Generation ......................................   16
      B.      Error Correction Tables .............................   18
   5.         Security Considerations .............................   20
   6.         References ..........................................   20
   7.         Acknowledgments .....................................   20
   8.         Working Group and Chair Address .....................   21
   9.         Authors' Addresses ..................................   21

Carlson, et al.             expires May 1999                    [Page 3]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

1.  Introduction

   The Path Signal Label (SONET/SDH overhead byte named C2; referred to
   as PSL in this document) is intended to indicate the type of data
   carried on the path.  This data, in turn, is referred to as the SONET
   Synchronous Payload Envelope (SPE) or SDH Administrative Unit Group
   (AUG).  The experimental PSL value of decimal 207 (CF hex) is
   currently [3] used to indicate that the SPE contains PPP framed using
   RFC 1662 Octet Synchronous (O-S) framing and transmission without
   scrambling, and the value 22 (16 hex) is used to indicated PPP framed
   using O-S framing and transmission with ATM-style X^43+1 scrambling.

   This document describes a method to enable the use of SDL framing for
   PPP over SONET/SDH, and describes the framing technique and require-
   ments for PPP.  While O-S framing has a worst-case octet overhead of
   100% of all data octets transmitted, SDL has a fixed eight octet per
   frame overhead with zero data overhead.  This mapping is similar to
   the earlier "Ether-like Framing" proposal, found in a separate work-
   in-progress.  [4]

   SDL is being submitted by Lucent, IronBridge, and others to ANSI sub-
   committee T1A1.5 for eventual international telecommunications stan-
   dardization.  Also, a Bellcore Digest article on SDL will appear in

   Note:  This document describes a new PSL value 23 (17 hex).  This
   value has not been allocated by any applicable standards body, and
   SDL must not be used on public networks until a standard value is
   allocated.  A joint contribution will be made to ANSI subcommittee
   T1X1.5 requesting the assignment of 17 hex as a PSL for an SDL over
   SONET mapping in T1.105.

2.  Physical Layer Requirements

   PPP treats SONET/SDH transport as octet-oriented synchronous links.
   No provision is made to transmit partial octets.  Also, SONET/SDH
   links are full-duplex by definition.

2.1.  Payload Types

   Only synchronous payloads STS-1 and higher are considered in this
   document.  Plesiochronous payload mappings, such as T1 and T3, are
   defined for SONET/SDH and for SDL, but, since standard HDLC is
   defined for PPP on those media, PPP over SDL is not defined.
   "Packet-over-fiber" mode is also defined for SDL, but is for future
   study in PPP.

Carlson, et al.             expires May 1999                    [Page 4]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

2.2.  Control Signals

   The PPP over SONET/SDH mapping allows the use of the PSL as a control
   signal.  Not all equipment, however, is capable of setting or detect-
   ing this value, and any standard must take this into account.  Equip-
   ment employing only SDL MUST be capable of transmitting PSL with
   value 23, but need not be capable of detecting the peer's value or
   capable of changing its own value.

   There are two methods to enable SDL, an LCP-negotiated method and a
   prior-arrangement method.  The former allows for easier configuration
   and compatibility with existing equipment, while the latter allows
   general use with separate SONET/SDH transmission equipment with PSL
   limitations.  Both types of implementations will freely interoperate
   given the procedures below.

   LCP-negotiated systems MUST be capable of changing their transmitted
   PSL value and detecting the peer's value.  Equipment without these
   features MUST NOT support LCP negotiation of SDL.

   When SDL is negotiated by LCP, LCP negotiation MUST be started with
   the PSL value initially set to 22 or 207 and the corresponding non-
   SDL O-S PPP encapsulation MUST be used.  The SDL LCP option is then
   placed in the LCP Configure-Request messages transmitted.  On recep-
   tion of LCP Configure-Request with an SDL LCP option or when the
   peer's transmitted PSL value is received as 23, the implementation
   MUST shut down LCP by sending a Down event to its state machine, then
   switch its transmitted PSL value to 23, switch encapsulation mode to
   SDL, wait for SDL synchronization, and then restart LCP by sending an
   Up event into LCP.  Otherwise, if the peer does not transmit PSL
   value 23 and it does not include the SDL LCP option in its LCP
   Configure-Request messages, then operation using non-SDL O-S PPP
   encapsulation continues.  If the received PSL value subsequently
   received reverts from 23 to any other value, then this is treated as
   a Down event into the LCP state machine, and an Up event MUST be gen-
   erated if the new value is recognized as a valid PPP framing mode.

   When SDL is enabled by prior arrangement, the PSL SHOULD be transmit-
   ted as 23.  Any other value may also be used by prior external
   arrangement with the peer, although the values 22 and 207 are
   discouraged.  (Such use is enforced by an administrator, and is out-
   side the scope of this specification.)  When SDL is enabled by prior
   arrangement, the SDL LCP option SHOULD NOT be negotiated by the

   An implementation-specific configuration option SHOULD exist to
   enable the use of prior-arrangement versus LCP-negotiated modes.
   This option SHOULD be presented to an administrator, and SHOULD

Carlson, et al.             expires May 1999                    [Page 5]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   default to LCP-negotiated if the hardware permits.  Otherwise, if the
   hardware implementation precludes non-SDL modes of operation, then it
   MUST default to prior-arrangement mode.

2.3.  Synchronization Modes

   Unlike O-S encapsulation, SDL provides a positive indication that it
   has achieved synchronization with the peer.  An SDL PPP implementa-
   tion MUST provide a means to temporarily suspend PPP data transmis-
   sion (both user data and negotiation traffic) if synchronization loss
   is detected.  An SDL PPP implementation SHOULD also provide a confi-
   gurable timer that is started when SDL is initialized and restarted
   on the loss of synchronization.  If this timer expires,
   implementation-dependent action should be taken to report the
   hardware failure.

2.4.  Simple-Data-Link LCP Option

   A new LCP Configuration Option is used to request Simple Data Link
   (SDL) [7] operation for the PPP link.

   A summary of the Simple-Data-Link Configuration Option format for the
   Link Control Protocol (LCP) is shown below.  The fields are transmit-
   ted from left to right.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   |     Type      |    Length     |





   This option is used only as a hint to the peer that SDL operation is
   preferred by the sender.  If the current encapsulation mode is not
   SDL, then the only appropriate response to reception of this option
   by an SDL speaker is to then switch the encapsulation mode to SDL (as
   detailed in the section above) and restart LCP.  Non SDL-speakers
   SHOULD instead send LCP Configure-Reject for the option.

Carlson, et al.             expires May 1999                    [Page 6]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   If either LCP Configure-Nak or LCP Configure-Reject is received for
   this option, then the next transmitted LCP Configure-Request MUST NOT
   include this option.  If LCP Configure-Ack with this option is
   received, it MUST NOT be treated as a request for SDL mode.  If the
   received LCP Configure-Request message does not contain an SDL LCP
   option, an implementation SHOULD NOT send an unsolicited Configure-
   Nak for the option.

   (An implementation of SDL that is already in SDL framing mode and
   receives this option in an LCP Configure-Request message MAY, both
   for clarity and for convergence reasons, elect to send LCP
   Configure-Ack.  It MUST NOT restart LCP nor change framing modes in
   this case.)

2.5.  Framing

   The PPP frames are located by row within the SPE payload.  Because
   frames are variable in length, the frames are allowed to cross SPE
   boundaries.  Bytes marked as "overhead" or "fixed stuff" in SONET/SDH
   documentation for concatenated streams are not used as payload bytes.

   When SDL framing for PPP is employed, the SDL "Datagram Offset" is
   fixed at 4, and the "A" and "B" messages are never used.  These
   optional features of SDL are not described in this document, but are
   rather described in Lucent's SDL specification [7].

   Fixing the Datagram Offset to 4 allows a PPP MRU/MTU of 65536 using

   SDL framing is in general accomplished by the use of a four octet
   header on the packet.  This fixed-length header allows the use of a
   simple framer to detect synchronization as described in section 2.6.
   For use with PPP, this header precedes each raw PPP packet as fol-

    0                   1                   2                   3
    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
   |         Packet Length         |          Header CRC           |
   |     PPP packet (beginning with address and control fields)    |
   |                             .....                             |
   |                           Packet CRC                          |

Carlson, et al.             expires May 1999                    [Page 7]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   The four octet length header is DC balanced by exclusive-OR (also
   known as "modulo 2 addition") with the hex value B6AB31E0.  This is
   the maximum transition, minimum sidelobe, Barker-like sequence of
   length 32.  No other scrambling is done on the header itself.

   Packet Length is an unsigned 16 bit number in network byte order.
   Unlike the standard PPP FCS, the Header CRC is a CRC-16 generated
   with initial value zero and transmitted in standard network byte
   order.  The PPP packet is scrambled, and begins with the standard
   address and control fields, and may be any integral octet length
   (i.e., it is not padded unless the Self Describing Padding option is
   used).  The Packet CRC is also scrambled, and has a mode-dependent
   length (described below), and is located only on an octet boundary;
   no alignment of this field may be assumed.

   When the Packet Length value is 4 or greater, the distance in octets
   between one message header and the next in SDL is the sum of Packet
   Length field, Datagram Offset value, and the fixed size of the Packet
   CRC field.  The Datagram Offset is a configurable SDL parameter,
   which is set to the fixed value 4 for PPP.  When the Packet Length is
   0, the distance to the next header is 4 octets.  This is the idle
   fill header.  When the Packet Length is 1 to 3, the distance to the
   next header is 12 octets.  These headers are used for special SDL
   messages described below.

   General SDL, like PPP, allows the use of no CRC, ITU-T CRC-16, or
   ITU-T CRC-32 for the packet data.  However, because the Packet Length
   field does not include the CRC length, synchronization cannot be
   maintained if the CRC type is changed per RFC 1570, because frame-
   to-frame distance is, as described above, calculated including the
   CRC length.  Thus, this PPP over SDL specification fixes the CRC type
   to CRC-32 (four octets), and all SDL implementations MUST reject any
   LCP FCS Alternatives Option [8] requested by the peer when in SDL

   PPP over SDL implementations MAY allow a configuration option to set
   different CRC types for use by prior arrangement.  Any such configur-
   able option MUST default to CRC-32, and MUST NOT be include LCP nego-
   tiation of FCS Alternatives.

   With the SDL Datagram Offset set to 4, the value placed in the Packet
   Length field is exactly the length in octets of the PPP frame itself,
   including the address and control fields but not including the FCS

   Because Packet Lengths below 4 are reserved, the Packet Length MUST
   be 4 or greater for any legal PPP packet.  PPP packets with fewer
   octets, which are not possible without address/control or protocol

Carlson, et al.             expires May 1999                    [Page 8]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   field compression, MUST be padded to length 4 for SDL.

   Inter-packet time fill is accomplished by sending the four octet
   length header with the Packet Length set to zero.  No provision is
   made for intra-packet time fill.

   All octets in the PPP packet data following the SDL header through
   the final packet CRC are scrambled using an x^48+x^28+x^27+x+1
   independent scrambler initialized to all ones.  The scrambler is
   reset to all ones if the shift register ever contains all zeros.

   The special value of 1 for Packet Length is reserved to transfer the
   scrambler state from the transmitter to the receiver.  In this case,
   the SDL header is followed by six octets (48 bits) of scrambler state
   plus two octets of CRC-16 over the scrambler state.  None of these
   eight octets are scrambled.

   The special values of 2 and 3 for Packet Length are reserved for "A"
   and "B" messages, which are also six octets in length followed by two
   octets of CRC-16.  Each of these eight octets are scrambled.  No use
   for these messages with PPP SDL is defined.

2.6.  Synchronization Procedure

   SDL synchronization consists of two components, link and scrambler
   synchronization.  Both must be completed before PPP data flows on the

   The link synchronization procedure is similar to the I.432 section ATM HEC delineation procedure [9], but simpler because the
   SDL messages are variable length.  The machine starts in HUNT state
   until a four octet sequence in the data stream with a valid CRC-16 is
   found.  (Note that the CRC-16 single-bit error correction technique
   described in section 2.9 is not employed until the machine is in in
   SYNC state.)  Such a valid sequence is a candidate SDL header.  On
   finding the valid sequence, the machine enters PRESYNCH state.  Any
   one invalid SDL header in PRESYNC state returns the link to HUNT

   If a valid SDL header is seen in PRESYNCH state, then the link enters
   SYNCH state, and the scrambler synchronization sequence is started.
   If an invalid SDL header is detected, then the link is returned to
   HUNT state, and PPP transmission is suspended.

   When scrambler synchronization is started, a scrambler state message
   is sent (Packet Length set to 1 and six octets of scrambler state in
   network byte order follow the SDL header).  This message is sent

Carlson, et al.             expires May 1999                    [Page 9]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   once.  At this point, PPP transmission is enabled.

   Scrambler state messages are periodically transmitted to keep the
   peers in synchronization.  A period of once per eight transmitted
   packets is suggested, and it SHOULD be configurable.  Excessive
   packet CRC errors detected indicates an extended loss of synchroniza-
   tion and should trigger link resynchronization.

   On reception of a scrambler state message, an SDL implementation MUST
   compare the received 48 bits of state with the receiver's scrambler
   state.  If any of these bits differ, then a synchronization slip
   error is declared.  After such an error, the next valid scrambler
   state message received MUST be loaded into the receiver's scrambler,
   and the error condition is then cleared.

2.7.  Scrambler Operation

   The transmit and receive scramblers are shift registers with 48
   stages that are initialized to all-ones when the link is initialized.
   Each is refilled with all one bits if the value in the shift register
   ever becomes all zeros.  This scrambler is not reset at the beginning
   of each frame, as is the SONET/SDH X^7+X^6+1 scrambler, nor is it
   modified by the transmitted data, as is the ATM self-synchronous
   scrambler.  Instead it is kept in synchronization using special SDL

    |     ^                 ^      ^                  |
    |     |                 |      |                  |
    +->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+

   Each XOR is an exclusive-or gate; also known as a modulo-2 adder.
   Each Dn block is a D-type flip-flop clocked on the appropriate data

   The scrambler is clocked once after transmission of each bit of SDL
   data, whether or not the transmitted bit is scrambled.  When scram-
   bling is enabled for a given octet, the OUT bit is exclusive-ored
   with the raw data bit to produce the transmitted bit.  Bits within an
   octet are transmitted MSB-first.

   Reception of scrambled data is identical to transmission.  Each
   received bit is exclusive-ored with the output of the separate
   receive data scrambler.

Carlson, et al.             expires May 1999                   [Page 10]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   To generate a scrambler state message, the contents of D47 through D0
   are snapshot at the point where the first scrambler state bit is
   sent.  D47 is transmitted as the first bit of the output.  The first
   octet transmitted contains D47 through D40, the second octet D39
   through D32, and the sixth octet D7 through D0.

   The receiver of a scrambler state message MUST first run the CRC-16
   check and correct algorithm over this message.  If the CRC-16 message
   check detects multiple bit errors, then the message is dropped and is
   not processed further.

   Otherwise, it then should compare the contents of the entire receive
   scrambler state D47:D0 with the corrected message.  (By pipelining
   the receiver with multiple clock stages between SDL Header error-
   correction block and the descrambling block, the receive descrambler
   will be on the correct clock boundary when the message arrives at the
   descrambler.  This means that the decoded scrambler state can be
   treated as immediately available at the beginning of the D47 clock
   cycle into the receive scrambler.)

   If any of the received scrambler state bits is different from the
   corresponding shift register bit, then a soft error flag is set.  If
   the flag was already set when this occurs, then a synchronization
   slip error is declared.  This error SHOULD be counted and reported
   through implementation-defined network management procedures.  When
   the receiver has this soft error flag set, any scrambler state mes-
   sage that passes the CRC-16 message check without multiple bit errors
   is clocked directly into the receiver's state register after the com-
   parison is done, and the soft error flag is then cleared.  Otherwise,
   while uncorrectable scrambler state messages are received, the soft
   error flag state is maintained.

   (The intent of this mechanism is to reduce the likelihood that a
   falsely corrected scrambler state message with multiple bit errors
   can corrupt the running scrambler state.)

2.8.  CRC Generation

   The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-T
   standard polynomials [10].  These are:



   The SDL Header CRC and the CRC-16 used for each of the three special
   messages (scrambler state, message A, and message B) are all

Carlson, et al.             expires May 1999                   [Page 11]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   generated using an initial remainder value of 0000 hex.

   The optional CRC-16 on the payload data (this mode is not used with
   PPP over SDL) uses the standard initial remainder value of FFFF hex
   for calculation and the bits are complemented before transmission.
   The final CRC remainder, however, is transmitted in network byte
   order, unlike the regular PPP FCS.  If the CRC-16 algorithm is run
   over all of the octets including the appended CRC itself, then the
   remainder value on intact packets will always be E2F0 hex.  Alterna-
   tively, an implemenation may stop CRC calculation before processing
   the appended CRC itself, and do a direct comparison.

   The standard CRC-32 on the payload data (used for PPP over SDL) uses
   the initial remainder value of FFFFFFFF hex for calculation and the
   bits are complemented before transmission.  The CRC, however, is
   transmitted in network byte order, unlike the optional PPP 32 bit
   FCS.  The remainder value on intact packets when the appended CRC
   value is included in the calculation is 38FB2284.

   C code to generate these CRCs is found in Appendix A.

2.9.  Error Correction

   The error correction technique is based on the use of a Galois number
   field, as with the ATM HEC correction.  In a Galois number field,
   f(a+b) = f(a) + f(b).  Since the CRC-16 used for SDL forms such a
   field, we can state that CRC(message+error) = CRC(message) +
   CRC(error).  Since the SDL CRC-16 of a properly formed message is
   always zero, this means that, for the N distinct "error" strings
   corresponding to a single bit error, there are N distinct CRC(error)
   values, where N is the number of bits in the message.

   A table look-up is thus applied to the CRC-16 residue after calcula-
   tion over the four octet SDL header to correct bit errors in the
   header and to detect multiple bit errors.  A table look-up is simi-
   larly applied to the CRC-16 residue after calculation over the eight
   octet scrambler state message to correct bit errors and to detect
   multiple bit errors.  (This second correction is also used for the
   special SDL A and B messages, which are not used for PPP over SDL.)

   Note:  This error correction technique is used only when the link has
   entered synchronization state.  While hunting for SDL framing and
   when in PRESYNC state, error correction should not be performed, and
   only messages with syndrome 0000 are accepted.

   Since the CRC calculation is started with zero, the two tables can be
   merged.  The four octet table is merely the last 32 entries of the

Carlson, et al.             expires May 1999                   [Page 12]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   eight octet table.

   Eight octet (64 bit) single bit error syndrome table (in hex):

     FD81 F6D0 7B68 3DB4 1EDA 0F6D 8FA6 47D3
     ABF9 DDEC 6EF6 377B 93AD C1C6 60E3 B861
     D420 6A10 3508 1A84 0D42 06A1 8B40 45A0
     22D0 1168 08B4 045A 022D 8906 4483 AA51
     DD38 6E9C 374E 1BA7 85C3 CAF1 ED68 76B4
     3B5A 1DAD 86C6 4363 A9A1 DCC0 6E60 3730
     1B98 0DCC 06E6 0373 89A9 CCC4 6662 3331
     9188 48C4 2462 1231 8108 4084 2042 1021

   Thus, if the syndrome 6EF6 is seen on an eight octet message, then
   the third bit (hex 20) of the second octet is in error.  Similarly,
   if 48C4 is seen on an eight octet message, then the second bit (hex
   40) in the eighth octet is in error.  For a four octet message, the
   same two syndromes would indicate a multiple bit error for 6EF6, and
   a single bit error in the second bit of the fourth octet for 48C4.

   Corresponding C code to generate this table is found in Appendix B.

3.  Performance Analysis

   There are five general statistics that are important for framing
   algorithms.  These are:

     MTTF   Mean time to frame
     MTTS   Mean time to synchronization
     PFF    Probability of false frame
     PFS    Probability of false synchronization
     PLF    Probability of loss of frame

   The following sections summarize each of these statistics for SDL.
   Details and mathematic development can be found in the Lucent SDL
   documentation [7].

3.1.  Mean Time To Frame (MTTF)

   This metric measures the amount of time required to discover correct
   framing in the input data.  This may be measured in any convenient
   units, such as seconds or bytes.  For SDL, the relevant measurement
   is in packets, since fragments of packets are not useful.

   In order to calculate MTTF, we must first determine how often the
   frame detection state machine is "unavailable" because it has

Carlson, et al.             expires May 1999                   [Page 13]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   detected an apparent framing header within the user data.

   Since the probability of a false header detection using CRC-16 in
   random data is 2^-16 and this rate is large compared to the allowable
   packet size, it is worthwhile to run multiple parallel frame-
   detection state machines.  Each machine starts with a different can-
   didate framing point in order to reduce the probability of falsely
   detecting user data as a valid frame header.

   The results for this calculation, given maximal 64KB packets and
   average 384 byte packets, are:

     Number of  Unavailability  Unavailability
      Framers    64KB packets   384 byte pkts
         1         367.9E-3        5.373E-3
         2         30.83E-3        1.710E-6
         3         2.965E-3        971.2E-12
         4         253.2E-6        465.3E-15

   Using these values, MTTF can be calculated as a function of the Bit
   Error Rate (BER).  These plots show a characteristically flat region
   for all BERs up to a knee, beyond which the begins to rise sharply.
   In all cases, this knee point has been found to occur at a BER of
   approximately 1E-4, which is several orders of magnitude above that
   observed on existing SONET/SDH links.  The flat rate values are sum-
   marized as:

     Number of  Flat region   Flat region
      Framers   64KB packets   384 bytes
         1         3.58          1.52
         2         1.595         1.5
         3         1.52          1.5
         4         1.5           1.5

   Thus, for common packet sizes in an implementation with two parallel
   framers using links with a BER of 1E-4 or better, the MTTF is approx-
   imately 1.5 packets.  This is also the optimal time, since it
   represents initiating framing at an average point half-way into one
   packet, and achieving good framing after seeing exactly one correctly
   framed packet.

3.2.  Mean Time To Synchronization (MTTS)

   The MTTS for SDL is one half of the scrambling state transmission
   interval (in packets) plus the MTTF.  For insertion at the default
   rate of one per eight packets, the MTTS is 5.5 packets.

Carlson, et al.             expires May 1999                   [Page 14]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

   (The probability of receiving a bad scrambling state transmission
   should also be included in this calculation.  The probability of ran-
   dom corruption of this short message is shown in the SDL document [7]
   to be small enough that it can be neglected for this calculation.)

3.3.  Probability of False Frame (PFF)

   The PFF is 232.8E-12 (2^-32), since false framing requires two con-
   secutive headers with falsely correct CRC-16.

3.4.  Probability of False Synchronization (PFS)

   The PFS is 54.21E-21 (2^-64), and is calculated as the PFF above mul-
   tiplied by the probability of a falsely detected scrambler state mes-
   sage, which itself contains two independent CRC-16 calculations.

3.5.  Probability of Loss of Frame (PLS)

   The PLS is a function of the BER, and for SDL is approximately BER
   multiplied by .005, which is the probability of two or more bit
   errors occurring within the 32 bit SDL header.  Thus, at a BER of
   1E-5, the PLS is 5E-8.

4.  Configuration Details

   The standard LCP synchronous configuration defaults apply to
   SONET/SDH links.

   The following Configuration Options are recommended:

      Magic Number
      No Address and Control Field Compression
      No Protocol Field Compression
      No FCS alternatives (32-bit FCS default)

Carlson, et al.             expires May 1999                   [Page 15]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

Appendix A:  CRC Generation

   The following unoptimized code generates proper CRC-16 and CRC-32
   values for SDL messages.  Note that the polynomial bits are numbered
   in big-endian order for SDL CRCs; bit 0 is the MSB.

     typedef unsigned char u8;
     typedef unsigned short u16;
     typedef unsigned long u32;

     #define POLY16  0x1021
     #define POLY32  0x04C11DB7

     crc16(u16 crcval, u8 cval)
         int i;

         crcval ^= cval << 8;
         for (i = 8; i--; )
             crcval = crcval & 0x8000 ? (crcval << 1) ^ POLY16 :
                 crcval << 1;
         return crcval;

     crc32(u32 crcval, u8 cval)
         int i;

         crcval ^= cval << 24;
         for (i = 8; i--; )
             crcval = crcval & 0x80000000 ? (crcval << 1) ^ POLY32 :
                 crcval << 1;
         return crcval;

     crc16_special(u8 *buffer, int len)
         u16 crc;

         crc = 0;
         while (--len >= 0)
             crc = crc16(crc,*buffer++);
         return crc;

Carlson, et al.             expires May 1999                   [Page 16]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

     crc16_payload(u8 *buffer, int len)
         u16 crc;

         crc = 0xFFFF;
         while (--len >= 0)
             crc = crc16(crc,*buffer++);
         return crc ^ 0xFFFF;

     crc32_payload(u8 *buffer, int len)
         u32 crc;

         crc = 0xFFFFFFFFul;
         while (--len >= 0)
             crc = crc32(crc,*buffer++);
         return crc ^ 0xFFFFFFFFul;

     make_sdl_header(int packet_length, u8 *buffer)
         u16 crc;

         buffer[0] = (packet_length >> 8) & 0xFF;
         buffer[1] = packet_length & 0xFF;
         crc = crc16_special(buffer,2);
         buffer[0] ^= 0xB6;
         buffer[1] ^= 0xAB;
         buffer[2] = ((crc >> 8) & 0xFF) ^ 0x31;
         buffer[3] = (crc & 0xFF) ^ 0xE0;

Carlson, et al.             expires May 1999                   [Page 17]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

Appendix B:  Error Correction Tables

   To generate the error correction table, the following implementation
   may be used.  It creates a table called sdl_error_position, which is
   indexed on CRC residue value.  The tables can be used to determine if
   no error exists (table entry is equal to FE hex), one correctable
   error exists (table entry is zero-based index to errored bit with MSB
   of first octet being 0), or more than one error exists, and error is
   uncorrectable (table entry is FF hex).  To use for eight octet mes-
   sages, the bit index from this table is used directly.  To use for
   four octet messages, the index is treated as an unrecoverable error
   if it is below 32, and as bit index plus 32 if it is above 32.

   The program also prints out the error syndrome table shown in section
   2.9.  This may be used as part of a "switch" statement in a hardware

       u8 sdl_error_position[65536];

       /* Calculate new CRC from old^(byte<<8) */
       crc16_t8(u16 crcval)
           u16 f1,f2,f3;

           f1 = (crcval>>8) | (crcval<<8);
           f2 = (crcval>>12) | (crcval&0xF000) | ((crcval>>7)&0x01E0);
           f3 = ((crcval>>3) & 0x1FE0) ^ ((crcval<<4) & 0xF000);
           return f1^f2^f3;

       generate_error_table(u8 *bptab, int nbytes)
           u16 crc;
           int i, j, k;

           /* Marker for no error */
           bptab[0] = 0xFE;

           /* Marker for >1 error */
           for (i = 1; i < 65536; i++ )
               bptab[i] = 0xFF;

           /* Mark all single bit error cases. */
           printf("Error syndrome table:\n");
           for (i = 0; i < nbytes; i++) {
               putchar(' ');

Carlson, et al.             expires May 1999                   [Page 18]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

               for (j = 0; j < 8; j++) {
                   crc = 0;
                   for (k = 0; k < i; k++)
                         crc = crc16_t8(crc);
                   crc = crc16_t8(crc ^ (0x8000>>j));
                   for (k++; k < nbytes; k++)
                         crc = crc16_t8(crc);
                   bptab[crc] = (i * 8) + j;
                   printf(" %04X",crc);

       main(int argc, char **argv)
           u8 buffer[8] = {
           u16 crc;
           int i;


           /* Run sample message through check routine. */
           crc = 0;
           for (i = 0; i < 8; i++)
               crc = crc16_t8(crc ^ (buffer[i]<<8));

           /* Output is 0000 64 -- no error encountered. */
           printf("\nError test:  CRC %04X, bit position %d\n",

Carlson, et al.             expires May 1999                   [Page 19]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

5.  Security Considerations

   The reliability of public SONET/SDH networks depends on well-behaved
   traffic which does not disrupt the synchronous data recovery mechan-
   isms.  This document describes framing and scrambling options that
   are used to ensure the distribution of transmitted data such that
   SONET/SDH design assumptions are not likely to be violated.

6.  References

      [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)," RFC
            1661, Daydreamer, July 1994.

      [2]   Simpson, W., Editor, "PPP in HDLC-like Framing," RFC 1662,
            Daydreamer, July 1994.

      [3]   Simpson, W., Editor, "PPP over SONET/SDH," RFC 1619, Daydreamer,
            May 1994.

      [4]   Simpson, W., "PPP in Ether-like Framing," Daydreamer, work in

      [5]   "American National Standard for Telecommunications -
            Synchronous Optical Network (SONET) Payload Mappings," ANSI
            T1.105.02-1993 draft.

      [6]   ITU-T Recommendation G.707, "Synchronous Digital Hierarchy Bit
            Rates," June 1992.

      [7]   Lucent Technologies, "SDL Framer/Frame Inserter," work in

      [8]   Simpson, W., Editor, "PPP LCP Extensions," RFC 1570, Daydreamer,
            January 1994.

      [9]   ITU-T Recommendation I.432, "B-ISDN User-Network Interface -
            Physical Layer Specification," March 1993.

      [10]  ITU-T Recommendation V.41, "Code-independent error-control
            system," November 1989.

7.  Acknowledgments

   PPP over SONET was first proposed by Craig Partridge (BBN), and was
   last documented by William Simpson as RFC 1619.  Much of the material
   in this document was supplied by Lucent.

Carlson, et al.             expires May 1999                   [Page 20]

INTERNET DRAFT            PPP SDL on SONET/SDH             November 1998

8.  Working Group and Chair Address

   The working group can be contacted via the mailing list (ietf-
   ppp@merit.edu; send mail to ietf-ppp-request@merit.edu to subscribe),
   or via the current chair:

     Karl Fox
     Ascend Communications
     655 Metro Place South Suite 370
     Dublin OH  43017-3390

     Email:  karl@ascend.com

9.  Authors' Addresses

     James Carlson
     IronBridge Networks
     55 Hayden Avenue
     Lexington MA  02421-7996

     Phone:  +1 781 372 8132
     Fax:    +1 781 372 8190
     Email:  carlson@ibnets.com

     Paul Langner
     Lucent Technologies Microelectronics Group
     555 Union Boulevard
     Allentown PA  18103-1286
     Email:  plangner@lucent.com

     James Manchester
     Lucent Technologies
     101 Crawford Corners Rd.
     Holmdel NJ  07733-3030
     Email:  sterling@hotair.hobl.lucent.com

Carlson, et al.             expires May 1999                   [Page 21]