home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2615.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  18.8 KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          A. Malis
  8. Request for Comments: 2615                  Ascend Communications, Inc.
  9. Obsoletes: 1619                                              W. Simpson
  10. Category: Standards Track                                    DayDreamer
  11.                                                               June 1999
  12.  
  13.  
  14.                            PPP over SONET/SDH
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Copyright Notice
  25.  
  26.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  27.  
  28. Abstract
  29.  
  30.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  31.    transporting multi-protocol datagrams over point-to-point links.
  32.    This document describes the use of PPP over Synchronous Optical
  33.    Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits.
  34.  
  35.    This document replaces and obsoletes RFC 1619.  See section 7 for a
  36.    summary of the changes from RFC 1619.
  37.  
  38. Table of Contents
  39.  
  40.    1.     Introduction ..........................................    2
  41.    2.     Physical Layer Requirements ...........................    3
  42.    3.     Framing ...............................................    4
  43.    4.     X**43 + 1 Scrambler Description .......................    4
  44.    5.     Configuration Details .................................    6
  45.    6.     Security Considerations ...............................    6
  46.    7.     Changes from RFC 1619 .................................    7
  47.    8.     Intellectual Property .................................    7
  48.    9.     Acknowledgments .......................................    8
  49.    10.    References ............................................    8
  50.    11.    Authors' Addresses ....................................    9
  51.    12.    Full Copyright Statement ..............................   10
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Malis & Simpson             Standards Track                     [Page 1]
  59.  
  60. RFC 2615                  PPP over SONET/SDH                   June 1999
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    PPP was designed as a standard method of communicating over
  66.    point-to-point links.  Initial deployment has been over short local
  67.    lines, leased lines, and plain-old-telephone-service (POTS) using
  68.    modems.  As new packet services and higher speed lines are introduced,
  69.    PPP is easily deployed in these environments as well.
  70.  
  71.    This specification is primarily concerned with the use of the PPP
  72.    encapsulation over SONET/SDH links.  Since SONET/SDH is by definition
  73.    a point-to-point circuit, PPP is well suited to use over these links.
  74.  
  75.    Real differences between SONET and SDH (other than terminology) are
  76.    minor; for the purposes of encapsulation of PPP over SONET/SDH, they
  77.    are inconsequential or irrelevant.
  78.  
  79.    For the convenience of the reader, we list the equivalent terms below:
  80.  
  81.        SONET                   SDH
  82.    ---------------------------------------------
  83.    SPE                         VC
  84.    STS-SPE                     Higher Order VC (VC-3/4/4-Nc)
  85.    STS-1 frame                 STM-0 frame (rarely used)
  86.    STS-1-SPE                   VC-3
  87.    STS-1 payload               C-3
  88.    STS-3c frame                STM-1 frame, AU-4
  89.    STS-3c-SPE                  VC-4
  90.    STS-3c payload              C-4
  91.    STS-12c/48c/192c frame      STM-4/16/64 frame, AU-4-4c/16c/64c
  92.    STS-12c/48c/192c-SPE        VC-4-4c/16c/64c
  93.    STS-12c/48c/192c payload    C-4-4c/16c/64c
  94.  
  95.    The only currently supported SONET/SDH SPE/VCs are the following:
  96.  
  97.        SONET                   SDH
  98.    ----------------------------------------
  99.    STS-3c-SPE                  VC-4
  100.    STS-12c-SPE                 VC-4-4c
  101.    STS-48c-SPE                 VC-4-16c
  102.    STS-192c-SPE                VC-4-64c
  103.  
  104.    The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
  105.    SHALL, SHALL NOT, SHOULD, and SHOULD NOT are to be interpreted as
  106.    defined in [6].
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Malis & Simpson             Standards Track                     [Page 2]
  115.  
  116. RFC 2615                  PPP over SONET/SDH                   June 1999
  117.  
  118.  
  119. 2.  Physical Layer Requirements
  120.  
  121.    PPP treats SONET/SDH transport as octet oriented synchronous links.
  122.    SONET/SDH links are full-duplex by definition.
  123.  
  124.    Interface Format
  125.  
  126.       PPP in HDLC-like framing presents an octet interface to the
  127.       physical layer.  There is no provision for sub-octets to be
  128.       supplied or accepted [3][5].
  129.  
  130.       The octet stream is mapped into the SONET STS-SPE/SDH Higher Order
  131.       VC, with the octet boundaries aligned with the SONET STS-SPE/SDH
  132.       Higher Order VC octet boundaries.
  133.  
  134.       Scrambling is performed during insertion into the SONET STS-
  135.       SPE/SDH Higher Order VC to provide adequate transparency and
  136.       protect against potential security threats (see Section 6).  For
  137.       backwards compatibility with RFC 1619 (STS-3c-SPE/VC-4 only), the
  138.       scrambler MAY have an on/off capability where the scrambler is
  139.       bypassed entirely when it is in the off mode.  If this capability
  140.       is provided, the default MUST be set to scrambling enabled.
  141.  
  142.       For PPP over SONET/SDH, the entire SONET/SDH payload (SONET STS-
  143.       SPE/SDH Higher Order VC minus the path overhead and any fixed
  144.       stuff) is scrambled using a self-synchronous scrambler of
  145.       polynomial X**43 + 1.  See Section 4 for the description of the
  146.       scrambler.
  147.  
  148.       The proper order of operation is:
  149.  
  150.       When transmitting:
  151.  
  152.          IP -> PPP -> FCS generation -> Byte stuffing -> Scrambling  ->
  153.          SONET/SDH framing
  154.  
  155.       When receiving:
  156.  
  157.          SONET/SDH framing -> Descrambling -> Byte destuffing -> FCS
  158.          detection -> PPP -> IP
  159.  
  160.    The Path Signal Label (C2) indicates the contents of the SONET STS-
  161.    SPE/SDH Higher Order VC.  The value of 22 (16 hex) is used to
  162.    indicate PPP with X^43 + 1 scrambling [4].
  163.  
  164.    For compatibility with RFC 1619 (STS-3c-SPE/VC-4 only), if scrambling
  165.    has been configured to be off, then the value 207 (CF hex) is used
  166.    for the Path Signal Label to indicate PPP without scrambling.
  167.  
  168.  
  169.  
  170. Malis & Simpson             Standards Track                     [Page 3]
  171.  
  172. RFC 2615                  PPP over SONET/SDH                   June 1999
  173.  
  174.  
  175.    The Multiframe Indicator (H4) is unused, and MUST be zero.
  176.  
  177.    Control Signals
  178.  
  179.       PPP does not require the use of control signals.  When available,
  180.       using such signals can allow greater functionality and
  181.       performance.  Implications are discussed in [2].
  182.  
  183. 3.  Framing
  184.  
  185.    The framing for octet-synchronous links is described in "PPP in
  186.    HDLC-like Framing" [2].
  187.  
  188.    The PPP frames are located by row within the SONET STS-SPE/SDH Higher
  189.    Order VC payload.  Because frames are variable in length, the frames
  190.    are allowed to cross SONET STS-SPE/SDH Higher Order VC boundaries.
  191.  
  192. 4.  X**43 + 1 Scrambler Description
  193.  
  194.    The X**43 + 1 scrambler transmitter and receiver operation are as
  195.    follows:
  196.  
  197.    Transmitter schematic:
  198.  
  199.                                               Unscrambled Data
  200.                                                      |
  201.                                                      v
  202.         +-------------------------------------+    +---+
  203.      +->|     --> 43 bit shift register -->   |--->|xor|
  204.      |  +-------------------------------------+    +---+
  205.      |                                               |
  206.      +-----------------------------------------------+
  207.                                                      |
  208.                                                      v
  209.                                                Scrambled Data
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Malis & Simpson             Standards Track                     [Page 4]
  227.  
  228. RFC 2615                  PPP over SONET/SDH                   June 1999
  229.  
  230.  
  231.    Receiver schematic:
  232.  
  233.                                                Scrambled Data
  234.                                                      |
  235.      +-----------------------------------------------+
  236.      |                                               |
  237.      |                                               v
  238.      |  +-------------------------------------+    +---+
  239.      +->|     --> 43 bit shift register -->   |--->|xor|
  240.         +-------------------------------------+    +---+
  241.                                                      |
  242.                                                      v
  243.                                              Unscrambled Data
  244.  
  245.  
  246.    Note: While the HDLC FCS is calculated least significant bit first as
  247.    shown:
  248.  
  249.               <-  <-  <-  <-
  250.               A   B   C   D
  251.  
  252.    (that is, the FCS calculator is fed as follows: A[0], A[1], ... A[7],
  253.    B[0], B[1], etc...),  scrambling is done in the opposite manner, most
  254.    significant bit first, as shown:
  255.  
  256.                ->  ->  ->  ->
  257.                A   B   C   D.
  258.  
  259.    That is, the scrambler is fed as follows: A[7], A[6], ... A[0], B[7],
  260.    B[6], etc...
  261.  
  262.    The scrambler operates continuously through the bytes of the SONET
  263.    STS-SPE/SDH Higher Order VC, bypassing bytes of SONET Path Overhead
  264.    and any fixed stuff (see Figure 20 of ANSI T1.105 [3] or Figure 10-17
  265.    of ITU G.707 [5]).  The scrambling state at the beginning of a SONET
  266.    STS-SPE/SDH Higher Order VC is the state at the end of the previous
  267.    SONET STS-SPE/SDH Higher Order VC.  Thus, the scrambler runs
  268.    continuously and is not reset per frame. The initial seed is randomly
  269.    chosen by transmitter to improve operational security (see Section
  270.    6).  Consequently, the first 43 transmitted bits following startup or
  271.    reframe operation will not be descrambled correctly.
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Malis & Simpson             Standards Track                     [Page 5]
  283.  
  284. RFC 2615                  PPP over SONET/SDH                   June 1999
  285.  
  286.  
  287. 5.  Configuration Details
  288.  
  289.    Other than the FCS length (see below), the standard LCP sync
  290.    configuration defaults apply to SONET/SDH links.
  291.  
  292.    The following Configuration Options are RECOMMENDED for STS-3c-
  293.    SPE/VC-4:
  294.  
  295.       Magic Number
  296.       No Address and Control Field Compression
  297.       No Protocol Field Compression
  298.  
  299.    For operation at STS-12c-SPE/VC-4-4c and above, Address and Control
  300.    Field Compression and Protocol Field Compression are NOT RECOMMENDED.
  301.    The Magic Number option remains RECOMMENDED.
  302.  
  303.    Regarding the FCS length, with one exception, the 32-bit FCS MUST be
  304.    used for all SONET/SDH rates. For STS-3c-SPE/VC-4 only, the 16-bit
  305.    FCS MAY be used, although the 32-bit FCS is RECOMMENDED.  The FCS
  306.    length is set by provisioning and is not negotiated.
  307.  
  308. 6.  Security Considerations
  309.  
  310.    The major change from RFC 1619 is the addition of payload scrambling
  311.    when inserting the HDLC-like framed PPP packets into the SONET STS-
  312.    SPE/SDH Higher Order VC.  RFC 1619 was operationally found to permit
  313.    malicious users to generate packets with bit patterns that could
  314.    create SONET/SDH-layer low-transition-density synchronization
  315.    problems, emulation of the SDH set-reset scrambler pattern, and
  316.    replication of the STM-N frame alignment word.
  317.  
  318.    The use of the x^43 + 1 self-synchronous scrambler was introduced to
  319.    alleviate these potential security problems.  Predicting the output
  320.    of the scrambler requires knowledge of the 43-bit state of the
  321.    transmitter as the scrambling of a known input is begun.  This
  322.    requires knowledge of both the initial 43-bit state of the scrambler
  323.    when it started and every byte of data scrambled by the device since
  324.    it was started.  The odds of guessing correctly are 1/2**43, with the
  325.    additional probability of 1/127 that a correct guess will leave the
  326.    frame properly aligned in the SONET/SDH payload, which results in a
  327.    probability of 9e-16 against being able to deliberately cause
  328.    SONET/SDH-layer problems.  This seems reasonably secure for this
  329.    application.
  330.  
  331.    This scrambler is also used when transmitting ATM over SONET/SDH, and
  332.    public network carriers have considerable experience with its use.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Malis & Simpson             Standards Track                     [Page 6]
  339.  
  340. RFC 2615                  PPP over SONET/SDH                   June 1999
  341.  
  342.  
  343.    A known security issue is bandwidth reduction by intentional
  344.    transmission of characters or sequences requiring transparency
  345.    processing by including flag and/or escape characters in user data. A
  346.    user may cause up to a 100% increase in the bandwidth required for
  347.    transmitting his or her packets by filling the packet with flag
  348.    and/or escape characters.
  349.  
  350. 7.  Changes from RFC 1619
  351.  
  352.    As mentioned in the previous section, the major change from RFC 1619
  353.    was the addition of payload scrambling when inserting the HDLC-like
  354.    framed PPP packets into the SONET STS-SPE/SDH Higher Order VC.  Other
  355.    changes were:
  356.  
  357.    The terminology was updated to better match that used by ANSI and
  358.    ITU-T.
  359.  
  360.    The specification's applicability is now specifically restricted to:
  361.  
  362.        SONET                   SDH
  363.    ----------------------------------------
  364.    STS-3c-SPE                  VC-4
  365.    STS-12c-SPE                 VC-4-4c
  366.    STS-48c-SPE                 VC-4-16c
  367.    STS-192c-SPE                VC-4-64c
  368.  
  369.    The Path Signal Label (C2) is set to 22 (16 hex) when using X^43 + 1
  370.    scrambling.
  371.  
  372.    The 32-bit FCS is required except for operation with STS-3c-SPE/VC-4,
  373.    in which case the 16-bit FCS is allowed (but the 32-bit FCS is still
  374.    recommended).
  375.  
  376.    The Security Considerations section was added.
  377.  
  378. 8.  Intellectual Property
  379.  
  380.    The IETF takes no position regarding the validity or scope of any
  381.    intellectual property or other rights that might be claimed to
  382.    pertain to the implementation or use of the technology described in
  383.    this document or the extent to which any license under such rights
  384.    might or might not be available; neither does it represent that it
  385.    has made any effort to identify any such rights.  Information on the
  386.    IETF's procedures with respect to rights in standards-track and
  387.    standards-related documentation can be found in BCP-11.  Copies of
  388.    claims of rights made available for publication and any assurances of
  389.    licenses to be made available, or the result of an attempt made to
  390.    obtain a general license or permission for the use of such
  391.  
  392.  
  393.  
  394. Malis & Simpson             Standards Track                     [Page 7]
  395.  
  396. RFC 2615                  PPP over SONET/SDH                   June 1999
  397.  
  398.  
  399.    proprietary rights by implementors or users of this specification can
  400.    be obtained from the IETF Secretariat.
  401.  
  402.    The IETF invites any interested party to bring to its attention any
  403.    copyrights, patents or patent applications, or other proprietary
  404.    rights which may cover technology that may be required to practice
  405.    this standard.  Please address the information to the IETF Executive
  406.    Director.
  407.  
  408. 9.  Acknowledgments
  409.  
  410.    The scrambler description was provided by J. Manchester, S. Davida,
  411.    B. Doshi, and J. Anderson of Lucent Technologies, R. Broberg of Cisco
  412.    Systems, and Peter Lothberg of Sprint Corporation.  The security
  413.    analysis was provided by Iain Verigin of PMC-Sierra and Larry McAdams
  414.    of Cisco Systems.  The authors would also like to thank the members
  415.    of the IETF's Point-to-Point Protocol Extensions Working Group for
  416.    their many suggestions and improvements to the text.
  417.  
  418. 10.  References
  419.  
  420.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  421.          51, RFC 1661, Daydreamer, July 1994.
  422.  
  423.    [2]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
  424.          1662, Daydreamer, July 1994.
  425.  
  426.    [3]   American National Standards Institute, "Synchronous Optical
  427.          Network (SONET) - Basic Description including Multiplex
  428.          Structure, Rates and Formats," ANSI T1.105-1995.
  429.  
  430.    [4]   American National Standards Institute, "Synchronous Optical
  431.          Network (SONET)--Payload Mappings," T1.105.02-1998.
  432.  
  433.    [5]   ITU Recommendation G.707, "Network Node Interface For The
  434.          Synchronous Digital Hierarchy", 1996.
  435.  
  436.    [6]   Bradner, S., "Key words for use in RFCs to indicate Requirement
  437.          Levels", BCP 14, RFC 2119, March 1997.
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Malis & Simpson             Standards Track                     [Page 8]
  451.  
  452. RFC 2615                  PPP over SONET/SDH                   June 1999
  453.  
  454.  
  455. 11.  Authors' Addresses
  456.  
  457.    Andrew G. Malis
  458.    Ascend Communications, Inc.
  459.    1 Robbins Road
  460.    Westford, MA 01810 USA
  461.  
  462.    Phone: +1 978 952 7414
  463.    EMail: malis@ascend.com
  464.  
  465.  
  466.    William Allen Simpson
  467.    DayDreamer
  468.    Computer Systems Consulting Services
  469.    1384 Fontaine
  470.    Madison Heights, Michigan  48071
  471.  
  472.    EMail: wsimpson@GreenDragon.com
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Malis & Simpson             Standards Track                     [Page 9]
  507.  
  508. RFC 2615                  PPP over SONET/SDH                   June 1999
  509.  
  510.  
  511. 12.  Full Copyright Statement
  512.  
  513.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  514.  
  515.    This document and translations of it may be copied and furnished to
  516.    others, and derivative works that comment on or otherwise explain it
  517.    or assist in its implementation may be prepared, copied, published
  518.    and distributed, in whole or in part, without restriction of any
  519.    kind, provided that the above copyright notice and this paragraph are
  520.    included on all such copies and derivative works.  However, this
  521.    document itself may not be modified in any way, such as by removing
  522.    the copyright notice or references to the Internet Society or other
  523.    Internet organizations, except as needed for the purpose of
  524.    developing Internet standards in which case the procedures for
  525.    copyrights defined in the Internet Standards process must be
  526.    followed, or as required to translate it into languages other than
  527.    English.
  528.  
  529.    The limited permissions granted above are perpetual and will not be
  530.    revoked by the Internet Society or its successors or assigns.
  531.  
  532.    This document and the information contained herein is provided on an
  533.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  534.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  535.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  536.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  537.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  538.  
  539. Acknowledgement
  540.  
  541.    Funding for the RFC Editor function is currently provided by the
  542.    Internet Society.
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Malis & Simpson             Standards Track                    [Page 10]
  563.  
  564.