idnits 2.17.1 draft-ietf-pppext-sonet-as-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 463 has weird spacing: '... Mbps min...' == Line 471 has weird spacing: '... Mbps min...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'Tanenbaum' is mentioned on line 114, but not defined == Missing Reference: 'Kleinrock' is mentioned on line 116, but not defined == Unused Reference: 'RFC-1662' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'G.707' is defined on line 908, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-xxxx' -- Possible downref: Non-RFC (?) normative reference: ref. 'SONET' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft 4 expires in six months August 1998 6 Applicability Statement for PPP over SONET/SDH 7 draft-ietf-pppext-sonet-as-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) 28 ftp.nis.garr.it (Southern Europe) 29 ftp.ietf.org (Eastern USA) 30 ftp.isi.edu (Western USA) 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) William Allen Simpson (1994, 1997-1998). All Rights 38 Reserved. 40 Abstract 42 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard 43 method for transporting multi-protocol datagrams over point-to-point 44 links. This document describes the use of PPP over Synchronous Opti- 45 cal Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. 47 1. Applicability Statement 49 PPP over SONET/SDH is intended for those implementations that desire 50 the PPP encapsulation over high speed private point-to-point links, 51 such as intra-campus single-mode fiber that may already be installed 52 and unused. 54 Some installations have attempted to use commercial long-distance 55 carriers. Because these services were installed and tested for 56 voice, and carriers have bid least-cost components that do not meet 57 the needs of high speed data services, numerous interoperability 58 problems have arisen. The profile identifies many of these pitfalls, 59 and recommends practices that avoid them. 61 1.1. Terminology 63 The various committees changing the SONET/SDH specifications have 64 been inconsistent in their terminology. This specification uses a 65 few simplified terms: 67 block A fixed-size time-based multiplexing unit, carried 68 from interface to interface; also known as the SONET 69 Synchronous Transport Signal (STS-N) Frame, or the 70 SDH Synchronous Transport Module (STM-N) Frame 71 Structure. This use of "frame" conflicts with link- 72 layer use of the same term. The format has more in 73 common with fixed-length unit record equipment, such 74 as a magnetic tape, than with a variable-length 75 packet. 77 byte An 8-bit quantity; also known as "octet" in stan- 78 dardese. 80 envelope A fixed-size time-based multiplexing unit, carried 81 within successive blocks along a path; also known as 82 the SONET Synchronous Payload Envelope (SPE), or the 83 SDH Administrative Unit Group (AUG). 85 frame A variable-length unit of transmission, which is 86 passed across the interface between the link-layer 87 and the physical-layer. A single packet is usually 88 wrapped in a frame, unless link-layer packet frag- 89 mentation is performed, or multiple packets are 90 aggregated into a single frame. 92 packet The basic unit of link encapsulation, which is 93 passed across the interface between the network- 94 layer and the link-layer. The packet information is 95 variable-length. 97 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 98 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 99 described in [RFC-2119]. 101 To remain consistent with standard Internet practice, and avoid con- 102 fusion for people used to reading RFCs, all binary numbers in the 103 following descriptions are in Most Significant Bit to Least Signifi- 104 cant Bit order, from Most Significant Byte to Least Significant Byte, 105 reading from left to right, unless otherwise indicated. Note that 106 this is contrary to ISO and ITU practice, which orders bits as trans- 107 mitted (network bit order). Keep this in mind when comparing this 108 document with the other documents. 110 2. SONET/SDH Profile 112 "The nice thing about standards is that you have so many to choose 113 from; furthermore, if you do not like any of them, you can just wait 114 for next year's model." [Tanenbaum] 116 "The problem with standards is the last 's'." [Kleinrock] 118 SONET and SDH were "standardized" by at least 4 different organiza- 119 tions. 121 - Bellcore developed the original SONET specification, and has 122 issued significantly reorganized and revised documents in 1991 and 123 1995. According the [SONET] Revision History: "Since TR- 124 TSY-000253, Issue 1, there have been so many revisions to this 125 material that the use of change bars is impractical." 127 - ANSI (T1X1 and T1M3) has a separate series of documents, that are 128 continuously revised, and strongly influenced by a single vendor. 130 - ETSI also has a separate series of documents, but has greatly ben- 131 efited by close attention to detail, and coordination with 132 CCITT/ITU-T. 134 - CCITT (since renamed ITU-T) published the SDH specifications in 135 1988. Minor revisions occurred in 1993 and 1994, with a major 136 reorganization in 1996. 138 The latter organizations have not maintained consistent naming of 139 fields and payloads, have made conflicting changes and extensions, 140 and have been careless about conformity and backward compatibility 141 with existing deployment. 143 This specification was developed utilizing carefully chosen documents 144 that reflect a particular point in time, and that correspond to 145 extant fielded implementations. Where naming conventions are incon- 146 sistent, or conflict with other network usage of the same terms, a 147 simpler taxonomy is chosen. 149 To promote interoperability, this document provides a condensed 150 description of basic SONET/SDH functionality, together with some of 151 the recent changes and their relevance, and a profile of recommended 152 practices. 154 2.1. Bit Transmission 156 All bytes are transmitted Most Significant Bit first. 158 Discussion 160 Care must be taken when converting from other media, such as 161 serial links and ethernet, that are transmitted Least Significant 162 Bit first. 164 2.1.1. Electrical Bits 166 SONET specifies an optional electrical transmission capability using 167 a pair of 75 Ohm coaxial cables, one for each direction. 169 At 156 Mbps, Coded Mark Inversion (CMI) is specified. 171 single bits 173 - - --- 174 | | | | | | | | 175 | | | | | | | | 176 - - --- 177 "0" "0" "1" "1" 179 A1A2 pattern 181 --- --- - --- - - - - --- - - - 182 | | | | | | | | | | | | | | | | | | | | | | | | | 183 | | | | | | | | | | | | | | | | | | | | | | | | | 184 --- --- - --- - - - --- - - - - 185 1 1 1 1 0 1 1 0 0 0 1 0 1 0 0 0 187 or its inverse. 189 Lower signal rates (52 Mbps) use Bipolar with Three-Zero Substitution 190 (B3ZS). These rates are not relevant to PPP over SONET/SDH (see 191 "Physical Layer Requirements"). 193 Discussion 195 There are no recent changes that might affect interoperability. 197 At the time of writing, there are no reported router implementa- 198 tions using CMI electrical transmission to directly feed electro- 199 optical section or line terminating equipment. 201 Typically, pseudo-ECL signals over very short inter-component dis- 202 tances are used to drive the optics with the same encoding pattern 203 as the optical bits. 205 Recommendations 207 As the cost of optical interfaces and cabling has rapidly 208 decreased, the use of optical transmission is preferred, even for 209 moderately short intra-office distances. 211 For electrical intra-office router interconnection, use of 212 100baseT (or future gigabit ethernet) is preferable to PPP over 213 SONET/SDH. 215 2.1.2. Optical Bits 217 SONET specifies an optical transmission capability using a pair of 218 fibers, one for each direction. The use of bi-directional fiber 219 transmission is "for further study". 221 The optical line coding used for all system interfaces is binary Non- 222 Return-to-Zero (NRZ). The convention adopted for optical logic level 223 is 224 logical 1 -- emission of light 225 logical 0 -- no emission of light 227 single bits 229 --- 230 | | 231 | | 232 --- 233 "0" "1" 235 A1A2 pattern 237 --------------- ------- --- --- 238 | | | | | | | 239 | | | | | | | 240 --- ----------- --- ----------- 241 1 1 1 1 0 1 1 0 0 0 1 0 1 0 0 0 243 To simplify the development of compatible multi-vendor systems, it is 244 desirable to define a relatively small set of categories and corre- 245 sponding optical interface specifications. 247 Short Reach (intra-office) 248 SONET optical sections having loss budgets of 0 dB to 7 dB; alter- 249 natively, SDH interconnect distances less than 2 kilometers. 251 Intermediate Reach (short haul inter-office) 252 SONET optical sections having loss budgets of 0 dB to 12 dB; 253 alternatively, SDH interconnect distances up to 15 kilometers. 255 Long Reach (long haul inter-office) 256 SONET optical sections having loss budgets of 10 dB to 28 dB; 257 alternatively, SDH interconnect distances up to 40 kilometers at 258 1310 nanometers, and up to 60 kilometers at 1550 nanometers. 260 Unfortunately, the current proliferation of specifications falls far 261 short of this goal, having different category definitions (as seen 262 above) and more than 20 total pages of parameter tables. 264 Discussion 266 There are too many recent changes that impede interoperability to 267 detail in this short overview. 269 Care must be taken when comparing signals from other media, such 270 as high speed serial links, where "no signal" is "logical 1". 272 At the time of writing, the majority of reported implementations 273 use "intermediate" level 1310 nanometer optics with single mode 274 fiber. This can accommodate multi-mode fiber and short reach 275 (intra-office) interconnection with the addition of transmitter 276 attenuation. 278 Upgrading to future higher speeds would be facilitated by 279 installing single mode fiber instead of multi-mode fiber. 281 Recommendations 283 The greatest interoperability and economies of scale will be 284 achieved with deployment of a few general interface choices, all 285 for single mode fiber: 287 Intermediate Reach equipment at 1310 nanometers for each STM 288 line speed. 290 Long Reach equipment at 1550 nanometers for 2 Gbps and above. 292 2.1.3. Bit Scrambling 294 Optical interface signals use NRZ binary line coding (described 295 above). A series of repeated bits will not feature any signal level 296 transitions. Such transitions (zeros to ones and ones to zeros) are 297 needed at the receiver to dynamically correct bit timing variance for 298 line rate clock recovery. Therefore, although it has no effect on 299 random data, the signal is scrambled against the possibility that a 300 very long series of ones or zeros might naturally occur in the trans- 301 mitted bit stream. 303 Electrical interface signals use line encoding (B3ZS and CMI) that 304 assures adequate transitions. Scrambling is not needed. However, 305 they are also scrambled for consistency between the electrical and 306 optical component interfaces. 308 In both cases, a 7-bit linear feedback shift register (LFSR) is iden- 309 tically applied at the transmitter and receiver. The sequence of 310 bits from the x**7 stage of the LFSR is exclusive-or'd (in most sig- 311 nificant bit order) with the output bits before transmission, and 312 with the corresponding input bits after signal recovery. 314 The first row of the STM-N transmission block overhead (N * 9 bytes 315 described later) is not scrambled. The 7-bit LFSR state is reset to 316 bit value 1111111 (127 decimal) on the most significant bit of the 317 byte following the block overhead. The scrambler runs continuously 318 from that bit onward, throughout the remainder of the transmission 319 block. 321 The generating polynomial for the LFSR is x**7 + x**6 + 1. The 322 resulting 127-bit sequence repeats in a 127 byte stream (shown in 323 hex): 325 fe 04 18 51 e4 59 d4 fa 1c 49 b5 bd 8d 2e e6 55 326 fc 08 30 a3 c8 b3 a9 f4 38 93 6b 7b 1a 5d cc ab 327 f8 10 61 47 91 67 53 e8 71 26 d6 f6 34 bb 99 57 328 f0 20 c2 8f 22 ce a7 d0 e2 4d ad ec 69 77 32 af 329 e0 41 85 1e 45 9d 4f a1 c4 9b 5b d8 d2 ee 65 5f 330 c0 83 0a 3c 8b 3a 9f 43 89 36 b7 b1 a5 dc ca bf 331 81 06 14 79 16 75 3e 87 12 6d 6f 63 4b b9 95 7f 332 02 0c 28 f2 2c ea 7d 0e 24 da de c6 97 73 2a 334 Discussion 336 There are no recent changes that might affect interoperability. 338 The scrambling mechanism is defective in a packet transmission 339 context, where adjacent bytes are sequentially related. Appar- 340 ently, the short polynomial assumed unrelated data that is 341 obtained from DS0 through DS3 circuits. This is characteristic 342 for legacy technology such as Asynchronous Transfer Mode (ATM), 343 interleaved virtual circuits, or voice traffic. 345 Since the feedback is based on the internal state of the LFSR, and 346 is not dependent on its interaction with previous bytes, any sub- 347 set of the bit sequence that exactly matches the phase of the LFSR 348 will generate a series of zeros. The bitwise inverse of the bit 349 sequence will generate a series of ones. 351 This effect is not limited to direct PPP over SONET/SDH. Any 352 packet oriented transmissions carried by SONET/SDH without inter- 353 leaving would have the same result. 355 Moreover, although the 127 byte stream may have been appropriate 356 for the original STS-1 (90 bytes per row), this length is mani- 357 festly insufficient for STM-N (N * 270 bytes per row). 359 Finally, the most egregious flaw in this part of the SONET/SDH 360 specification, the number of bits permitted without a transition 361 is not explicitly defined. Instead, the value is implicitly 362 derived from the fixed length scrambling sequence versus the vari- 363 able length Loss of Signal (LOS) condition based on the link speed 364 (described later). 366 Note that the complete scrambling byte stream cannot be repre- 367 sented in a valid PPP packet. The pair "fd 03" is not conformant, 368 limiting the maximum sequence without a transition to 127 bytes. 370 Recommendations 372 Packet transmissions carried at rates less than 156 Mbps MUST be 373 interleaved under the VT/TU scheme (see "Physical Layer Require- 374 ments"). This is consistent with prior use of bit-synchronous 375 HDLC (and Frame Relay) over DS0 through DS3 circuits. 377 Line rate clock recovery SHOULD be sufficiently stable to with- 378 stand periods of 1016 repeated one or zero bits (127 bytes). 380 2.1.4. Loss of Signal (LOS) 382 To detect a failure that occurs at the transmitter (such as laser 383 failure) or within the transmission facility (such as a fiber cut), 384 all incoming signals (optical and electrical) are monitored for Loss 385 of Signal (LOS) before descrambling, by detecting a lack of suffi- 386 cient signal level transitions to ensure accurate line rate clock 387 recovery. 389 No transitions on the incoming signal is not considered LOS when the 390 condition lasts 2.3 microseconds or less, and is considered LOS when 391 the condition lasts 100 microseconds or more. The treatment of no 392 transitions lasting between 2.3 microseconds and 100 microseconds for 393 the purpose of LOS detection is not specified (left to the choice of 394 the equipment designer). 396 For electrical (B3ZS and CMI) interfaces, the no voltage transitions 397 condition is easily distinguished from an "all-zeros pattern". 399 For SONET optical (and component) interfaces, the no light pulses 400 condition corresponds to an "all-zeros pattern". For testing SONET 401 compliance with the LOS detection requirement, it suffices to apply 402 an "all-zeros pattern" lasting at most 2.3 microseconds, and to apply 403 an "all-zeros pattern" lasting at least 100 microseconds. Optical 404 equipment shall enter the LOS state within 100 microseconds of the 405 onset of the incoming "all-zeros pattern." 407 For SDH optical (and component) interfaces, equipment may also indi- 408 cate LOS within 3 milliseconds of the time the received signal level 409 drops below an implementation-determined threshold (based on receiver 410 sensitivity). The threshold should be selected such that LOS will 411 not be indicated while the Bit Error Rate (BER) is still acceptable. 412 For SDH, the BER is defined to be 1 in 10**(-3). 414 Note that the secondary method is in addition to the primary method, 415 not in lieu of it, and is not required to be implemented in SONET 416 installations. 418 The equipment shall terminate the LOS condition when the incoming 419 signal has two consecutive valid block alignment patterns (described 420 later), and during the intervening time (125 microseconds) sufficient 421 transitions prevent another LOS defect. 423 For trouble isolation purposes, especially for intermittent failures, 424 it is important to distinguish between LOS and other signal failure 425 conditions, such as Loss of Frame (LOF). 427 Discussion 429 There are significant differences between SONET, ANSI, and SDH; 430 SDH does not describe the primary method of detection. Circa 431 1994, this resulted in the addition of the secondary method to 432 SONET. 434 There is no explicit requirement given for the "all-ones pattern" 435 that would indicate a stuck clock or laser transmitter. The same 436 difficulty with lack of transitions will apply. 438 There is no rationale given for the selection of 2.3 us and 100 439 us. Presumably, 100 us was chosen to allow sufficient variance 440 between 125 us block alignment patterns. However, 100 us will 441 cause multiple errors in the block overhead (described later), 442 while 2.3 us is too short to cause any significant damage. 444 The wide disparity between 2.3 us and 100 us, and leaving the 445 error treatment to the vendor, has caused many interoperability 446 problems. Incorrect LOS values as low as 1 +-0.750 us have been 447 discovered. Typical values for valid designs are 20 +-3 us, and 448 26 +-1 us. No values higher than 30 us have been found. 450 Line rate clock stability has been a related interoperability 451 problem. Early 156 Mbps implementations were very robust, and 452 could handle periods of 2,000 bits with no transitions. Some sam- 453 ple and/or low quality implementations have not been as robust; 454 failure has been noted as low as 72 to 80 bits without transi- 455 tions. 457 Recommendations 459 Using the minimum and maximum specification of LOS, line rate 460 clock recovery MUST be sufficiently stable to withstand periods of 461 repeated one or zero bits: 463 Mbps min bits max bits 464 156 358 15,552 465 622 1,431 62,208 466 2,488 5,724 248,832 468 Implementations compatible with this specification SHOULD observe 469 a stricter range of LOS detection, between 13.89 us and 27.26 us: 471 Mbps min bits max bits 472 156 2,161 4,240 473 622 8,641 16,960 474 2,488 34,561 67,840 476 The lower limit affects no more than one row of overhead, while 477 the upper limit includes at least one row of overhead. 479 When a circuit path is divided into multiple line sections, the 480 LOS is not propagated end to end. A hidden section can fail inde- 481 pendently. Therefore, the LOS indication is only advisory, and 482 the (possibly improperly) decoded signal bits MUST be passed to 483 the next section. The framed PPP packet FCS is used to detect the 484 failure. 486 Some SONET framers provide a test feature to send an "all-zeroes 487 pattern" (post scrambling) that forces the LOS alarm downstream. 488 Alternatively, the pattern can be simulated with software. This 489 SHOULD be used to test for compatible equipment during the instal- 490 lation of the circuit, by generating progressively longer zero 491 patterns, to verify that the circuit meets the requirements of 492 this profile. 494 2.2. Block Transmission 496 SONET/SDH transmits each block at precise 125 microsecond intervals. 497 This corresponds to the traditional 4 kHz voice digital sampling rate 498 used for DS0. 500 Each block is divided into 9 logical "rows". 502 For "concatenated" STS/STM, each row consists of some multiple of 270 503 byte "columns". 505 Block transmission overhead is arranged into layers, which correspond 506 to different equipment interfaces that might occur in the path of a 507 single circuit. Although SONET and SDH use inconsistent terms, the 508 layers have a general equivalence. 510 SONET divides its Network Element (NE) interface overhead into Sec- 511 tion (SOH), Line (LOH), and Path (POH). 513 SDH has a corresponding Network Node Interface (NNI) overhead called 514 Regenerator-Section (RSOH), Multiplex-Section (MSOH), and Path (POH). 516 There are 3 rows of (Regenerator) Section Overhead (SOH or RSOH), and 517 6 rows of Line or Multiplex-Section Overhead (LOH or MSOH). 519 2.2.1. Block Overhead 521 The STS-3c/STM-1 transmission block overhead consists of 9 byte 522 columns at the beginning of each 270 byte row, with the remaining 261 523 bytes used for the data envelope(s). 525 +----+----+----+----+----+----+----+----+----+---------- 526 | A1 A1 A1 A2 A2 A2 J0 Z0 Z0 envelope 527 +----+----+----+----+----+----+----+----+----+---------- 528 | B1 ++ ++ E1 ++ ?? F1 ** ** envelope 529 +----+----+----+----+----+----+----+----+----+---------- 530 | D1 ++ ++ D2 ++ ?? D3 ?? ?? envelope 531 +----+----+----+----+----+----+----+----+----+---------- 532 | H1 H1# H1# H2 H2# H2# H3 H3 H3 envelope 533 +----+----+----+----+----+----+----+----+----+---------- 534 | B2 B2 B2 K1 ?? ?? K2 ?? ?? envelope 535 +----+----+----+----+----+----+----+----+----+---------- 536 | D4 ?? ?? D5 ?? ?? D6 ?? ?? envelope 537 +----+----+----+----+----+----+----+----+----+---------- 538 | D7 ?? ?? D8 ?? ?? D9 ?? ?? envelope 539 +----+----+----+----+----+----+----+----+----+---------- 540 | D10 ?? ?? D11 ?? ?? D12 ?? ?? envelope 541 +----+----+----+----+----+----+----+----+----+---------- 542 | S1 Z1 Z1 Z2 Z2 M1 E2 ** ** envelope 543 +----+----+----+----+----+----+----+----+----+---------- 545 ++ media dependent. 546 ** reserved for national use. 547 ?? reserved for future use, SHOULD be zero. 549 Values relevant to this specification: 551 (A1) bit value 1111 0110 (f6 hex) 553 (A2) bit value 0010 1000 (28 hex) 555 (H1) and (H2) Each of the 3 consecutive pairs of H1H2 is taken as 556 a 16-bit mask, with various combinations of bits 557 determining the offset (in multiples of 3*N) to the 558 start of the data envelope. An offset of 0 indi- 559 cates that the envelope immediately follows the last 560 H3 overhead byte. An offset of 522 indicates that 561 the envelope immediately follows the last Z0 over- 562 head byte in the next transmission block. 564 When used for this specification, the second and 565 third H1#H2# pairs are always bit value 1001 xx11 566 1111 1111 (93ff hex), indicating a "concatenated" 567 envelope, where xx is ignored on receipt. 569 Since the block is transmitted by row, the overhead columns are 570 interspersed with envelope columns, complicating generation and 571 recovery. 573 An additional complication is added by the section-level bit scram- 574 bling. Overhead bytes of the first row (A1, A2, J0, Z0) are not 575 scrambled. 577 Discussion 579 J0 was formerly called C1. Z0 was formerly additional copies of 580 C1, but these bytes are now reserved for national use. 582 The xx bit values in H1# were originally 00 for SONET and 10 for 583 SDH. 585 These changes might affect interoperability between international 586 facilities. 588 The scrambler needs a reset signal to indicate the position of the 589 beginning of the transmission block and length of the overhead. 590 Failure of the reset signal timing could prevent recognition of 591 the block. 593 Teleopolists seem inordinately fond of groups of 3. This was evi- 594 dent in early digital efforts (24 DS0 in T1), and continues into 595 SONET/SDH (3 T3/E3 in STM-1). Note that all of the values, 596 including 261 and 270, are divisible by 3. This does not scale 597 well in a digital processing environment. 599 Recommendations 601 Envelopes SHOULD be sent with the H1H2 offset of 522. However, 602 every implementation MUST be prepared to receive a variable off- 603 set. 605 2.2.2. Block Synchronization 607 Timing alignment is detected by searching for (a subset of) the A1 608 and A2 overhead pattern. There are two levels of synchronization 609 recovery. 611 When synchronization has been lost for 3 milliseconds or more (or has 612 never been achieved), long-term synchronization recovery requires 613 detection of a minimum of eight (8) successive error-free A1 and A2 614 overhead patterns. The maximum recovery time is 3 milliseconds (24 615 error-free patterns). 617 Once alignment has been achieved, short-term synchronization loss is 618 declared when four (4) or more consecutive A1 and A2 pattern errors 619 have been detected. The maximum detection time is 625 microseconds. 620 The algorithm used shall be such that, under normal operation, a 621 10**(-3) Poisson distribution of bit errors will not cause a false 622 loss indication more than once every 6 minutes. 624 Recovery from a short-term synchronization loss requires detection of 625 only two (2) successive error-free A1 and A2 overhead patterns. Any 626 recovery circuitry is acceptable that achieves resynchronization 627 within the 250 microsecond interval implied by this definition. 629 Failure to obtain resynchronization within 24 blocks (3 milliseconds) 630 results in a long-term synchronization loss declaration, called Loss 631 of Frame (LOF). 633 Discussion 635 The SDH specification is incomplete, and is missing some time 636 intervals. 638 Conversely, SDH has a somewhat stricter requirement for resynchro- 639 nization after a short-term loss; the algorithm used shall be such 640 that, with a random signal, the probability for false recovery is 641 no more than 10**(-5) per 250 microsecond interval. 643 Recommendations 645 Because of the interaction between block synchronization detec- 646 tion, termination of the Loss of Signal (LOS) condition, and the 647 first row reset of the section-level bit scrambling, the detection 648 circuitry MUST be independent (upstream) of the scrambler, and 649 trigger the subsequent scrambler reset timing. 651 2.2.3. Envelope Overhead 653 A series of envelopes appear within the transmission block. These 654 envelopes float to allow precise timing alignment and jitter correc- 655 tion as the payload is carried over the circuit path. The position 656 of the envelope(s) head within the block is specified by the H1 and 657 H2 pair(s). The envelope(s) tail can carry over into the next trans- 658 mission block. 660 The STS-3c/STM-1 Path Overhead (POH for both SONET and SDH) consists 661 of a 1 byte column, with the remaining bytes used for the payload 662 data. 664 +----+--------- 665 | J1 payload 666 +----+--------- 667 | B3 payload 668 +----+--------- 669 | C2 payload 670 +----+--------- 671 | G1 payload 672 +----+--------- 673 | F2 payload 674 +----+--------- 675 | H4 payload 676 +----+--------- 677 | Z3 payload 678 +----+--------- 679 | Z4 payload 680 +----+--------- 681 | Z5 payload 682 +----+--------- 684 Values relevant to this specification: 686 (J1) Path Trace. Carries one byte at a time of a repeat- 687 ing 64-byte fixed-length string (SONET) or a 16-byte 688 E.164 number (SDH), so that a path receiving termi- 689 nal can verify its continued connection to the 690 intended transmitter. 692 (C2) Path Signal Label. Indicates the composition, con- 693 struction and content of the envelope payload. 695 (H4) Multipurpose Position Indicator. Used by specific 696 payload mappings, such as Floating Virtual Tribu- 697 tary. 699 Since the envelope is transmitted by row, the path overhead columns 700 are interspersed with payload columns, and the combination are inter- 701 spersed with block overhead columns, complicating generation and 702 recovery. 704 Discussion 706 The envelope payload provides the physical-layer interface for 707 insertion of PPP encapsulated packets. 709 The J1 16-byte E.164 number format is rarely applicable, as there 710 is no voice circuit involved in packets. Neither have fielded 711 implementations observed strict adherence to the 64-byte limita- 712 tion. A widely used implementation has generated a string con- 713 sisting of the following pattern, each line CRLF terminated: 715 Remote hostname : sl-bb10 716 Remote interface: POS9 717 Remote IP addr : 127.255.255.255 718 Remote Rx(K1/K2): 00/00 Tx(K1/K2): 00/00 720 The C2 value is primarily informational. It is difficult to use 721 for applying alternate processing for adjacent envelopes, as it 722 occurs after two rows of the envelope have already been processed. 723 Although there is no need for intermediate transit equipment to 724 interpret the value, some equipment fails upon encountering an 725 unrecognized value. 727 At first glance this floating envelope may appear to be a highly 728 efficient technique to avoid interface buffering of synchronized 729 incoming data. Unfortunately, due to interspersing the overhead 730 with the data, it is impossible to determine where the envelope 731 begins until at least a third of the transmission block has been 732 received. 734 Also, the envelope head can begin much later in the same block, or 735 even in the next block. An envelope tail can carry over into a 736 block that is two blocks later than the H1H2 overhead that indi- 737 cates its head. 739 Thus, in a packet switched network, no matter how fast the link 740 speed, a minimum of 125 microseconds is added at every hop, and 741 cut-through routing is difficult or impossible. 743 Recommendations 745 See [RFC-xxxx] "Physical Layer Requirements". 747 2.2.4. Envelope Ordering 749 SONET and SDH differ in the ordering of envelope rows. Several 750 schemes are described, including: 752 J1 ... 753 B3 ... 754 C2 ... 755 J1 ... 756 B3 ... 757 C2 ... 758 J1 ... 759 B3 ... 760 C2 ... 762 J1 ... J1 ... J1 ... 763 B3 ... B3 ... B3 ... 764 C2 ... C2 ... C2 ... 766 J1 J1 J1 ... 767 B3 B3 B3 ... 768 C2 C2 C2 ... 770 Another difficulty has been the interleaving of lower rate channels 771 within envelopes. These are time division multiplexed. 773 In the SONET and SDH specifications, much of the complexity is due to 774 these multi-stage multiplexing schemes. 776 Discussion 778 After optical specifications, this has been the worst impediment 779 to interoperability. 781 As carriers have upgraded equipment to STS-3c/STM-1 and 782 STS-12c/STM-4, some have merely reconnected older equipment with 783 coax (see "Electrical Bits"). This is often haphazard. Although 784 this has no effect on voice, where each byte is a separate chan- 785 nel, this is unacceptable for packets. 787 Recommendations 789 Higher data rate envelopes, and the bytes within envelopes, MUST 790 be sequentially ordered by row. 792 SDH VC-3/VC-4/VC-4-Xc ordering MUST be supported. 794 Envelope data MUST be carried from source to sink in sequential 795 order. That is, bytes inserted in the order "1234" MUST arrive in 796 the same order "1234". 798 At the current setup and monthly charges of hundreds of thousands 799 of US Dollars, installations can insist that equipment be care- 800 fully configured, or will need to find an alternative carrier. 802 2.2.5. Payload Insertion 804 Various ordering schemes differ only in the location of duplicate 805 POH. These redundant POH bytes are specified as "fixed stuff", and 806 the values are not examined. 808 For example, in the previous section, the latter schemes interleave 809 the redundant POH bytes throughout the row (VC-3/VC-4), or concate- 810 nate the redundant POH bytes at the beginning of the row (VC-4-Xc). 812 Recommendations 814 See [RFC-xxxx] "The Data Link Layer". The specification finesses 815 the issue by filling the "fixed stuff" with packet data. This 816 make VC-4 and VC-4-Xc identical with respect to packet processing. 818 2.2.6. Protection Switching 820 SONET provides Automatic Protection Switching (APS), also known as 821 the SDH Multiplex Section Protection Function (MSP), to switch from 822 one circuit to another spare circuit whenever a problem is detected. 823 This switch can take place based on Signal Fail (SF), Signal Degrade 824 (SD), or by manual intervention. Once switching is initiated, it can 825 take up to 50 milliseconds to complete the switch. 827 Signal Fail (SF) is defined as LOS, LOF, BER exceeding 10**(-3), and 828 various other error conditions. 830 Signal Degrade (SD) is defined as BER exceeding a user selectable 831 range from 10**(-5) to 10**(-9). 833 The protection switch applies to all circuits in one direction simul- 834 taneously. Bidirectional switching is optional. 836 Discussion 838 This time domain switching facility wastes entire backup links 839 against the rare possibility that a link might fail. Worse, these 840 links are frequently in the same cable, and backhoe fade kills all 841 the links. 843 Conversely, Internet routing utilizes all available circuits con- 844 currently, and gracefully degrades while providing best-effort 845 packet switching around points of failure. 847 Since this specification is intended for carrying PPP packets over 848 point-to-point links in a routed network, APS/MSP is superfluous. 850 During intermittent failures, due to the many orders of magnitude 851 time difference between activation (microseconds) and completion 852 of switching (milliseconds), and the severe extended packet loss, 853 APS/MSP link flapping can interact badly with routing protocols. 855 It usually costs more, with no added benefit. 857 Recommendations 859 Where SONET/SDH circuit path configuration is under control of the 860 user, APS/MSP SHOULD be disabled. 862 Security Considerations 864 This specification introduces no known security vulnerabilities. 866 Section-level bit scrambling consists of a simple repeated XOR with a 867 short, easily computed, LFSR bit stream (listed earlier). This is 868 not a pseudo-random number generator. There is no practical crypto- 869 graphic security. 871 Acknowledgements 873 PPP over SONET was first proposed by Craig Partridge (BBN). Some 874 information was obtained from the good folks at Bellcore. 876 Technical assistance and information was also provided by Victor Dem- 877 janenko (SUNY Buffalo). 879 Considerable explanatory text was contributed by C. M. Heard (VVNet). 881 Anonymous, Karl Fox (Ascend), Peter Lothberg (Sprint), Subhash Roy 882 (TranSwitch), Stuart Venters (Adtran), and Eric Verwillow (Juniper) 883 provided useful critiques of earlier versions of this document. 885 Special thanks to Ascend Communications (nee Morning Star Technolo- 886 gies) for providing computing resources and network access support 887 for writing this specification. 889 References 891 [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 892 STD-51, DayDreamer, July 1994. 894 [RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51, 895 DayDreamer, July 1994. 897 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP-14, Harvard University, March 899 1997. 901 [RFC-xxxx] Simpson, W., Editor, "PPP over SONET/SDH", DayDreamer, 902 work in progress. 904 [SONET] "Synchronous Optical Network (SONET) Transport Systems: 905 Common Generic Criteria", Bellcore, TR-NWT-000253 Issue 906 2, December 1991. 908 [G.707] CCITT Recommendation G.707, "Synchronous Digital Hierar- 909 chy Bit Rates", June 1992. 911 Contacts 913 Comments about this document should be discussed on the 914 pppsdh@greendragon.com or ietf-ppp@merit.edu mailing lists. 916 This document was reviewed by the Point-to-Point Protocol Working 917 Group of the Internet Engineering Task Force (IETF). The working 918 group can be contacted via the current chair: 920 Karl Fox 921 Ascend Communications 922 655 Metro Place South, Suite 370 923 Dublin, Ohio 43017 925 karl@Ascend.com 927 Questions about this document can also be directed to: 929 William Allen Simpson 930 DayDreamer 931 Computer Systems Consulting Services 932 1384 Fontaine 933 Madison Heights, Michigan 48071 935 wsimpson@UMich.edu 936 wsimpson@GreenDragon.com (preferred) 938 Full Copyright Statement 940 Copyright (C) William Allen Simpson (1994, 1997-1998). All Rights 941 Reserved. 943 This document and translations of it may be copied and furnished to 944 others, and derivative works that comment on or otherwise explain it 945 or assist in its implementation may be prepared, copied, published 946 and distributed, in whole or in part, without restriction of any 947 kind, provided that the above copyright notice and this paragraph are 948 included on all such copies and derivative works. However, this doc- 949 ument itself may not be modified in any way, except as required to 950 translate it into languages other than English. 952 This document and the information contained herein is provided on an 953 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 954 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 955 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 956 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.