[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                           W A Simpson [DayDreamer]
Internet Draft
expires in six months                                        August 1998


                           PPP over SONET/SDH
                   draft-ietf-pppext-sonet-ds-01.txt


Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Northern Europe)
      ftp.nis.garr.it (Southern Europe)
      ftp.ietf.org (Eastern USA)
      ftp.isi.edu (Western USA)
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) William Allen Simpson (1993-1994, 1997-1998).  All
   Rights Reserved.

Abstract

   The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard
   method for transporting multi-protocol datagrams over point-to-point
   links.  This document describes the use of PPP over Synchronous Opti-
   cal Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits.





Simpson                   expires in six months                 [Page i]


DRAFT                      PPP over SONET/SDH                August 1998


1.  Introduction

   PPP was designed as a standard method of communicating over point-to-
   point links.  Initial deployment has been over short local lines,
   leased lines, and plain-old-telephone-service (POTS) using modems.
   As new packet services and higher speed lines are introduced, PPP is
   easily deployed in these environments as well.

   The Synchronous Optical Network [SONET] is a time division multiplex-
   ing scheme that defines a family of standard rates and formats.
   Despite the name, it is not limited to optical links.  The ITU-T Syn-
   chronous Digital Hierarchy (SDH) attempts to internationalize SONET
   to provide interworking beteen networks based on different ple-
   siochronous digital hierarchies and speech encoding regimes.

   The SONET and SDH efforts specify an entire infrastructure, from
   physical-layer through network-layer to application-layer.  The upper
   layers rely on ISO CLNP, TP4/CLNS, ASN.1, ASCE, CMISE, and an exten-
   sive list of ITU-T X.committee specifications.

   Where SONET/SDH is configured as a point-to-point circuit, PPP is
   well suited to use over these links.  PPP provides link-layer packet
   encapsulation with framing, and treats SONET/SDH in its entirety
   merely as an overly complicated physical-layer, ignoring its other
   features.

   Because the PPP encapsulation has relatively low overhead, it is
   anticipated that substantially higher throughput can be attained com-
   pared to other SONET/SDH payload mappings, at a significantly lower
   cost for line termination equipment.


1.1.  Terminology

   The various committees changing the SONET/SDH specifications have
   been inconsistent in their terminology.  This specification uses a
   few simplified terms:

   block            A fixed-size time-based multiplexing unit, carried
                    from interface to interface; also known as the SONET
                    Synchronous Transport Signal (STS-N) Frame, or the
                    SDH Synchronous Transport Module (STM-N) Frame
                    Structure.  This use of "frame" conflicts with link-
                    layer use of the same term.  The format has more in
                    common with fixed-length unit record equipment, such
                    as a magnetic tape, than with a variable-length
                    packet.




Simpson                   expires in six months                 [Page 1]


DRAFT                      PPP over SONET/SDH                August 1998


   byte             An 8-bit quantity; also known as "octet" in stan-
                    dardese.

   envelope         A fixed-size time-based multiplexing unit, carried
                    within successive blocks along a path; also known as
                    the SONET Synchronous Payload Envelope (SPE), or the
                    SDH Administrative Unit Group (AUG).

   frame            A variable-length unit of transmission, which is
                    passed across the interface between the link-layer
                    and the physical-layer.  A single packet is usually
                    wrapped in a frame, unless link-layer packet frag-
                    mentation is performed, or multiple packets are
                    aggregated into a single frame.

   packet           The basic unit of link encapsulation, which is
                    passed across the interface between the network-
                    layer and the link-layer.  The packet information is
                    variable-length.

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC-2119].

   To remain consistent with standard Internet practice, and avoid con-
   fusion for people used to reading RFCs, all binary numbers in the
   following descriptions are in Most Significant Bit to Least Signifi-
   cant Bit order, from Most Significant Byte to Least Significant Byte,
   reading from left to right, unless otherwise indicated.  Note that
   this is contrary to ISO and ITU practice, which orders bits as trans-
   mitted (network bit order).  Keep this in mind when comparing this
   document with the other documents.


