📄 rfc2615.txt
字号:
Network Working Group A. MalisRequest for Comments: 2615 Ascend Communications, Inc.Obsoletes: 1619 W. SimpsonCategory: Standards Track DayDreamer June 1999 PPP over SONET/SDHStatus 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 .............................. 10Malis & Simpson Standards Track [Page 1]RFC 2615 PPP over SONET/SDH June 19991. 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 19992. 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 DataMalis & 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]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -