PPP Extensions Working Group S. Merchant Internet Draft Cimaron Communications November 1998 PPP over SONET (SDH) at Rates from STS-1 (AU-3) to STS-192c (AU-4-64c/STM-64) Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working 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 inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard mechanism for transport of multi-protocol datagrams over point-to-point links. There is currently significant interest and activity in transporting PPP over SONET links, and RFC 1619 [2] and RFC 1662 [3], both from 1994, have so far provided most of the basis for implementation of such a transport. Recent needs, proposals and standards have recently progressed beyond these two RFCs, as well as identified limitations of the methods described in the aforementioned RFCs for effective implementation at very high data rates in the vicinity of 10 Gb/s (STS-192c/OC-192). This document (A) attempts to consolidates (sometimes by reference) current standards and current practice in transport of PPP over SONET; (B) attempts to document current viewpoints that share some degree of consensus in recent developments in this area and (C) proposes for STS-192c/OC-192 transmission a simple, efficient and robust 32-bit-word-oriented framing mechanism based on HDLC, called HDLC-32, which is significantly more conducive to efficient implementation at high data rates in the vicinity of 10 Gb/s (STS-192c/OC-192) than the HDLC framing currently used at lower rates. Merchant Expires May 1999 Page 1 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 Table of Contents 1. INTRODUCTION 1.1 Conventions 2. GENERAL ASPECTS OF PPP OVER SONET 2.1 SONET vs. SDH 2.2 Appicable SONET Rates 3. RATE-SPECIFIC MAPPING INFORMATION 3.1 STS-1 (AU-3) 3.2 STS-3c (AU-4) 3.3 STS-12c (AU-4-4c) 3.4 STS-48c (AU-4-16c) 3.5 STS-192c (AU-4-64c) 3.6 Rates above STS-192c (above AU-4-64c) 4. HDLC-LIKE 32-BIT FRAMING (HDLC-32) FOR STS-192C 4.1 Basic HDLC-32 Frame Format 4.2 Adaptation of 8-Bit Packet Payload to 32-Bit HDLC-32 Word 4.3 Flag Sequences (Flag0-Flag3) 4.4 Escape Sequence (Esc32) and Escape Mechanism 4.5 Frame Check Sequence (FCS-32) 4.6 HDLC Payload Scrambling (SCR-29) 4.7 Link Configuration Options for HDLC-32 Framing 4.8 Summary of Processing Sequence for HDLC-32 Framing 5. SECURITY CONSIDERATIONS 5.1 Emulation of SONET framing or subversion of SONET scrambler 5.2 Bandwidth Reduction by Intentional Transmission of Characters or Sequences Requiring Transparency Processing APPENDICES A. FCS-32 Calculation and Transmission Sequence Example B. SCR-29 Calculation and Transmission Sequence Example C. SCR-43 Calculation and Transmission Sequence Example D. Mapping of PPP over DS3 REFERENCES ACKNOWLEDGEMENTS AUTHOR'S ADDRESS Merchant Expires May 1999 Page 2 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 1. INTRODUCTION This specification provides information for transport of PPP packets over a SONET interface. There have been significant developments in the past few years as this technology has matured, and there is a need to document current practice as well as prepare for future rates and technologies. 1.1 Conventions As much as possible, we will follow conventions currently in use in RFCs on this subject, e.g., - Binary and hexadecimal numbers in this document are listed in MSB to LSB order, reading from left to right. 2. GENERAL ASPECTS OF PPP OVER SONET PPP is the accepted method of carrying IP traffic (and potentially other multi-protocol datagrams) over SONET/SDH links. 2.1 SONET vs. SDH Real differences between SONET and SDH (other than terminology) are minor; for the purposes of encapsulation of PPP over SONET, they are inconsequential or irrelevant. Hence, we use the expression "PPP over SONET" to refer equivalently to "PPP over SDH," and similarly for other expressions. For the convenience of the reader, we list the equivalent terms below: SONET SDH --------------------------------------------- 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 2.2 Applicable SONET Rates As suggested above, the only currently supported frame rates are the following (note that the payload rates are lower, depending on the number of overhead and stuff bytes--see [4], [5], [6] for details): SONET/SDH Name Bit Rate -------------------------------- STS-1/STM-0 51.84 Mb/s STS-3/STM-1 155.52 Mb/s STS-12/STM-4 622.08 Mb/s Merchant Expires May 1999 Page 3 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 STS-48/STM-16 2.48832 Gb/s STS-192/STM-64 9.95328 Gb/s 3. RATE-SPECIFIC MAPPING INFORMATION 3.1 STS-1 (AU-3) PPP packets may be mapped into a SONET STS-1 payload in one of two ways: a) Into the payload of a DS3 signal, which is in turn mapped into an STS-1 payload via standard mappings defined in [4] and [5]. This is, strictly speaking, not a mapping of PPP into SONET, but a mapping of PPP into DS3, and hence is outside the scope of this document. However, since this is not documented elsewhere, the common practice as regards this mapping is described in Appendix D. b) Direct mapping into an STS-1 payload. Although this rate is not commonly use for direct mapping of PPP traffic (it is used primarily to carry DS3 traffic), it is included here for completeness. (Its SDH counterpart, the C-3 container, is furthermore not a popular structure in SDH environments for any payloads, direct mapped or otherwise.) The remainder of this Section 3.1 describes this mapping. 3.1.1 Packet Framing and Transparency Processing PPP Packets shall be encapsulated into a byte-oriented HDLC-like Framing as specified in RFC 1662, for the purposes of providing packet delineation, transparency of packet data, and error detection capability. 3.1.2 Mapping into SONET payload The PPP packets so encapsulated by HDLC-like Framing shall be mapped into an STS-1 payload (C-3 SDH container) using x^43+1 scrambling as specified in [7] and [8], and with the use of a Signal Label Byte (C2) value of 0x16 as also specified in those same references. 3.1.3 Link Configuration Options Link Configuration Options are as Specified in RFC 1619 and RFC 1662; those that are specific to the HDLC framing mechanism are summarized below: Option Default Alternative Values -------------------------------------------------------------- Address & Control Compression No Yes FCS size 16 bits None, 32 bits 3.2 STS-3c (AU-4) Merchant Expires May 1999 Page 4 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 3.2.1 Packet Framing and Transparency Processing PPP Packets shall be encapsulated into a byte-oriented HDLC-like Framing as specified in RFC 1662, for the purposes of providing packet delineation, transparency of packet data, and error detection capability. 3.2.2 Mapping into SONET payload The PPP packets so encapsulated by HDLC-like Framing shall be mapped into an STS-3c payload (C-4 SDH container) using x^43+1 scrambling as specified in [7] and [8], and with the use of a Signal Label Byte (C2) value of 0x16 as also specified in those same references. 3.2.3 Link Configuration Options Link Configuration Options are as Specified in RFC 1619 and RFC 1662; those that are specific to the HDLC framing mechanism are summarized below: Option Default Alternative Values -------------------------------------------------------------- Address & Control Compression No Yes FCS size 16 bits None, 32 bits 3.3 STS-12c (AU-4-4c) 3.3.1 Packet Framing and Transparency Processing PPP Packets shall be encapsulated into a byte-oriented HDLC-like Framing as specified in RFC 1662, for the purposes of providing packet delineation, transparency of packet data, and error detection capability. 3.3.2 Mapping into SONET payload The PPP packets so encapsulated by HDLC-like Framing shall be mapped into an STS-12c payload (C-4-4c SDH container) using x^43+1 scrambling as specified in [7] and [8], and with the use of a Signal Label Byte (C2) value of 0x16 as also specified in those same references. 3.3.3 Link Configuration Options Link Configuration Options are as Specified in RFC 1619 and RFC 1662; those that are specific to the HDLC framing mechanism are summarized below: Option Default Alternative Values -------------------------------------------------------------- Address & Control Compression No Yes FCS size 32 bits None, 16 bits Merchant Expires May 1999 Page 5 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 3.4 STS-48c (AU-4-16c) 3.4.1 Packet Framing and Transparency Processing PPP Packets shall be encapsulated into a byte-oriented HDLC-like Framing as specified in RFC 1662, for the purposes of providing packet delineation, transparency of packet data, and error detection capability. 3.4.2 Mapping into SONET payload The PPP packets so encapsulated by HDLC-like Framing shall be mapped into an STS-48c payload (C-4-16c SDH container) using x^43+1 scrambling as specified in [7] and [8], and with the use of a Signal Label Byte (C2) value of 0x16 as also specified in those same references. 3.4.3 Link Configuration Options Link Configuration Options are as specified in RFC 1619 and RFC 1662; those that are specific to the HDLC framing mechanism are summarized below: Option Default Alternative Values -------------------------------------------------------------- Address & Control Compression No Yes FCS size 32 bits None, 16 bits 3.5 STS-192c (AU-4-64c) 3.5.1 Packet Framing and Transparency Processing PPP packets shall be encapsulated into a 32-bit word-oriented HDLC-like Framing (HDLC-32) as specified in Section 4 of this document, for the purpose of providing packet delineation, transparency of packet data, adaptation from a byte-oriented structure to a 32-bit word-oriented structure, and error detection capability. 3.5.2 Mapping into SONET payload The PPP packets so encapsulated by the HDLC-32 protocol shall be mapped into an STS-192c payload (C-4-64c SDH container) using x^43+1 scrambling as specified in [7] and [8], with the additional constraint that data be aligned on 32-bit boundaries within the SONET frame, as described in Section 3.5.4. It is recommended that a different Signal Label Byte (C2) value be used for the mapping of HDLC-32 framed signals into SONET payloads than the value of 0x16 used for HDLC-framed signals [7][8]. A value of 0x17 (for example) may be submitted for standardization to ANSI as and when this proposal reaches the appropriate level of maturity. Merchant Expires May 1999 Page 6 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 3.5.3 Link Configuration Options Link Configuration Options that are specific to the HDLC-32 framing mechanism are specified in Section 4.7. 3.5.4 Word Alignment within SONET payloads Each word of an HDLC-32 frame MUST be aligned to a 4-byte boundary within the STS-192c frame. The most significant byte of an HDLC-32 word shall be the earliest byte transmitted, followed by the 2nd-most significant byte, the 3rd-most significant byte and finally the least significant byte. (Although SONET/SDH provides, in theory, an octet-based transport interface to its upper layers, the granularity of processing is, in fact, at a much wider data width. For example, for an STS-192c signal, each of the 9 rows of the SONET frame comprise 192x3 bytes of Section/Line overhead, followed by 192x87 bytes of Synchronous Payload Envelope (SPE). The start of payload within an SPE may occur only at a byte position of 192xN+64 within any row of the SPE, where 0 <= N <= 86. Pointer actions for STS-192c payloads shift the payload in multiples of 192 bytes. In general, for an STS-Mc payload, the lowest common denominator for possible start of payload positions within the STS-M frame is M/3 bytes. For STS-192c, this is 64 bytes--much greater than the 4 bytes specified above. Hence, it is always possible to align to 4-byte boundaries (down to STS-12c).) 3.6 Rates above STS-192c The next higher rate above STS-192c is expected to be STS-768c. The framing of packets and mapping into payloads at this payload rate is for further study. If technology permits reasonable hardware implementations with a 32-bit wide data path, then HDLC-32 will be a candidate for packet framing at this rate. Otherwise, we recommend an extension of HDLC-32 to a wider word format such as HDLC-64. 4. HDLC-LIKE 32-BIT FRAMING (HDLC-32) FOR STS-192C The following HDLC-32 frame format for mapping packet data (e.g., PPP) into SONET payloads at the STS-192c rate is proposed based on the following criteria: a. Permitting simpler processing of data at high rates (STS-192c) by using wider processing units than 8-bits (hence a deviation from byte-oriented HDLC framing), since 8-bit processing granularity greatly complicates hardware implementations at these rates; b. Retaining the general nature of HDLC processing, which does not constrain transmission to any particular packet format, nor requires detailed knowledge of the packet structure such as packet length; c. Retaining the familiar and well-understood concepts of byte-oriented HDLC processing as much as possible, to avoid introducing unproven concepts and their associated risks; d. Use of a framing mechanism that minimizes or at least bounds the number of adjacent packets that may be lost if there are errors in a Merchant Expires May 1999 Page 7 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 packet; e. Recognizing the established nature of byte-wide HDLC processing for all SONET rates up to and including STS-48c (hence we do not propose using HDLC-32 for rates of STS-48c and below, even though it could be used to advantage at some of these lower rates); f. Eliminating configuration options as much as possible, to simplify link setup and compatibility issues, and eliminate unnecessary hardware and software complexity associated with the need to support multiple modes of operation. 4.1 Basic HDLC-32 Frame Format The HDLC-32 frame format is described in units of 32-bit words. An HDLC-32 frame starts with a flag word, which may be one of four flag words Flag0, Flag1, Flag2 or Flag3, which are further described in Section 4.3. It is directly followed by a variable number of Data words, after which is an FCS-32 word and then one or more flag words. This is illustrated in the figure below. -------------------------------------------------------------- | Flag | Data | Data | ... | Data | FCS-32 | Flag | -------------------------------------------------------------- The occurrence of any of the four flag words within the data is replaced by a 2-word combination consisting of a special escape word named Esc32 and a transformed version of the flag word. The occurrence of the escape word itself within the data is similarly replaced by a 2-word combination comprising Esc32 followed by a transformed version of Esc32. Details of this escape mechanism are provided in Section 4.4. To reduce the likelihood of intentional insertion of multiple Flag or Escape words within the data by a malicious user (to effect bandwidth depravation), the contents of the entire packet between (but not including) Flag bytes shall be scrambled by a self-synchronous scrambler. Details of this scrambler are provided in Section 4.6. 4.2 Adaptation of 8-Bit Packet Payload to 32-Bit HDLC-32 Word HDLC-32 adapts a sequence of bytes (an octet stream) to a stream of 32-bit words. For a complete description of this adaptation, it is necessary to specify (a) the order of packing octets into words and (b) the handling of a byte sequence that is not a multiple of 4 bytes. Octets within an HDLC-32 word are packed (or unpacked) starting with the most significant byte first (which is also the one first transmitted on the SONET line) and ending with the least significant byte of the word. If the length of the byte stream to be encapsulated within an HDLC-32 frame (after transparency processing) is not a multiple of 4 bytes, it is padded with 1, 2 or 3 all-zero bytes so that the length is forced to be the next larger multiple of 4 bytes. These pad bytes are included in the FCS-32 calculation, and the number of pad bytes (0, 1, 2 or 3) are encoded in the choice of the corresponding Flag sequence (Flag0, Flag1, Flag2 or Flag3, respectively) that immediately follows the FCS-32 word Merchant Expires May 1999 Page 8 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 for that packet. 4.3 Flag Sequences (Flag0-Flag3) The flag word immediately following the last word of a packet (the FCS-32 word), may be any one of the 4 flag words Flag0, Flag1, Flag2 or Flag3, depending on whether the word immediately preceding the FCS-32 word has 0, 1, 2 or 3 all-zero pad bytes, respectively. This single flag word may serve as the starting flag word for the following packet if one is available to be transported immediately. Otherwise, the sequence of flag words transmitted shall continue in the sequence Flag0, Flag1, Flag2, Flag3 in a modulo-4 fashion, to provide inter-packet word fill whenever there are no packets available to be transported over the SONET interface. (The receiving end shall accept any of the 4 flag values as inter-packet fill without attaching any special significance to which of the 4 values was received, other than as described above for the first flag word following the FCS-32 word). Aside from avoiding repeating bytes or combinations known to be likely to occur in data, there are no special criteria believed necessary for the choice of Flag bytes. We select the following values, since they are (a) sufficiently "random" in appearance that they have no particularly known likelihood of appearing with undue frequency in data (b) have no repeating bytes and (c) have an average 1s-density of 50%. Flag0=E7 81 CA 34 Flag1=E7 81 CA 35 Flag2=E7 81 CA 36 Flag3=E7 81 CA 37 4.4 Escape Sequence (Esc32) and Escape Mechanism The Escape sequence Esc32 shall be Esc32=EB 8D C6 38 (which happens to be the Flag0 sequence exclusive-ored with the hexadecimal sequence 0x0C0C0C0C). Any occurrence in the transmit direction (from the system interface towards the SONET PHY interface) of any one of the five sequences {Flag0, Flag1, Flag2, Flag3, Esc32} on a 32-bit word boundary after FCS-32 calculation and HDLC-32 payload scrambling shall be replaced by a two word sequence comprising: (a) The Esc32 sequence followed by (b) the 32-bit sequence to be escaped exclusive-ored with the hexadecimal sequence 0x20202020. In the receive direction (SONET PHY interface towards the system interface), any occurrence of the Esc32 sequence shall be removed and the following word exclusive-ored with the hexadecimal sequence 0x20202020. Merchant Expires May 1999 Page 9 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 The one exception to the above is the abort sequence (Esc32 Flag0) which when transmitted indicates a packet known to be errored or which otherwise should be aborted by the receiver, and which when received indicates that the contents of the packet received thus far are invalid, and processing of that packet be aborted. 4.5 Frame Check Sequence (FCS-32) The FCS-32 word is calculated as follows: a. it is based on the polynomial x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1 b. it is calculated identically to the manner specified in RFC 1662 for PPP in HDLC-like framing, i.e., with the data order into the CRC calculator from most-significant byte to least-significant byte and from least-significant bit to most-significant bit within each such byte. 4.6 HDLC-32 Data Scrambling (SCR-29) The contents of all words between (but exclusive of) the two flag words that delineate a packet shall be scrambled after the FCS-32 is inserted but before transparency processing is performed. A self-synchronizing scrambler shall be used that shall be disabled (while retaining its internal state) between packets. The specific scrambler is for further study, but we tentatively propose the self-synchronizing scrambler corresponding to the polynomial x^29+1. This scrambler is intended to provide protection from possible malicious denial of service attacks by the sending of repeated sequences of flag or escape codes within the packet data, which could result in halving the effective bandwidth of the link. This scrambler operates independently of, and in addition to the self-synchronous x^43+1 SONET payload scrambler specified in [7] and [8] and the x^7+x^6+1 frame-synchronous SONET frame scrambler specified in [4], [5] or [6]. Appendix B provides details of the calculation in particular to clarify the bit ordering of the calculation and the insertion of the resulting SCR-29 sequence. 4.7 Link Configuration Options for HDLC-32 Framing There are no link configuration options that are specific to the HDLC-32 framing. Settings that might conceivably be programmable are nonetheless all fixed to their only single permissible value per the table below: Traditional or Possible Parameter Fixed Setting ----------------------------------------------------- Address & Control Compression Yes FCS size 32 bits HDLC-32 Data Scrambling Active Yes SONET Payload Scrambling Active Yes Merchant Expires May 1999 Page 10 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 4.8 Summary of Processing Sequence for HDLC-32 Framing The following summarizes the sequence of processing stages for HDLC-32 processing in the Receive (from the PHY layer to the System side interface) and Transmit (from the System side interface to the PHY layer) directions, respectively. They are entirely analogous to their counterpart functions for byte-oriented HDLC processing. 4.8.1 Receive Direction The sequence of operations is as follows: 1. Extraction of payload of SONET SPE using 32-bit boundaries; 2. Descrambling of SONET SPE payload using x^43+1 self-synchronizing descrambler 3. HDLC-32 Frame Delineation using Flag0-Flag3 sequences 4. Reverse Transparency Processing (including packet Abort processing) 5. HDLC-32 Data descrambling using x^29+1 [provisional] self-synchronizing descrambler 6. FCS-32 CRC processing (including discarding of errored HDLC-32 frames) 7. Adaptation of 32-bit-wide data from the PHY interface to 8-bit-wide data on the System interface (including pad removal) 4.8.2 Transmit Direction The sequence of operations is as follows: 1. Adaptation of 8-bit-wide data from the System interface to 32-bit-wide data on the PHY interface (including pad insertion) 2. FCS-32 CRC calculation and insertion 3. HDLC-32 Data scrambling using x^29+1 [provisional] self-synchronizing scrambler 4. Transparency processing (escape of Flag and Escape sequences) 5. HDLC-32 Frame creation using Flag0-Flag3 sequence insertion 6. Scrambling of SONET SPE payload using x^43+1 self-synchronizing scrambler 7. Insertion of payload into SONET SPE on 32-bit boundaries. 5. SECURITY CONSIDERATIONS The following are known security considerations in the transport of HDLC or HDLC-32 frames over SONET. 5.1 Emulation of SONET framing or subversion of SONET scrambler This well-documented phenomenon [9][10] involves the accidental, or more likely intentional, attempt to cancel the SONET scrambling, which is possible when one has access to several consecutive bytes of the SONET payload. Two of the possible attack mechanisms involve (a) intentional replication of the SONET framing pattern within the data or (b) Merchant Expires May 1999 Page 11 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 insertion of consecutive all-zeros in the data, which may cause a loss of signal declaration or degraded timing recovery at the downstream receiver. For HDLC framing, this is addressed by [7] and [8] and involves scrambling the entire SONET payload (i.e., excluding POH and fixed stuff bytes) with a self-synchronizing x^43+1 scrambler. For HDLC-32 framing, the identical mechanism is used, i.e., the SONET payload is scrambled with an x^43+1 self-synchronizing scrambler. Additional protection is provided in HDLC-32 framing by the x^29+1 [tentative] pre-scrambling of the packet data prior to encapsulation in the HDLC-32 frame (see Section 5.2). 5.2 Bandwidth Reduction by Intentional Transmission of Characters or Sequences Requiring Transparency Processing The basic phenomenon, documented in [9] and [10], involves intentional transmission of long strings of flag or control-escape characters which expand the bandwidth usage of the link by a factor of approximately 2 over a "random" or non-malicious sequence of "normal" data, since each such character needs to be escaped. For HDLC framing, this possibility is inherent to the HDLC framing mechanism; as such, the possibility for such malicious usage exists in most HDLC implementations and this is not specific to transport over SONET. HDLC-32 framing, as proposed above, addresses this situation in several ways. The most powerful of them is the scrambling of the data words prior to encapsulation within the HDLC-32 frame, with an independent self-synchronizing scrambler that does not reset from one packet to the next. Hence, in the presence of traffic on the link in addition to the malicious traffic (the only case of interest), the intervening packets would essentially eliminate the ability of a single malicious user to transmit sustained data patterns that would descramble to long sequence of the special byte sequences that need escaping. In addition, the use of 32-bit Flag and Escape sequences makes the devising of such a scheme considerably more difficult. Lastly, the 32-bit-based delineation mechanism will randomize the location of such a pattern to 1 of 4 possible byte locations within the 32-bit word, only one position of which will cause the deleterious effect (owing to the 32-bit-based SONET payload insertion/extraction). Thus, even in the exceedingly unlikely event of someone successfully sending data that would descramble to the sequences requiring escaping on a sustained basis, the average rate reduction would be only 1/4 x 50%, or 12.5%, even for this strictly hypothetical scenario. Merchant Expires May 1999 Page 12 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 APPENDIX A. FCS-32 Calculation and Transmission Sequence Example [To be provided] APPENDIX B. SCR-29 Calculation and Transmission Sequence Example [To be provided] APPENDIX C. SCR-43 Calculation and Transmission Sequence Example [To be provided] APPENDIX D. Mapping of PPP over DS3 [To be provided] REFERENCES [1] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)," RFC 1661, July 1994. [2] W. Simpson, Editor, "PPP over SONET/SDH," RFC 1619, May 1994. [3] W. Simpson, Editor, "PPP in HDLC-like Framing," RFC 1662, July 1994. [4] ITU-T, "Network Node Interface for the Synchronous Digital Hierarchy," G.707, March 1996. [5] Bellcore, "SONET Transport Systems: Common Criteria," GR-253-CORE, 1998. [6] American National Standards Institute, "Synchronous Optical Network (SONET)--Basic Description including Multiplex Structure, Rates and Formats," T1.105-1995. [7] American National Standards Institute, "Synchronous Optical Network (SONET)--Payload Mappings," T1.105.02-1998(?). [8] ITU-T Study Group 15, "Living List for the Revision of G.707 by Q.11/15," Report of WP 3/15, Annex 10, February 1998. [9] J. Manchester et al, "IP over SONET," IEEE Communications Magazine, May 1998. [10] [Several Internet Drafts, now expired] Merchant Expires May 1999 Page 13 Internet Draft PPP Over SONET from STS-1 to STS-192c Nov 1998 ACKNOWLEDGEMENTS Dr. Gary Martin of Cimaron Communications Corporation provided suggestions, insight and review for several aspects of this document. AUTHOR'S ADDRESS Shahrukh Merchant Cimaron Communications Corporation 200 Brickstone Square Andover, Massachusetts 01810 U.S.A. Phone: +1 978 623-0009 Ext. 3020 Fax: +1 978 623-0024 E-mail: smerchant@cimaron.com Merchant Expires May 1999 Page 14