2.  Physical Layer Requirements

   PPP treats SONET/SDH transport as an octet-oriented synchronous link.
   SONET/SDH links are bi-directional and full-duplex by definition.

   Interface Format

      PPP presents an octet interface to the physical layer.  There is
      no provision for sub-octets to be supplied or accepted.

      The octet stream is mapped into the SONET/SDH envelope payload,
      with the octet boundaries aligned with the payload byte bound-
      aries.




Simpson                   expires in six months                 [Page 2]


DRAFT                      PPP over SONET/SDH                August 1998


      PPP Authentication is preferable to the use of Path Trace (J1) for
      confirming connection between the correct peers.

      The Path Signal Label (C2) is intended to indicate the contents of
      the envelope.

      16 (10 hex) has been assigned to indicate PPP in octet-synchronous
         HDLC-like framing [RFC-1662] with ATM-style payload scrambling.
         This scrambling MUST be configurable at both terminals, and
         SHOULD NOT be enabled by default.  This technique is only used
         at STS-3c/STM-1.

      17 (11 hex) has been assigned to indicate PPP in ether-like fram-
         ing [RFC-yyyy] with LSFR payload scrambling.

      207
         (cf hex) SHOULD be used to indicate PPP in octet-synchronous
         HDLC-like framing [RFC-1662].  Byte sequences that might other-
         wise need scrambling (for under-performing circuits) are
         escaped using optional prophylactic octet-stuffing.  This tech-
         nique is only used at STS-3c/STM-1 and STS-12c/STM-4.

      An implementation MUST also allow configuration of the C2 field to
      0 (Unequipped) or 1 (Non-Specific Payload).

      The Multipurpose Position Indicator (H4) is currently unused, and
      MUST be zero.

   Transmission Rate

      The SONET transmission rates are integral multiples of 51.840
      Mbps, which may be used to carry T3/E3 signals.  The allowed mul-
      tiples are currently specified (in Mbps) as

              STS-1    51.840         STS-18    933.120
              STS-3   155.520         STS-24  1,244.160
              STS-9   466.560         STS-36  1,866.240
              STS-12  622.080         STS-48  2,488.320

                                      STS-192 9,953.280

      SDH defines a subset of SONET transmission rates beginning at
      155.520 Mbps [G.707]








Simpson                   expires in six months                 [Page 3]


DRAFT                      PPP over SONET/SDH                August 1998


              SONET           SDH equivalent
              STS-3c          STM-1
              STS-12c         STM-4
              STS-48c         STM-16
              STS-192c        STM-48

      The basic rate chosen for this specification is that of
      STS-3c/STM-1 at 155.520 Mbps.  The available information bandwidth
      is 149.760 Mbps, which is the STS-3c/STM-1 envelope payload with
      overhead removed.  This is the same super-rate mapping that is
      used for ATM and FDDI.

      Lower signal rates MUST use the SONET Virtual Tributary (VT) mech-
      anism, also known as SDH Tributary Units (TU) and Virtual Contain-
      ers (VC).  This maps existing signals up to T3/E3 rates asyn-
      chronously into the envelope, or uses available clocks for bit-
      synchronous and byte-synchronous mapping.

      Higher signal rates SHOULD conform to the SDH STM series, rather
      than the SONET STS series, as equipment becomes available.  The
      STM series progresses in powers of 4 (instead of 3), and employs
      fewer steps, which is likely to simplify multiplexing and integra-
      tion, thereby promoting interoperability.

   Control Signals

      PPP does not require the use of control signals.  When available,
      using such signals can allow greater functionality and perfor-
      mance.  Implications are discussed in [RFC-1662].

   For more information on the specification of the SONET/SDH interface,
   see [RFC-zzzz].


