Network Working Group W A Simpson [DayDreamer] Internet Draft expires in six months August 1998 Applicability Statement for PPP over SONET/SDH draft-ietf-pppext-sonet-as-00.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 (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 AS SONET/SDH August 1998 1. Applicability Statement PPP over SONET/SDH is intended for those implementations that desire the PPP encapsulation over high speed private point-to-point links, such as intra-campus single-mode fiber that may already be installed and unused. Some installations have attempted to use commercial long-distance carriers. Because these services were installed and tested for voice, and carriers have bid least-cost components that do not meet the needs of high speed data services, numerous interoperability problems have arisen. The profile identifies many of these pitfalls, and recommends practices that avoid them. 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. 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- Simpson expires in six months [Page 1] DRAFT PPP AS SONET/SDH August 1998 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. SONET/SDH Profile "The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model." [Tanenbaum] "The problem with standards is the last 's'." [Kleinrock] SONET and SDH were "standardized" by at least 4 different organiza- tions. - Bellcore developed the original SONET specification, and has issued significantly reorganized and revised documents in 1991 and 1995. According the [SONET] Revision History: "Since TR- TSY-000253, Issue 1, there have been so many revisions to this material that the use of change bars is impractical." - ANSI (T1X1 and T1M3) has a separate series of documents, that are continuously revised, and strongly influenced by a single vendor. - ETSI also has a separate series of documents, but has greatly ben- efited by close attention to detail, and coordination with CCITT/ITU-T. - CCITT (since renamed ITU-T) published the SDH specifications in 1988. Minor revisions occurred in 1993 and 1994, with a major reorganization in 1996. The latter organizations have not maintained consistent naming of fields and payloads, have made conflicting changes and extensions, and have been careless about conformity and backward compatibility Simpson expires in six months [Page 2] DRAFT PPP AS SONET/SDH August 1998 with existing deployment. This specification was developed utilizing carefully chosen documents that reflect a particular point in time, and that correspond to extant fielded implementations. Where naming conventions are incon- sistent, or conflict with other network usage of the same terms, a simpler taxonomy is chosen. To promote interoperability, this document provides a condensed description of basic SONET/SDH functionality, together with some of the recent changes and their relevance, and a profile of recommended practices. 2.1. Bit Transmission All bytes are transmitted Most Significant Bit first. Discussion Care must be taken when converting from other media, such as serial links and ethernet, that are transmitted Least Significant Bit first. 2.1.1. Electrical Bits SONET specifies an optional electrical transmission capability using a pair of 75 Ohm coaxial cables, one for each direction. At 156 Mbps, Coded Mark Inversion (CMI) is specified. single bits - - --- | | | | | | | | | | | | | | | | - - --- "0" "0" "1" "1" Simpson expires in six months [Page 3] DRAFT PPP AS SONET/SDH August 1998 A1A2 pattern --- --- - --- - - - - --- - - - | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- --- - --- - - - --- - - - - 1 1 1 1 0 1 1 0 0 0 1 0 1 0 0 0 or its inverse. Lower signal rates (52 Mbps) use Bipolar with Three-Zero Substitution (B3ZS). These rates are not relevant to PPP over SONET/SDH (see "Physical Layer Requirements"). Discussion There are no recent changes that might affect interoperability. At the time of writing, there are no reported router implementa- tions using CMI electrical transmission to directly feed electro- optical section or line terminating equipment. Typically, pseudo-ECL signals over very short inter-component dis- tances are used to drive the optics with the same encoding pattern as the optical bits. Recommendations As the cost of optical interfaces and cabling has rapidly decreased, the use of optical transmission is preferred, even for moderately short intra-office distances. For electrical intra-office router interconnection, use of 100baseT (or future gigabit ethernet) is preferable to PPP over SONET/SDH. 2.1.2. Optical Bits SONET specifies an optical transmission capability using a pair of fibers, one for each direction. The use of bi-directional fiber transmission is "for further study". The optical line coding used for all system interfaces is binary Non- Return-to-Zero (NRZ). The convention adopted for optical logic level is Simpson expires in six months [Page 4] DRAFT PPP AS SONET/SDH August 1998 logical 1 -- emission of light logical 0 -- no emission of light single bits --- | | | | --- "0" "1" A1A2 pattern --------------- ------- --- --- | | | | | | | | | | | | | | --- ----------- --- ----------- 1 1 1 1 0 1 1 0 0 0 1 0 1 0 0 0 To simplify the development of compatible multi-vendor systems, it is desirable to define a relatively small set of categories and corre- sponding optical interface specifications. Short Reach (intra-office) SONET optical sections having loss budgets of 0 dB to 7 dB; alter- natively, SDH interconnect distances less than 2 kilometers. Intermediate Reach (short haul inter-office) SONET optical sections having loss budgets of 0 dB to 12 dB; alternatively, SDH interconnect distances up to 15 kilometers. Long Reach (long haul inter-office) SONET optical sections having loss budgets of 10 dB to 28 dB; alternatively, SDH interconnect distances up to 40 kilometers at 1310 nanometers, and up to 60 kilometers at 1550 nanometers. Unfortunately, the current proliferation of specifications falls far short of this goal, having different category definitions (as seen above) and more than 20 total pages of parameter tables. Discussion There are too many recent changes that impede interoperability to detail in this short overview. Care must be taken when comparing signals from other media, such Simpson expires in six months [Page 5] DRAFT PPP AS SONET/SDH August 1998 as high speed serial links, where "no signal" is "logical 1". At the time of writing, the majority of reported implementations use "intermediate" level 1310 nanometer optics with single mode fiber. This can accommodate multi-mode fiber and short reach (intra-office) interconnection with the addition of transmitter attenuation. Upgrading to future higher speeds would be facilitated by installing single mode fiber instead of multi-mode fiber. Recommendations The greatest interoperability and economies of scale will be achieved with deployment of a few general interface choices, all for single mode fiber: Intermediate Reach equipment at 1310 nanometers for each STM line speed. Long Reach equipment at 1550 nanometers for 2 Gbps and above. 2.1.3. Bit Scrambling Optical interface signals use NRZ binary line coding (described above). A series of repeated bits will not feature any signal level transitions. Such transitions (zeros to ones and ones to zeros) are needed at the receiver to dynamically correct bit timing variance for line rate clock recovery. Therefore, although it has no effect on random data, the signal is scrambled against the possibility that a very long series of ones or zeros might naturally occur in the trans- mitted bit stream. Electrical interface signals use line encoding (B3ZS and CMI) that assures adequate transitions. Scrambling is not needed. However, they are also scrambled for consistency between the electrical and optical component interfaces. In both cases, a 7-bit linear feedback shift register (LFSR) is iden- tically applied at the transmitter and receiver. The sequence of bits from the x**7 stage of the LFSR is exclusive-or'd (in most sig- nificant bit order) with the output bits before transmission, and with the corresponding input bits after signal recovery. The first row of the STM-N transmission block overhead (N * 9 bytes described later) is not scrambled. The 7-bit LFSR state is reset to bit value 1111111 (127 decimal) on the most significant bit of the Simpson expires in six months [Page 6] DRAFT PPP AS SONET/SDH August 1998 byte following the block overhead. The scrambler runs continuously from that bit onward, throughout the remainder of the transmission block. The generating polynomial for the LFSR is x**7 + x**6 + 1. The resulting 127-bit sequence repeats in a 127 byte stream (shown in hex): fe 04 18 51 e4 59 d4 fa 1c 49 b5 bd 8d 2e e6 55 fc 08 30 a3 c8 b3 a9 f4 38 93 6b 7b 1a 5d cc ab f8 10 61 47 91 67 53 e8 71 26 d6 f6 34 bb 99 57 f0 20 c2 8f 22 ce a7 d0 e2 4d ad ec 69 77 32 af e0 41 85 1e 45 9d 4f a1 c4 9b 5b d8 d2 ee 65 5f c0 83 0a 3c 8b 3a 9f 43 89 36 b7 b1 a5 dc ca bf 81 06 14 79 16 75 3e 87 12 6d 6f 63 4b b9 95 7f 02 0c 28 f2 2c ea 7d 0e 24 da de c6 97 73 2a Discussion There are no recent changes that might affect interoperability. The scrambling mechanism is defective in a packet transmission context, where adjacent bytes are sequentially related. Appar- ently, the short polynomial assumed unrelated data that is obtained from DS0 through DS3 circuits. This is characteristic for legacy technology such as Asynchronous Transfer Mode (ATM), interleaved virtual circuits, or voice traffic. Since the feedback is based on the internal state of the LFSR, and is not dependent on its interaction with previous bytes, any sub- set of the bit sequence that exactly matches the phase of the LFSR will generate a series of zeros. The bitwise inverse of the bit sequence will generate a series of ones. This effect is not limited to direct PPP over SONET/SDH. Any packet oriented transmissions carried by SONET/SDH without inter- leaving would have the same result. Moreover, although the 127 byte stream may have been appropriate for the original STS-1 (90 bytes per row), this length is mani- festly insufficient for STM-N (N * 270 bytes per row). Finally, the most egregious flaw in this part of the SONET/SDH specification, the number of bits permitted without a transition is not explicitly defined. Instead, the value is implicitly derived from the fixed length scrambling sequence versus the vari- able length Loss of Signal (LOS) condition based on the link speed (described later). Simpson expires in six months [Page 7] DRAFT PPP AS SONET/SDH August 1998 Note that the complete scrambling byte stream cannot be repre- sented in a valid PPP packet. The pair "fd 03" is not conformant, limiting the maximum sequence without a transition to 127 bytes. Recommendations Packet transmissions carried at rates less than 156 Mbps MUST be interleaved under the VT/TU scheme (see "Physical Layer Require- ments"). This is consistent with prior use of bit-synchronous HDLC (and Frame Relay) over DS0 through DS3 circuits. Line rate clock recovery SHOULD be sufficiently stable to with- stand periods of 1016 repeated one or zero bits (127 bytes). 2.1.4. Loss of Signal (LOS) To detect a failure that occurs at the transmitter (such as laser failure) or within the transmission facility (such as a fiber cut), all incoming signals (optical and electrical) are monitored for Loss of Signal (LOS) before descrambling, by detecting a lack of suffi- cient signal level transitions to ensure accurate line rate clock recovery. No transitions on the incoming signal is not considered LOS when the condition lasts 2.3 microseconds or less, and is considered LOS when the condition lasts 100 microseconds or more. The treatment of no transitions lasting between 2.3 microseconds and 100 microseconds for the purpose of LOS detection is not specified (left to the choice of the equipment designer). For electrical (B3ZS and CMI) interfaces, the no voltage transitions condition is easily distinguished from an "all-zeros pattern". For SONET optical (and component) interfaces, the no light pulses condition corresponds to an "all-zeros pattern". For testing SONET compliance with the LOS detection requirement, it suffices to apply an "all-zeros pattern" lasting at most 2.3 microseconds, and to apply an "all-zeros pattern" lasting at least 100 microseconds. Optical equipment shall enter the LOS state within 100 microseconds of the onset of the incoming "all-zeros pattern." For SDH optical (and component) interfaces, equipment may also indi- cate LOS within 3 milliseconds of the time the received signal level drops below an implementation-determined threshold (based on receiver sensitivity). The threshold should be selected such that LOS will not be indicated while the Bit Error Rate (BER) is still acceptable. For SDH, the BER is defined to be 1 in 10**(-3). Simpson expires in six months [Page 8] DRAFT PPP AS SONET/SDH August 1998 Note that the secondary method is in addition to the primary method, not in lieu of it, and is not required to be implemented in SONET installations. The equipment shall terminate the LOS condition when the incoming signal has two consecutive valid block alignment patterns (described later), and during the intervening time (125 microseconds) sufficient transitions prevent another LOS defect. For trouble isolation purposes, especially for intermittent failures, it is important to distinguish between LOS and other signal failure conditions, such as Loss of Frame (LOF). Discussion There are significant differences between SONET, ANSI, and SDH; SDH does not describe the primary method of detection. Circa 1994, this resulted in the addition of the secondary method to SONET. There is no explicit requirement given for the "all-ones pattern" that would indicate a stuck clock or laser transmitter. The same difficulty with lack of transitions will apply. There is no rationale given for the selection of 2.3 us and 100 us. Presumably, 100 us was chosen to allow sufficient variance between 125 us block alignment patterns. However, 100 us will cause multiple errors in the block overhead (described later), while 2.3 us is too short to cause any significant damage. The wide disparity between 2.3 us and 100 us, and leaving the error treatment to the vendor, has caused many interoperability problems. Incorrect LOS values as low as 1 +-0.750 us have been discovered. Typical values for valid designs are 20 +-3 us, and 26 +-1 us. No values higher than 30 us have been found. Line rate clock stability has been a related interoperability problem. Early 156 Mbps implementations were very robust, and could handle periods of 2,000 bits with no transitions. Some sam- ple and/or low quality implementations have not been as robust; failure has been noted as low as 72 to 80 bits without transi- tions. Simpson expires in six months [Page 9] DRAFT PPP AS SONET/SDH August 1998 Recommendations Using the minimum and maximum specification of LOS, line rate clock recovery MUST be sufficiently stable to withstand periods of repeated one or zero bits: Mbps min bits max bits 156 358 15,552 622 1,431 62,208 2,488 5,724 248,832 Implementations compatible with this specification SHOULD observe a stricter range of LOS detection, between 13.89 us and 27.26 us: Mbps min bits max bits 156 2,161 4,240 622 8,641 16,960 2,488 34,561 67,840 The lower limit affects no more than one row of overhead, while the upper limit includes at least one row of overhead. When a circuit path is divided into multiple line sections, the LOS is not propagated end to end. A hidden section can fail inde- pendently. Therefore, the LOS indication is only advisory, and the (possibly improperly) decoded signal bits MUST be passed to the next section. The framed PPP packet FCS is used to detect the failure. Some SONET framers provide a test feature to send an "all-zeroes pattern" (post scrambling) that forces the LOS alarm downstream. Alternatively, the pattern can be simulated with software. This SHOULD be used to test for compatible equipment during the instal- lation of the circuit, by generating progressively longer zero patterns, to verify that the circuit meets the requirements of this profile. 2.2. Block Transmission SONET/SDH transmits each block at precise 125 microsecond intervals. This corresponds to the traditional 4 kHz voice digital sampling rate used for DS0. Each block is divided into 9 logical "rows". For "concatenated" STS/STM, each row consists of some multiple of 270 byte "columns". Simpson expires in six months [Page 10] DRAFT PPP AS SONET/SDH August 1998 Block transmission overhead is arranged into layers, which correspond to different equipment interfaces that might occur in the path of a single circuit. Although SONET and SDH use inconsistent terms, the layers have a general equivalence. SONET divides its Network Element (NE) interface overhead into Sec- tion (SOH), Line (LOH), and Path (POH). SDH has a corresponding Network Node Interface (NNI) overhead called Regenerator-Section (RSOH), Multiplex-Section (MSOH), and Path (POH). There are 3 rows of (Regenerator) Section Overhead (SOH or RSOH), and 6 rows of Line or Multiplex-Section Overhead (LOH or MSOH). 2.2.1. Block Overhead The STS-3c/STM-1 transmission block overhead consists of 9 byte columns at the beginning of each 270 byte row, with the remaining 261 bytes used for the data envelope(s). +----+----+----+----+----+----+----+----+----+---------- | A1 A1 A1 A2 A2 A2 J0 Z0 Z0 envelope +----+----+----+----+----+----+----+----+----+---------- | B1 ++ ++ E1 ++ ?? F1 ** ** envelope +----+----+----+----+----+----+----+----+----+---------- | D1 ++ ++ D2 ++ ?? D3 ?? ?? envelope +----+----+----+----+----+----+----+----+----+---------- | H1 H1# H1# H2 H2# H2# H3 H3 H3 envelope +----+----+----+----+----+----+----+----+----+---------- | B2 B2 B2 K1 ?? ?? K2 ?? ?? envelope +----+----+----+----+----+----+----+----+----+---------- | D4 ?? ?? D5 ?? ?? D6 ?? ?? envelope +----+----+----+----+----+----+----+----+----+---------- | D7 ?? ?? D8 ?? ?? D9 ?? ?? envelope +----+----+----+----+----+----+----+----+----+---------- | D10 ?? ?? D11 ?? ?? D12 ?? ?? envelope +----+----+----+----+----+----+----+----+----+---------- | S1 Z1 Z1 Z2 Z2 M1 E2 ** ** envelope +----+----+----+----+----+----+----+----+----+---------- ++ media dependent. ** reserved for national use. ?? reserved for future use, SHOULD be zero. Values relevant to this specification: Simpson expires in six months [Page 11] DRAFT PPP AS SONET/SDH August 1998 (A1) bit value 1111 0110 (f6 hex) (A2) bit value 0010 1000 (28 hex) (H1) and (H2) Each of the 3 consecutive pairs of H1H2 is taken as a 16-bit mask, with various combinations of bits determining the offset (in multiples of 3*N) to the start of the data envelope. An offset of 0 indi- cates that the envelope immediately follows the last H3 overhead byte. An offset of 522 indicates that the envelope immediately follows the last Z0 over- head byte in the next transmission block. When used for this specification, the second and third H1#H2# pairs are always bit value 1001 xx11 1111 1111 (93ff hex), indicating a "concatenated" envelope, where xx is ignored on receipt. Since the block is transmitted by row, the overhead columns are interspersed with envelope columns, complicating generation and recovery. An additional complication is added by the section-level bit scram- bling. Overhead bytes of the first row (A1, A2, J0, Z0) are not scrambled. Discussion J0 was formerly called C1. Z0 was formerly additional copies of C1, but these bytes are now reserved for national use. The xx bit values in H1# were originally 00 for SONET and 10 for SDH. These changes might affect interoperability between international facilities. The scrambler needs a reset signal to indicate the position of the beginning of the transmission block and length of the overhead. Failure of the reset signal timing could prevent recognition of the block. Teleopolists seem inordinately fond of groups of 3. This was evi- dent in early digital efforts (24 DS0 in T1), and continues into SONET/SDH (3 T3/E3 in STM-1). Note that all of the values, including 261 and 270, are divisible by 3. This does not scale well in a digital processing environment. Simpson expires in six months [Page 12] DRAFT PPP AS SONET/SDH August 1998 Recommendations Envelopes SHOULD be sent with the H1H2 offset of 522. However, every implementation MUST be prepared to receive a variable off- set. 2.2.2. Block Synchronization Timing alignment is detected by searching for (a subset of) the A1 and A2 overhead pattern. There are two levels of synchronization recovery. When synchronization has been lost for 3 milliseconds or more (or has never been achieved), long-term synchronization recovery requires detection of a minimum of eight (8) successive error-free A1 and A2 overhead patterns. The maximum recovery time is 3 milliseconds (24 error-free patterns). Once alignment has been achieved, short-term synchronization loss is declared when four (4) or more consecutive A1 and A2 pattern errors have been detected. The maximum detection time is 625 microseconds. The algorithm used shall be such that, under normal operation, a 10**(-3) Poisson distribution of bit errors will not cause a false loss indication more than once every 6 minutes. Recovery from a short-term synchronization loss requires detection of only two (2) successive error-free A1 and A2 overhead patterns. Any recovery circuitry is acceptable that achieves resynchronization within the 250 microsecond interval implied by this definition. Failure to obtain resynchronization within 24 blocks (3 milliseconds) results in a long-term synchronization loss declaration, called Loss of Frame (LOF). Discussion The SDH specification is incomplete, and is missing some time intervals. Conversely, SDH has a somewhat stricter requirement for resynchro- nization after a short-term loss; the algorithm used shall be such that, with a random signal, the probability for false recovery is no more than 10**(-5) per 250 microsecond interval. Simpson expires in six months [Page 13] DRAFT PPP AS SONET/SDH August 1998 Recommendations Because of the interaction between block synchronization detec- tion, termination of the Loss of Signal (LOS) condition, and the first row reset of the section-level bit scrambling, the detection circuitry MUST be independent (upstream) of the scrambler, and trigger the subsequent scrambler reset timing. 2.2.3. Envelope Overhead A series of envelopes appear within the transmission block. These envelopes float to allow precise timing alignment and jitter correc- tion as the payload is carried over the circuit path. The position of the envelope(s) head within the block is specified by the H1 and H2 pair(s). The envelope(s) tail can carry over into the next trans- mission block. The STS-3c/STM-1 Path Overhead (POH for both SONET and SDH) consists of a 1 byte column, with the remaining bytes used for the payload data. +----+--------- | J1 payload +----+--------- | B3 payload +----+--------- | C2 payload +----+--------- | G1 payload +----+--------- | F2 payload +----+--------- | H4 payload +----+--------- | Z3 payload +----+--------- | Z4 payload +----+--------- | Z5 payload +----+--------- Values relevant to this specification: (J1) Path Trace. Carries one byte at a time of a repeat- ing 64-byte fixed-length string (SONET) or a 16-byte E.164 number (SDH), so that a path receiving termi- nal can verify its continued connection to the Simpson expires in six months [Page 14] DRAFT PPP AS SONET/SDH August 1998 intended transmitter. (C2) Path Signal Label. Indicates the composition, con- struction and content of the envelope payload. (H4) Multipurpose Position Indicator. Used by specific payload mappings, such as Floating Virtual Tribu- tary. Since the envelope is transmitted by row, the path overhead columns are interspersed with payload columns, and the combination are inter- spersed with block overhead columns, complicating generation and recovery. Discussion The envelope payload provides the physical-layer interface for insertion of PPP encapsulated packets. The J1 16-byte E.164 number format is rarely applicable, as there is no voice circuit involved in packets. Neither have fielded implementations observed strict adherence to the 64-byte limita- tion. A widely used implementation has generated a string con- sisting of the following pattern, each line CRLF terminated: Remote hostname : sl-bb10 Remote interface: POS9 Remote IP addr : 127.255.255.255 Remote Rx(K1/K2): 00/00 Tx(K1/K2): 00/00 The C2 value is primarily informational. It is difficult to use for applying alternate processing for adjacent envelopes, as it occurs after two rows of the envelope have already been processed. Although there is no need for intermediate transit equipment to interpret the value, some equipment fails upon encountering an unrecognized value. At first glance this floating envelope may appear to be a highly efficient technique to avoid interface buffering of synchronized incoming data. Unfortunately, due to interspersing the overhead with the data, it is impossible to determine where the envelope begins until at least a third of the transmission block has been received. Also, the envelope head can begin much later in the same block, or even in the next block. An envelope tail can carry over into a block that is two blocks later than the H1H2 overhead that indi- cates its head. Simpson expires in six months [Page 15] DRAFT PPP AS SONET/SDH August 1998 Thus, in a packet switched network, no matter how fast the link speed, a minimum of 125 microseconds is added at every hop, and cut-through routing is difficult or impossible. Recommendations See [RFC-xxxx] "Physical Layer Requirements". 2.2.4. Envelope Ordering SONET and SDH differ in the ordering of envelope rows. Several schemes are described, including: J1 ... B3 ... C2 ... J1 ... B3 ... C2 ... J1 ... B3 ... C2 ... J1 ... J1 ... J1 ... B3 ... B3 ... B3 ... C2 ... C2 ... C2 ... J1 J1 J1 ... B3 B3 B3 ... C2 C2 C2 ... Another difficulty has been the interleaving of lower rate channels within envelopes. These are time division multiplexed. In the SONET and SDH specifications, much of the complexity is due to these multi-stage multiplexing schemes. Discussion After optical specifications, this has been the worst impediment to interoperability. As carriers have upgraded equipment to STS-3c/STM-1 and STS-12c/STM-4, some have merely reconnected older equipment with Simpson expires in six months [Page 16] DRAFT PPP AS SONET/SDH August 1998 coax (see "Electrical Bits"). This is often haphazard. Although this has no effect on voice, where each byte is a separate chan- nel, this is unacceptable for packets. Recommendations Higher data rate envelopes, and the bytes within envelopes, MUST be sequentially ordered by row. SDH VC-3/VC-4/VC-4-Xc ordering MUST be supported. Envelope data MUST be carried from source to sink in sequential order. That is, bytes inserted in the order "1234" MUST arrive in the same order "1234". At the current setup and monthly charges of hundreds of thousands of US Dollars, installations can insist that equipment be care- fully configured, or will need to find an alternative carrier. 2.2.5. Payload Insertion Various ordering schemes differ only in the location of duplicate POH. These redundant POH bytes are specified as "fixed stuff", and the values are not examined. For example, in the previous section, the latter schemes interleave the redundant POH bytes throughout the row (VC-3/VC-4), or concate- nate the redundant POH bytes at the beginning of the row (VC-4-Xc). Recommendations See [RFC-xxxx] "The Data Link Layer". The specification finesses the issue by filling the "fixed stuff" with packet data. This make VC-4 and VC-4-Xc identical with respect to packet processing. 2.2.6. Protection Switching SONET provides Automatic Protection Switching (APS), also known as the SDH Multiplex Section Protection Function (MSP), to switch from one circuit to another spare circuit whenever a problem is detected. This switch can take place based on Signal Fail (SF), Signal Degrade (SD), or by manual intervention. Once switching is initiated, it can take up to 50 milliseconds to complete the switch. Signal Fail (SF) is defined as LOS, LOF, BER exceeding 10**(-3), and various other error conditions. Simpson expires in six months [Page 17] DRAFT PPP AS SONET/SDH August 1998 Signal Degrade (SD) is defined as BER exceeding a user selectable range from 10**(-5) to 10**(-9). The protection switch applies to all circuits in one direction simul- taneously. Bidirectional switching is optional. Discussion This time domain switching facility wastes entire backup links against the rare possibility that a link might fail. Worse, these links are frequently in the same cable, and backhoe fade kills all the links. Conversely, Internet routing utilizes all available circuits con- currently, and gracefully degrades while providing best-effort packet switching around points of failure. Since this specification is intended for carrying PPP packets over point-to-point links in a routed network, APS/MSP is superfluous. During intermittent failures, due to the many orders of magnitude time difference between activation (microseconds) and completion of switching (milliseconds), and the severe extended packet loss, APS/MSP link flapping can interact badly with routing protocols. It usually costs more, with no added benefit. Recommendations Where SONET/SDH circuit path configuration is under control of the user, APS/MSP SHOULD be disabled. Security Considerations This specification introduces no known security vulnerabilities. Section-level bit scrambling consists of a simple repeated XOR with a short, easily computed, LFSR bit stream (listed earlier). This is not a pseudo-random number generator. There is no practical crypto- graphic security. Simpson expires in six months [Page 18] DRAFT PPP AS SONET/SDH August 1998 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). Considerable explanatory text was contributed by C. M. Heard (VVNet). 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. 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-xxxx] Simpson, W., Editor, "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 19] DRAFT PPP AS 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 20] DRAFT PPP AS SONET/SDH August 1998 Full Copyright Statement Copyright (C) William Allen Simpson (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 21]