summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2615.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2615.txt')
-rw-r--r--doc/rfc/rfc2615.txt563
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]
+