3.  The Data Link Layer

   The framed PPP packet MUST be mapped directly into the envelope pay-
   load by row, skipping a single column for Path Overhead (POH), and
   filling any fixed-stuff columns.  Because packets are variable in
   length, the frames are allowed to carry over envelope boundaries.

   Interleaving and separating VT/TU PPP packet streams over multiple
   circuit paths are beyond the scope of this specification.








Simpson                   expires in six months                 [Page 4]


DRAFT                      PPP over SONET/SDH                August 1998


3.1.  STS-3c/STM-1 and STS-12c/STM-4

   By default, octet-synchronous HDLC-like framing [RFC-1662] MUST be
   implemented.

   As an option, octet-synchronous Frame Relay [RFC-1973bis] MAY be
   implemented.


3.2.  STS-48c/STM-4 and above

   By default, ether-like framing [RFC-yyyy] MUST be implemented.


4.  Configuration Details

   The standard LCP 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
      Link Quality Monitoring
      Self Describing Padding
      32-bit FCS

























Simpson                   expires in six months                 [Page 5]


DRAFT                      PPP over SONET/SDH                August 1998


A.  Payload Scrambling

   Several suggestions have been made for reducing the possibility that
   a maliciously chosen payload can cause a long sequence of one or zero
   bits, resulting in the Loss of Signal (LOS) indication.  Implementa-
   tions strictly conforming to original SONET specification are not
   subject to this problem, and the recommendations in the [RFC-zzzz]
   profile completely prevent this problem.

   However, the profile recommends testing for non-conforming installa-
   tions.  When the recommended installation test detects that line rate
   clock recovery is not sufficiently stable to meet the requirements of
   this specification, Prophylactic Octet Stuffing MAY be configured by
   the sending peer.  There is no requirement that this method be imple-
   mented.


