doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2615.txt b/doc/rfc/rfc2615.txt
new file mode 100644
index 0000000..05d7ef4
--- /dev/null
+++ b/doc/rfc/rfc2615.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                          A. Malis
+Request for Comments: 2615                  Ascend Communications, Inc.
+Obsoletes: 1619                                              W. Simpson
+Category: Standards Track                                    DayDreamer
+                                                              June 1999
+
+
+                           PPP over SONET/SDH
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) [1] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.
+   This document describes the use of PPP over Synchronous Optical
+   Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits.
+
+   This document replaces and obsoletes RFC 1619.  See section 7 for a
+   summary of the changes from RFC 1619.
+
+Table of Contents
+
+   1.     Introduction ..........................................    2
+   2.     Physical Layer Requirements ...........................    3
+   3.     Framing ...............................................    4
+   4.     X**43 + 1 Scrambler Description .......................    4
+   5.     Configuration Details .................................    6
+   6.     Security Considerations ...............................    6
+   7.     Changes from RFC 1619 .................................    7
+   8.     Intellectual Property .................................    7
+   9.     Acknowledgments .......................................    8
+   10.    References ............................................    8
+   11.    Authors' Addresses ....................................    9
+   12.    Full Copyright Statement ..............................   10
+
+
+
+
+
+
+Malis & Simpson             Standards Track                     [Page 1]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+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.
+
+   This specification is primarily concerned with the use of the PPP
+   encapsulation over SONET/SDH links.  Since SONET/SDH is by definition
+   a point-to-point circuit, PPP is well suited to use over these links.
+
+   Real differences between SONET and SDH (other than terminology) are
+   minor; for the purposes of encapsulation of PPP over SONET/SDH, they
+   are inconsequential or irrelevant.
+
+   For the convenience of the reader, we list the equivalent terms below:
+
+       SONET                   SDH
+   ---------------------------------------------
+   SPE                         VC
+   STS-SPE                     Higher Order VC (VC-3/4/4-Nc)
+   STS-1 frame                 STM-0 frame (rarely used)
+   STS-1-SPE                   VC-3
+   STS-1 payload               C-3
+   STS-3c frame                STM-1 frame, AU-4
+   STS-3c-SPE                  VC-4
+   STS-3c payload              C-4
+   STS-12c/48c/192c frame      STM-4/16/64 frame, AU-4-4c/16c/64c
+   STS-12c/48c/192c-SPE        VC-4-4c/16c/64c
+   STS-12c/48c/192c payload    C-4-4c/16c/64c
+
+   The only currently supported SONET/SDH SPE/VCs are the following:
+
+       SONET                   SDH
+   ----------------------------------------
+   STS-3c-SPE                  VC-4
+   STS-12c-SPE                 VC-4-4c
+   STS-48c-SPE                 VC-4-16c
+   STS-192c-SPE                VC-4-64c
+
+   The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
+   SHALL, SHALL NOT, SHOULD, and SHOULD NOT are to be interpreted as
+   defined in [6].
+
+
+
+
+
+
+
+Malis & Simpson             Standards Track                     [Page 2]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+2.  Physical Layer Requirements
+
+   PPP treats SONET/SDH transport as octet oriented synchronous links.
+   SONET/SDH links are full-duplex by definition.
+
+   Interface Format
+
+      PPP in HDLC-like framing presents an octet interface to the
+      physical layer.  There is no provision for sub-octets to be
+      supplied or accepted [3][5].
+
+      The octet stream is mapped into the SONET STS-SPE/SDH Higher Order
+      VC, with the octet boundaries aligned with the SONET STS-SPE/SDH
+      Higher Order VC octet boundaries.
+
+      Scrambling is performed during insertion into the SONET STS-
+      SPE/SDH Higher Order VC to provide adequate transparency and
+      protect against potential security threats (see Section 6).  For
+      backwards compatibility with RFC 1619 (STS-3c-SPE/VC-4 only), the
+      scrambler MAY have an on/off capability where the scrambler is
+      bypassed entirely when it is in the off mode.  If this capability
+      is provided, the default MUST be set to scrambling enabled.
+
+      For PPP over SONET/SDH, the entire SONET/SDH payload (SONET STS-
+      SPE/SDH Higher Order VC minus the path overhead and any fixed
+      stuff) is scrambled using a self-synchronous scrambler of
+      polynomial X**43 + 1.  See Section 4 for the description of the
+      scrambler.
+
+      The proper order of operation is:
+
+      When transmitting:
+
+         IP -> PPP -> FCS generation -> Byte stuffing -> Scrambling  ->
+         SONET/SDH framing
+
+      When receiving:
+
+         SONET/SDH framing -> Descrambling -> Byte destuffing -> FCS
+         detection -> PPP -> IP
+
+   The Path Signal Label (C2) indicates the contents of the SONET STS-
+   SPE/SDH Higher Order VC.  The value of 22 (16 hex) is used to
+   indicate PPP with X^43 + 1 scrambling [4].
+
+   For compatibility with RFC 1619 (STS-3c-SPE/VC-4 only), if scrambling
+   has been configured to be off, then the value 207 (CF hex) is used
+   for the Path Signal Label to indicate PPP without scrambling.
+
+
+
+Malis & Simpson             Standards Track                     [Page 3]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+   The Multiframe Indicator (H4) is unused, and MUST be zero.
+
+   Control Signals
+
+      PPP does not require the use of control signals.  When available,
+      using such signals can allow greater functionality and
+      performance.  Implications are discussed in [2].
+
+3.  Framing
+
+   The framing for octet-synchronous links is described in "PPP in
+   HDLC-like Framing" [2].
+
+   The PPP frames are located by row within the SONET STS-SPE/SDH Higher
+   Order VC payload.  Because frames are variable in length, the frames
+   are allowed to cross SONET STS-SPE/SDH Higher Order VC boundaries.
+
+4.  X**43 + 1 Scrambler Description
+
+   The X**43 + 1 scrambler transmitter and receiver operation are as
+   follows:
+
+   Transmitter schematic:
+
+                                              Unscrambled Data
+                                                     |
+                                                     v
+        +-------------------------------------+    +---+
+     +->|     --> 43 bit shift register -->   |--->|xor|
+     |  +-------------------------------------+    +---+
+     |                                               |
+     +-----------------------------------------------+
+                                                     |
+                                                     v
+                                               Scrambled Data
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis & Simpson             Standards Track                     [Page 4]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+   Receiver schematic:
+
+                                               Scrambled Data
+                                                     |
+     +-----------------------------------------------+
+     |                                               |
+     |                                               v
+     |  +-------------------------------------+    +---+
+     +->|     --> 43 bit shift register -->   |--->|xor|
+        +-------------------------------------+    +---+
+                                                     |
+                                                     v
+                                             Unscrambled Data
+
+
+   Note: While the HDLC FCS is calculated least significant bit first as
+   shown:
+
+              <-  <-  <-  <-
+              A   B   C   D
+
+   (that is, the FCS calculator is fed as follows: A[0], A[1], ... A[7],
+   B[0], B[1], etc...),  scrambling is done in the opposite manner, most
+   significant bit first, as shown:
+
+               ->  ->  ->  ->
+               A   B   C   D.
+
+   That is, the scrambler is fed as follows: A[7], A[6], ... A[0], B[7],
+   B[6], etc...
+
+   The scrambler operates continuously through the bytes of the SONET
+   STS-SPE/SDH Higher Order VC, bypassing bytes of SONET Path Overhead
+   and any fixed stuff (see Figure 20 of ANSI T1.105 [3] or Figure 10-17
+   of ITU G.707 [5]).  The scrambling state at the beginning of a SONET
+   STS-SPE/SDH Higher Order VC is the state at the end of the previous
+   SONET STS-SPE/SDH Higher Order VC.  Thus, the scrambler runs
+   continuously and is not reset per frame. The initial seed is randomly
+   chosen by transmitter to improve operational security (see Section
+   6).  Consequently, the first 43 transmitted bits following startup or
+   reframe operation will not be descrambled correctly.
+
+
+
+
+
+
+
+
+
+
+Malis & Simpson             Standards Track                     [Page 5]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+5.  Configuration Details
+
+   Other than the FCS length (see below), the standard LCP sync
+   configuration defaults apply to SONET/SDH links.
+
+   The following Configuration Options are RECOMMENDED for STS-3c-
+   SPE/VC-4:
+
+      Magic Number
+      No Address and Control Field Compression
+      No Protocol Field Compression
+
+   For operation at STS-12c-SPE/VC-4-4c and above, Address and Control
+   Field Compression and Protocol Field Compression are NOT RECOMMENDED.
+   The Magic Number option remains RECOMMENDED.
+
+   Regarding the FCS length, with one exception, the 32-bit FCS MUST be
+   used for all SONET/SDH rates. For STS-3c-SPE/VC-4 only, the 16-bit
+   FCS MAY be used, although the 32-bit FCS is RECOMMENDED.  The FCS
+   length is set by provisioning and is not negotiated.
+
+6.  Security Considerations
+
+   The major change from RFC 1619 is the addition of payload scrambling
+   when inserting the HDLC-like framed PPP packets into the SONET STS-
+   SPE/SDH Higher Order VC.  RFC 1619 was operationally found to permit
+   malicious users to generate packets with bit patterns that could
+   create SONET/SDH-layer low-transition-density synchronization
+   problems, emulation of the SDH set-reset scrambler pattern, and
+   replication of the STM-N frame alignment word.
+
+   The use of the x^43 + 1 self-synchronous scrambler was introduced to
+   alleviate these potential security problems.  Predicting the output
+   of the scrambler requires knowledge of the 43-bit state of the
+   transmitter as the scrambling of a known input is begun.  This
+   requires knowledge of both the initial 43-bit state of the scrambler
+   when it started and every byte of data scrambled by the device since
+   it was started.  The odds of guessing correctly are 1/2**43, with the
+   additional probability of 1/127 that a correct guess will leave the
+   frame properly aligned in the SONET/SDH payload, which results in a
+   probability of 9e-16 against being able to deliberately cause
+   SONET/SDH-layer problems.  This seems reasonably secure for this
+   application.
+
+   This scrambler is also used when transmitting ATM over SONET/SDH, and
+   public network carriers have considerable experience with its use.
+
+
+
+
+
+Malis & Simpson             Standards Track                     [Page 6]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+   A known security issue is bandwidth reduction by intentional
+   transmission of characters or sequences requiring transparency
+   processing by including flag and/or escape characters in user data. A
+   user may cause up to a 100% increase in the bandwidth required for
+   transmitting his or her packets by filling the packet with flag
+   and/or escape characters.
+
+7.  Changes from RFC 1619
+
+   As mentioned in the previous section, the major change from RFC 1619
+   was the addition of payload scrambling when inserting the HDLC-like
+   framed PPP packets into the SONET STS-SPE/SDH Higher Order VC.  Other
+   changes were:
+
+   The terminology was updated to better match that used by ANSI and
+   ITU-T.
+
+   The specification's applicability is now specifically restricted to:
+
+       SONET                   SDH
+   ----------------------------------------
+   STS-3c-SPE                  VC-4
+   STS-12c-SPE                 VC-4-4c
+   STS-48c-SPE                 VC-4-16c
+   STS-192c-SPE                VC-4-64c
+
+   The Path Signal Label (C2) is set to 22 (16 hex) when using X^43 + 1
+   scrambling.
+
+   The 32-bit FCS is required except for operation with STS-3c-SPE/VC-4,
+   in which case the 16-bit FCS is allowed (but the 32-bit FCS is still
+   recommended).
+
+   The Security Considerations section was added.
+
+8.  Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+
+
+
+Malis & Simpson             Standards Track                     [Page 7]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+9.  Acknowledgments
+
+   The scrambler description was provided by J. Manchester, S. Davida,
+   B. Doshi, and J. Anderson of Lucent Technologies, R. Broberg of Cisco
+   Systems, and Peter Lothberg of Sprint Corporation.  The security
+   analysis was provided by Iain Verigin of PMC-Sierra and Larry McAdams
+   of Cisco Systems.  The authors would also like to thank the members
+   of the IETF's Point-to-Point Protocol Extensions Working Group for
+   their many suggestions and improvements to the text.
+
+10.  References
+
+   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+         51, RFC 1661, Daydreamer, July 1994.
+
+   [2]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
+         1662, Daydreamer, July 1994.
+
+   [3]   American National Standards Institute, "Synchronous Optical
+         Network (SONET) - Basic Description including Multiplex
+         Structure, Rates and Formats," ANSI T1.105-1995.
+
+   [4]   American National Standards Institute, "Synchronous Optical
+         Network (SONET)--Payload Mappings," T1.105.02-1998.
+
+   [5]   ITU Recommendation G.707, "Network Node Interface For The
+         Synchronous Digital Hierarchy", 1996.
+
+   [6]   Bradner, S., "Key words for use in RFCs to indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+Malis & Simpson             Standards Track                     [Page 8]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+11.  Authors' Addresses
+
+   Andrew G. Malis
+   Ascend Communications, Inc.
+   1 Robbins Road
+   Westford, MA 01810 USA
+
+   Phone: +1 978 952 7414
+   EMail: malis@ascend.com
+
+
+   William Allen Simpson
+   DayDreamer
+   Computer Systems Consulting Services
+   1384 Fontaine
+   Madison Heights, Michigan  48071
+
+   EMail: wsimpson@GreenDragon.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis & Simpson             Standards Track                     [Page 9]
+
+RFC 2615                  PPP over SONET/SDH                   June 1999
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis & Simpson             Standards Track                    [Page 10]
+