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]