A.1.  Prophylactic Octet Stuffing

   The installation test SHOULD determine the maximum number of bytes
   that can be safely sent, and configure the allowance at one less.
   The transmitter checks the outgoing bytes, and adds an escape when-
   ever the allowance is exceeded.

   The principal advantage of this method is that it is fully backward
   compatible.  The receiver does not need to make any changes, as
   octet-stuffing escapes are already handled.

   Also, there are no additional error patterns introduced that are
   undetectable by the FCS.

   Moreover, this method operates on octets rather than bits, and is
   parallelizable in the same fashion as HDLC-like framing.

   Finally, the resulting protection is complete, rather than proba-
   bilistic.

   /* Detect SONET/SDH section scrambler pattern in PPP data.
    *  1996 May,   William Allen Simpson
    */
   typedef unsigned char uint8;


   /* Combining the patterns for all-zeros and all-ones, each
    * byte in this table contains the next byte in the pattern.
    * There are 2 bytes that do not appear in the patterns
    * (00 and ff).  These are both directed to 7d, as the series
    * "7d 0e" is not a feasible PPP construct.



Simpson                   expires in six months                 [Page 6]


DRAFT                      PPP over SONET/SDH                August 1998


    */
   uint8 pattern[256] =
   {       0x7d, 0xfb, 0x0c, 0xf7, 0x18, 0xe3, 0x14, 0xef,
           0x30, 0xcb, 0x3c, 0xc7, 0x28, 0xd3, 0x24, 0xdf,
           0x61, 0x9a, 0x6d, 0x96, 0x79, 0x82, 0x75, 0x8e,
           0x51, 0xaa, 0x5d, 0xa6, 0x49, 0xb2, 0x45, 0xbe,
           0xc2, 0x39, 0xce, 0x35, 0xda, 0x21, 0xd6, 0x2d,
           0xf2, 0x09, 0xfe, 0x05, 0xea, 0x11, 0xe6, 0x1d,
           0xa3, 0x58, 0xaf, 0x54, 0xbb, 0x40, 0xb7, 0x4c,
           0x93, 0x68, 0x9f, 0x64, 0x8b, 0x70, 0x87, 0x7c,
           0x7e, 0x85, 0x72, 0x89, 0x66, 0x9d, 0x6a, 0x91,
           0x4e, 0xb5, 0x42, 0xb9, 0x56, 0xad, 0x5a, 0xa1,
           0x1f, 0xe4, 0x13, 0xe8, 0x07, 0xfc, 0x0b, 0xf0,
           0x2f, 0xd4, 0x23, 0xd8, 0x37, 0xcc, 0x3b, 0xc0,
           0xbc, 0x47, 0xb0, 0x4b, 0xa4, 0x5f, 0xa8, 0x53,
           0x8c, 0x77, 0x80, 0x7b, 0x94, 0x6f, 0x98, 0x63,
           0xdd, 0x26, 0xd1, 0x2a, 0xc5, 0x3e, 0xc9, 0x32,
           0xed, 0x16, 0xe1, 0x1a, 0xf5, 0x0e, 0xf9, 0x02,

           0xfd, 0x06, 0xf1, 0x0a, 0xe5, 0x1e, 0xe9, 0x12,
           0xcd, 0x36, 0xc1, 0x3a, 0xd5, 0x2e, 0xd9, 0x22,
           0x9c, 0x67, 0x90, 0x6b, 0x84, 0x7f, 0x88, 0x73,
           0xac, 0x57, 0xa0, 0x5b, 0xb4, 0x4f, 0xb8, 0x43,
           0x3f, 0xc4, 0x33, 0xc8, 0x27, 0xdc, 0x2b, 0xd0,
           0x0f, 0xf4, 0x03, 0xf8, 0x17, 0xec, 0x1b, 0xe0,
           0x5e, 0xa5, 0x52, 0xa9, 0x46, 0xbd, 0x4a, 0xb1,
           0x6e, 0x95, 0x62, 0x99, 0x76, 0x8d, 0x7a, 0x81,
           0x83, 0x78, 0x8f, 0x74, 0x9b, 0x60, 0x97, 0x6c,
           0xb3, 0x48, 0xbf, 0x44, 0xab, 0x50, 0xa7, 0x5c,
           0xe2, 0x19, 0xee, 0x15, 0xfa, 0x01, 0xf6, 0x0d,
           0xd2, 0x29, 0xde, 0x25, 0xca, 0x31, 0xc6, 0x3d,
           0x41, 0xba, 0x4d, 0xb6, 0x59, 0xa2, 0x55, 0xae,
           0x71, 0x8a, 0x7d, 0x86, 0x69, 0x92, 0x65, 0x9e,
           0x20, 0xdb, 0x2c, 0xd7, 0x38, 0xc3, 0x34, 0xcf,
           0x10, 0xeb, 0x1c, 0xe7, 0x08, 0xf3, 0x04, 0x7d
   };

   int pattern_allowed = 7;                /* maximum number of bytes
                                              permitted before escaping,
                                              default 7 */
   int pattern_found = 0;                  /* count of bytes matched */

   uint8 pattern_next = 0x7e;              /* next byte in pattern,
                                              assume start of HDLC frame */


   /* Check a byte stream for a pattern matching sequence
    * exceeding the allowed match length.  Return true/false.



Simpson                   expires in six months                 [Page 7]


DRAFT                      PPP over SONET/SDH                August 1998


    * On true, the caller will generate a two byte escape sequence,
    * calling this routine again with both values.
    */
   int pattern_escape_needed( uint8 current_byte )
   {
           if ( current_byte != pattern_next )
           {
                   pattern_found = 0;
           }
           else
           {
                   pattern_found++;
           }
           pattern_next = pattern[current_byte];
           return ((pattern_found > pattern_allowed)
               &&  (current_byte != 0x5e)
               &&  (current_byte != 0x7d)
               &&  (current_byte != 0x7e));
   }


A.2.  LFSR scrambling



A.3.  ATM-style scrambling

   The ATM (x**43 + 1) LFSR can be applied to the entire frame as it is
   inserted into the payload.

   The polynomial has an undesirable interaction with the HDLC 16-bit
   FCS (x**16 + x**12 + x**5 + 1).  Analysis has shown [FC97] that there
   exist undetectable burst error patterns, and that protection against
   errors in general is reduced.


A.4.  Rejected Alternatives

   An enhancement to the octet-stuffing technique has been suggested
   that checks the scrambler output for the all-zeros pattern, and sig-
   nals an escape insertion to the HDLC-like framer (or Frame Relay).
   This is only useful for highly integrated devices, and protects only
   the first section.  Other payload alignments could occur on later
   sections in the path.

   Several recurrent suggestions are less desirable than octet stuffing.
   These suggestions do not provide backward compatibility.




Simpson                   expires in six months                 [Page 8]


DRAFT                      PPP over SONET/SDH                August 1998


   Moreover, none of these suggestions scale well.  They do not accommo-
   date parallel processing, as they are bit-oriented.

   Furthermore, for the LFSR techniques, the resulting protection is
   probabilistic, not a complete solution.

   ATM employs a payload LFSR scrambler that affects only the data por-
   tion of the ATM cell, and does not include the ATM header.  The gen-
   erating polynomial for the LFSR is x**43 + 1.

   The equivalent technique applied to PPP encapsulated packets in HDLC-
   like frames (or Frame Relay) as they are inserted into the payload
   would not include the framing octets.

   This is rejected, as the scrambled data could mimic the frame delim-
   iting flag sequence, resulting in incorrect frame detection.

   Other LFSR polynomials have been proposed.  These have a similar
   error multiplication effect.


Security Considerations

   This specification introduces no known security vulnerabilities.


Acknowledgements

   PPP over SONET was first proposed by Craig Partridge (BBN).  Some
   information was obtained from the good folks at Bellcore.

   Technical assistance and information was also provided by Victor Dem-
   janenko (SUNY Buffalo).

   Anonymous, Karl Fox (Ascend), Peter Lothberg (Sprint), Subhash Roy
   (TranSwitch), Stuart Venters (Adtran), and Eric Verwillow (Juniper)
   provided useful critiques of earlier versions of this document.

   Special thanks to Ascend Communications (nee Morning Star Technolo-
   gies) for providing computing resources and network access support
   for writing this specification.










Simpson                   expires in six months                 [Page 9]


DRAFT                      PPP over SONET/SDH                August 1998


References

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

   [RFC-1662]  Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51,
               DayDreamer, July 1994.

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP-14, Harvard University, March
               1997.

   [RFC-yyyy]  Simpson, W., "PPP in Ether-like Framing", DayDreamer,
               work in progress.

   [RFC-zzzz]  Simpson, W., "Applicability Statement for PPP over
               SONET/SDH", DayDreamer, work in progress.

   [SONET]     "Synchronous Optical Network (SONET) Transport Systems:
               Common Generic Criteria", Bellcore, TR-NWT-000253 Issue
               2, December 1991.

   [G.707]     CCITT Recommendation G.707, "Synchronous Digital Hierar-
               chy Bit Rates", June 1992.



























Simpson                   expires in six months                [Page 10]


DRAFT                      PPP over SONET/SDH                August 1998


Contacts

   Comments about this document should be discussed on the
   pppsdh@greendragon.com or ietf-ppp@merit.edu mailing lists.

   This document was reviewed by the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  The working
   group can be contacted via the current chair:

      Karl Fox
      Ascend Communications
      655 Metro Place South,  Suite 370
      Dublin, Ohio  43017

          karl@Ascend.com

   Questions about this document can also be directed to:

      William Allen Simpson
      DayDreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)

























Simpson                   expires in six months                [Page 11]


DRAFT                      PPP over SONET/SDH                August 1998


Full Copyright Statement

   Copyright (C) William Allen Simpson (1993-1994, 1997-1998).  All
   Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this doc-
   ument itself may not be modified in any way, except as required to
   translate it into languages other than English.

   This document and the information contained herein is provided on an
   "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
































Simpson                   expires in six months                [Page 12]