idnits 2.17.1 draft-ietf-pppext-pppsonet-scrambler-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-24) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 13 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 28 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 336 has weird spacing: '...as been propo...' == Line 684 has weird spacing: '...in some frame...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Note 1' on line 178 -- Looks like a reference, but probably isn't: 'Note 2' on line 188 -- Looks like a reference, but probably isn't: 'Note 3' on line 242 == Unused Reference: '3' is defined on line 440, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 468, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1619 (ref. '2') (Obsoleted by RFC 2615) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 J. Manchester 2 Internet Draft M. Krishnaswamy 3 Point-to-Point Protocol Extensions WG S. Dravida 4 J. Anderson 5 Expire in six months B. Doshi 6 E. Hernandez-Valencia 7 Lucent Technologies 9 W. L. Edwards 10 Sprint Corporation 12 B. Bharucha 13 K. Fendick 14 G. Wetzel 15 AT&T 17 PPP over SONET/SDH 19 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as 32 ``work in progress.'' 34 To learn the current status of any Internet-Draft, please check 35 the ``1id-abstracts.txt'' listing contained in the Internet- 36 Drafts Shadow Directories on ftp.is.co.za (Africa), 37 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 38 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 40 This memo provides information for the Internet community. 41 This memo does not specify an Internet standard of any kind. 42 Distribution of this memo is unlimited. 44 Abstract 46 This Internet Draft addresses the PPP/SONET interface defined 47 in the IETF RFC 1619 and its application in public Internet backbone 48 networks. By experimental analysis it is found that this SONET interface 49 specification is deficient in providing payload transparency. This 50 deficiency leads to deleterious effects in providing reliable network 51 operations. A simple SONET payload scrambler enhancement is proposed 52 PPP over SONET/SDH October 1997 54 to overcome this deficiency. This work has been brought to the 55 ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping 56 to T1.105 with a scrambler to be determined by T1X1. 58 We are submitting the same proposal to IETF now with the interest to 59 enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards. 60 To facilitate this alignment, we have recommended that T1X1 establish a 61 formal liaison with IETF in regard to IP/SONET interface standards 62 and associated IP transmission standards development. 64 1. Introduction 66 SONET provides a reliable high speed transmission path for today's 67 growing Internet backbone traffic. RFC 1619 addresses the issues 68 concerning mapping of the PPP packets on to SONET payload envelopes 69 [1], [2]. However no scrambling of the IP payload is specified in 70 RFC 1619. We have found by experimental analysis that this leads to 71 lack of payload transparency that could cause serious damage to the 72 reliable functioning of SONET networks. 74 We are proposing a scrambler for SONET payloads and use of SONET 75 Path Overheads for maintaining synchronization in the scrambler 76 operation. We have recommended to T1X1.5 that the scrambler enhanced 77 mapping use a different Path Signal Label code (byte C2) from the 78 original proposal in RFC 1619. This will allow network operators to 79 distinguish between scrambled and non-scrambled payloads. 81 2. Native SONET Scrambler design 83 One very serious problem with the RFC specification is the assertion 84 It is evident that the decision to not scramble the HDLC delimited PPP 85 packets is derived from errored assumptions about the SONET scrambler. 86 The SONET scrambler was designed for optical transmission of 87 digital signals. "SONET optical interfaces use binary line coding, and 88 therefore must be scrambled to assure an adequate number of transitions 89 (zeros to ones, and ones to zeros) for such purposes as line rate 90 recovery at the receiver,"[3, page 5-6] and the suppression of discrete 91 spectral components that could lower the receiver's signal-to-noise 92 ratio. Use of the SONET scrambler was deemed sufficient for providing 93 payload transparency for multiplexed payloads. However, in the case of 94 non-multiplexed payloads, such as IP or ATM, where the user data 95 occupies a significant portion of the SONET frame, use of the SONET 96 scrambler does not provide sufficient payload transparency. 98 PPP over SONET/SDH October 1997 100 ____ 101 | | 102 .--------------------------------------| <---. 103 | |____| | 104 | ^ | 105 __V___ ______ ______ | ___.__ 106 |Stage | |Stage | |Stage | | |Stage | 107 | 1 |------> 2 |---> .... ---> 6 |-.--> 7 |----. 108 |______| |______| |______| |______| | 109 ^ ^ ^ ^ ^ ^ ^ ^ | 110 | | | | | | | | | 111 | | | | | | | | | 112 ----.-------------.--------------------.-----------.----- | 113 Clock | | | | | 114 | | | | | 115 ------.-------------.--------------------.-----------.-- | 116 Frame Pulse | 117 _V__ 118 Data In | | 119 ----------> | 120 |_.__| 121 | 122 | 123 Scrambled | 124 Data Out V 126 Fig. 1 SONET Scrambler (1 + x**6 + x**7) 128 To understand the implications of not having sufficient payload 129 transparency, one must examine the SONET scrambler in more 130 detail. The SONET scrambler is a set-reset frame synchronous 131 scrambler with a generating polynomial of 1+x**6+x**7 as shown in 132 Figure 1. The scrambler resets at each SONET frame by setting 133 each of the registers to all ones on the most significant bit of the 134 byte following the STS-1 number N J0/Z0 byte. The framing bytes, 135 and the J0/Z0 bytes in STS-1 through STS-N are not scrambled. 136 A series of shift registers are used with feedback taps coming off 137 of the 6th and 7th registers. These taps are xored for input back 138 into the 1st shift register. This operation produces a pseudo 139 random sequence. As this is a 7th order scrambler, the pseudo 140 random sequence generated repeats itself every (2**7)-1, or 127, bit 141 periods. The pseudo random sequence coming out of the 7th 142 register is xored with the data to be transmitted. This sequence 143 from the 7th register is easily obtainable using a spread sheet 144 application. Thus, a malicious user, armed with knowledge of the 145 xor operation, can, by making a 1/127 assumption as to where 146 his data lands in the SPE, control the output of the SONET 147 scrambler. 149 Suppose for example that a malicious user was trying to introduce 150 a long string of zeros into the public network. They could transmit 151 PPP over SONET/SDH October 1997 153 an IP datagram that continuously repeats the 127 bit pattern from 154 the 7th register of the SONET scrambler. When the pattern from 155 the 7th register is aligned with the 127 bit pattern from the 156 malicious user, the scrambler will put out all zeros. 157 The malicious user has no idea where his datagram will land in the SPE. 158 The probability of the repetitive codes in the first row being aligned 159 with the 7th register of the SONET scrambler is 1/127. If the SONET 160 signal is an STS-3c, there will be an 80 bit offset for the 161 transmission of the SONET transport and path overhead. The 162 malicious user will have no control over these fields; however, 163 because 127 is prime and thus has no factors in common with 80, 164 the probability of the repetitive codes matching the output of the 7th 165 register is exactly 1/127 for each new row that the datagram is 166 mapped into [Note 1]. If the assumption is further made, that the 167 user is transmitting to the IP over SONET interfaces via an ethernet 168 interface (which has an MTU of 1500 bytes), then on average, the 169 malicious user only has to transmit 21 [Note 2] datagrams to be 170 reasonably sure that a long string of zeros has been introduced 171 into the network. This long string of zeros is, in the worst case, 172 2080 bits or 13 microsec for the STS-3c mapping. This is well within 173 the specification for SONET LOS (Loss Of Signal) and depending on the 174 type of clock and clock recovery circuit may also cause framing and 175 synchronization problems. 177 ----------------------------------------------------------------------------- 178 [Note 1] 179 If there were common factors between 127 and 80, the per row probability 180 would be lower because there will be spots in one row whereby if 181 an user's datagram lands in them, it will be impossible for the 182 repetitive codes to be on in the next row. The 1/127 probability 183 actually increases if the Path Overhead starts to float. The path 184 overhead then acts as a second offset and the codes are twice as likely 185 to be on for each row; however, the number of zeroes that can be 186 introduced will be reduced. 188 [Note 2] 189 1500 bytes is roughly 6 rows for an STS-3c mapping. Each datagram thus 190 has a 6/127 chance of introducing a long string of zeros. The 191 transmission of 21 datagrams will thus lead to a probability of 192 (6/127)*21 ~= 1. 194 3. Experimental verification of RFC 1619 inadequacy 196 In the laboratory we tested out our technical hypotheses using 197 RFC 1619 compliant interfaces and several SONET transport network 198 test equipments. The following is a summary of our conclusions: 200 A. SONET interfaces that detect LOS in less than 13 microsec are open 201 to a malicious user causing LOS when interconnected to an RFC 1619 202 compliant interface [Note 3]. Note that the LOS specification is 2.3 to 100 203 microsec and it is our experience that most SONET interfaces are on the 204 PPP over SONET/SDH October 1997 206 low end of this detection time as this value is included in the SONET 207 restoration time for automatic protection switching. 209 B. All SONET interfaces regardless of LOS detection are open to a 210 malicious user causing synchronization, clock, and framing problems 211 when the interface is connected to an RFC 1619 compliant interface. 212 There are no requirements for how long a clock recovery circuit must 213 maintain synchronization, but our experience tells us that most SONET 214 clock recovery circuits are designed to stay in synchronization for 215 ~80 bit periods when there are no bit transitions on the incoming line. 216 After that, the clock will go into holdover and the ability of the clock 217 to maintain synchronization will be dependent on the clock quality 218 (i.e., stratum level). 220 C. As a result of the above scenario, it is possible for a malicious 221 user to force an interface connected to an RFC 1619 compliant interface 222 to detect a hard failure based on the onset of LOS or LOF (Loss Of Frame). 223 Thus, RFC 1619 compliant interfaces should never be used to provide 224 enhanced services such as protection switching. 226 It is also important to realize that the issue of unraveling the 227 SONET scrambler came up during the standardization of ATM over SONET 228 interfaces. There a user could only gain 48 bytes of the SONET SPE 229 before there is an interruption from the ATM cell overhead. This was 230 still seen as a problem when analyzed theoretically. Laboratory tests 231 could not be performed at the time because SONET and ATM equipment did 232 not exist. It is therefore simply fair to point out, at the outset, 233 what this work owes to certain contemporary ATM and SONET 234 interface developers. We wish to provide citations to this early 235 outstanding technical work here: [4] [5] [6] [7] [8] [9]. 236 As a result of these contributions, "cell payload scrambling is 237 used to provide security against payload information replicating 238 the frame synchronous scrambling sequence (or its inverse) used at the 239 SONET section layer." [3, page 3-61]. 241 ---------------------------------------------------------------------------- 242 [Note 3] 243 The malicious datagrams can be transmitted from anywhere in the 244 Internet. The user need not be directly connected to the SONET 245 network. 247 4. Requirements for SONET Mappings 249 In November 1988, T1X1 agreed to the following set of mapping 250 guidelines [10]: 252 Standardized Payload 253 Significant Network Advantage OR Unique 254 Payload Transparency for Non-terminated Payloads 255 Timing Transparency 256 Minimal Implementation Complexity 257 PPP over SONET/SDH October 1997 259 Floating/Locked Translation Capability 260 Mid-Span Meet 262 A detailed explanation of each of the mapping guidelines from the 263 original T1X1.5 Mapping SWG contribution [10] follows: 265 Standardized Payload 267 The structure of any payload to be mapped must be specified in 268 detail and approved by a recognized standard setting 269 organization. 271 Unique or Significant Network Advantage 273 The payload must not already have a defined mapping (unique) or the new 274 mapping must have a significant network advantage over the original 275 mapping. Significant NETWORK advantage implies that the assessment of 276 'significant advantage' takes into consideration the fact that the STS 277 format was developed to allow direct interfaces on many types of transport 278 equipment which are interconnected. Therefore, a mapping which optimizes 279 a particular piece of equipment or application at the expense of the 280 network as a whole is precluded. 282 Payload Transparency For Non-Terminated Payloads 284 VT and STS Synchronous Payload Envelopes were developed to allow the 285 transport of payloads by equipment which has no 'knowledge' of the type 286 of payload, and to allow new payloads to be mapped and transported 287 without modification to deployed equipment. New mappings should not 288 compromise this capability. 290 Timing Transparency 292 VT and STS Payload Pointers were developed to allow the transport of 293 payloads between equipment which is not phase-aligned nor necessarily 294 exactly frequency synchronous. New mappings should not compromise this 295 capability. 297 Minimal Transport Delay 299 VT and STS Payload Pointers also allow the manipulation of Synchronous 300 Payload Envelopes without frame alignment buffers in order to minimize 301 transport delay. New mappings should not compromise this capability. 303 Minimal Implementation Complexity 305 The circuitry required to implement a particular mapping should 306 not be unduly complicated. 308 Performance 310 The mapping should be such that, after being transported by the 311 SONET network, the payload can meet all network performance 312 PPP over SONET/SDH October 1997 314 criteria, such as jitter, specific to that payload. 315 Floating/Locked Translation Capability 317 Locked VT Mode mappings must be such that it is possible to 318 translate an STS-1 between Locked and Floating VT Mode. This 319 translation function should meet all other applicable guidelines. 321 Mid-Span Meet 323 This mapping should not compromise the capability of providing mid-span 324 meet for that payload. Although a payload that is mapped using 325 Floating VTs is not compatible with the same payload mapped using Lock 326 VTs, this exception is covered by the Floating/Locked Translation 327 Capability. 329 5. Analysis of RFC 1619 with Respect to Mapping Guidelines 331 In examining the RFC 1619 PPP/SONET mapping with respect to the 332 T1X1 mapping guidelines, it is clear from the discussion in Section 333 2 and 3 that the mapping does not provide payload transparency for 334 non-terminated payloads. This is a very serious problem and 335 cannot be overlooked. To rectify this situation immediately, it 336 has been proposed in T1X1 to enhance the PPP over SONET mapping 337 with the use of a scrambler. (See Appendix A for the scrambler 338 proposed to T1X1) 340 6. Scrambler Requirements 342 In the previous sections we demonstrated the need for a scrambler. 343 Scramblers designed to transport high speed data services must meet 344 the following requirements: 346 A. Robust Performance: The scrambler design must be robust against 347 malicious user attacks. Even if the user gains control of one or more 348 SONET/SDH frames, the user should not be able to negate the scrambler 349 so that bit transparency is lost. This can be accomplished by 350 making the probability of guessing the scrambler state as small as 351 possible. 353 B. Quick Recovery: The scrambler design should be such that in the 354 event of abnormal situations such as the loss and regaining of physical 355 layer synchronization, the descrambler at the receiver and the scrambler 356 at the transmitter regain synchronization is as short a time as 357 possible. 359 C. No Error Multiplication: Error multiplication at the lower layer 360 can be damaging to the higher layer applications. If there is error 361 multiplication, certain error protection schemes such as parity checks 362 could be rendered useless. Arithmetic check sums are also generally 363 vulnerable to error multiplication and perform poorly. Even CRC checks 364 designed at the higher layers to provide a certain minimum Hamming 365 distance begin to lose their power and the effective minimum Hamming 366 distance provided in the presence of error multiplication is reduced. 368 PPP over SONET/SDH October 1997 370 D. Immunity to Transmission Errors: While quick recovery is desirable 371 PPP over SONET/SDH October 1997 373 after abnormal conditions such as loss of signal events, it is also 374 important that the scrambler have immunity to normal conditions such 375 as random background errors. The random errors should not cause the 376 descrambler and scrambler to go out of synchronization. 378 E. Work within existing Frame Structure: The scrambler should be made 379 to work within the existing SONET/SDH frame structure. There should be 380 no need to introduce new overheads in the SONET/SDH payload. 382 7. Proposed Scrambler Design 384 See Appendix A for the scrambler proposed to T1X1. 386 8. Proposal made to T1X1 388 This work addressed the PPP/SONET interface defined in the 389 IETF RFC 1619 and its application in public Internet backbone 390 networks. Based on the analysis presented herein, the following 391 proposals were made in T1X1: 393 A. Reaffirm the SONET mapping criteria and requirements for T1.105 [11] 394 outlined in [10]. 396 B. Enhance the PPP/SONET mapping in [2] with use of a scrambler for 397 the SONET payload and use of Path Overheads for maintaining 398 synchronization in the scrambler operation. 400 C. Specify the scrambler and the Path Signal Label code. The Path 401 Signal Label code should be different from the original proposal in 402 RFC 1619 for allowing network operators to distinguish between 403 scrambled and non-scrambled payloads. 405 9. Proposal to IETF 407 Specifically we propose that future IETF specifications of PPP over 408 SONET/SDH be aligned with T1.105 when this work is completed in T1. 410 In the interim, we recommend that one of the following is done: 412 A. Retract RFC 1619 (or) 414 B. Reissue a new PPP over SONET/SDH RFC with a cautionary note 415 that the failure to scramble the PPP packets can lead to 416 deleterious effects in providing reliable network operations. 418 PPP over SONET/SDH October 1997 420 10. Security Consideration 422 This memo is informational, and specifies no protocol for deployment. 423 It highlights specific security vulnerabilities of RFC 1619. 425 11. Acknowledgments 427 We would like to thank Tom Bowmaster from Bellcore for his technical 428 and testing assistance. 430 Grenville Armitage assisted in presenting this information in the IETF 431 Internet Draft format. 433 12. References 435 [1] IETF RFC 1661, "The Point-to-Point Protocol (PPP)," W. Simpson - 436 Daydreamer (July 1994). 438 [2] IETF RFC 1619, "PPP over SONET/SDH," W. Simpson - Daydreamer (May 1994). 440 [3] Bellcore GR-253-CORE, Issue 2, (December 1995). 442 [4] T1S1.1/88-498, "Enhancements of SONET Scrambling Capabilities to 443 Carry ATM Cells," Kuo-Hui Liu and William L. Edwards - Pacific Bell 444 (October 1988). 446 [5] T1S1.1/88-453, "Bit Sequence Independence for ATM Cells," 447 Ralph Ballart - Bellcore (October 1988). 449 [6] T1X1.5/89-007, "Further Analysis on Bit Transparency Issue," 450 William L. Edwards and Kuo-Hui Liu - Pacific Bell (February 1989). 452 [7] T1S1.1/89-527, "Distributed Bit Scrambling Method for ATM Cells", 453 D. Fisher and S. Brueckheimer - STC Technology Limited (September 1989). 455 [8] T1S1.1/89-222, "Killer Cells Detector and Solution for Bit 456 Transparency Issue," William L. Edwards and Kuo-Hui Liu - Pacific Bell 457 (May 1989). 459 [9] T1S1.1/89-163, "Proposed Contribution to CCITT SG XVIII on 460 SDH Mapping for ATM," Jon Anderson - AT&T Bell Laboratories (May 1989). 462 [10] T1X1.5/88-123, "Payload Mapping Guidelines," Brent Allen - Nortel 463 (November 1988). 465 [11] ANSI T1.105, "Synchronous Optical Network (SONET) Basic 466 Description including Multiplex Structure, Rates and Formats" (1995). 468 [12] ITU-T Recommendation G.707, "Network node interface for the 469 synchronous digital hierarchy (SDH)" (3/96). 471 PPP over SONET/SDH October 1997 473 12. Authors' Address 475 James Manchester 476 E-mail: manchester@bell-labs.com 477 Telephone: +1-732-949-6284 478 Fax: +1-732-949-3210 480 Bell Laboratories 481 Room 2G-527 482 101 Crawfords Corner Road 483 Holmdel, NJ 07733-3030 484 USA 486 Murali Krishnaswamy 487 E-mail: murali@bell-labs.com 488 Telephone: +1-732-949-3611 489 Fax: +1-732-949-3210 491 Bell Laboratories 492 Room 2G-527A 493 101 Crawfords Corner Road 494 Holmdel, NJ 07733-3030 495 USA 497 Subrahmanyam Dravida 498 E-mail: dravida@bell-labs.com 499 Telephone: +1-732-949-1264 500 Fax: +1-732-834-5906 502 Bell Laboratories 503 Room 3M-337 504 101 Crawfords Corner Road 505 Holmdel, NJ 07733-3030 506 USA 508 Jon Anderson 509 E-mail: jonanderson@bell-labs.com 510 Telephone: +1-732-949-0634 511 Fax: +1-732-949-3210 513 Bell Laboratories 514 Room 2G-538 515 101 Crawfords Corner Road 516 Holmdel, NJ 07733-3030 517 USA 519 Bharat Tarachand Doshi 520 E-mail: bdoshi@bell-labs.com 521 Telephone: +1-732-949-0823 522 Fax: +1-732-834-5906 524 Bell Laboratories 525 Room 3L-337 526 PPP over SONET/SDH October 1997 528 101 Crawfords Corner Road 529 Holmdel, NJ 07733-3030 530 USA 532 Enrique Hernandez-Valencia 533 E-mail: enrique@bell-labs.com 534 Telephone: +1-732-949-6153 535 Fax: +1-732-834-5906 537 Bell Laboratories 538 Room 3H-313 539 101 Crawfords Corner Road 540 Holmdel, NJ 07733-3030 541 USA 543 W. L. Edwards 544 E-mail: texas@sprintcorp.com 545 Telephone: +1-913-534-5334 546 Fax: +1-913-534-2526 548 Sprint Corporation 549 Mailstop KSOPKB0802 550 9300 Metcalf Avenue 551 Overland Park, KS 66212 553 Behram Bharucha 554 E-mail: bbharucha@att.com 555 Telephone: +1-732-949-7989 556 Fax: +1-732-949-8569 558 AT&T 559 Room 1J-301 560 101 Crawfords Corner Road 561 Holmdel, NJ 07733-3030 562 USA 564 Kerry Fendick 565 E-mail: kfendick@att.com 566 Telephone: +1-732-949-1243 567 Fax: +1-732-949-1726 569 AT&T 570 Room 1L-425 571 101 Crawfords Corner Road 572 Holmdel, NJ 07733-3030 573 USA 575 Greg Wetzel 576 E-mail: gfwetzel@att.com 577 Telephone: +1-732-949-6630 578 Fax: +1-732-949-1726 579 PPP over SONET/SDH October 1997 581 AT&T 582 Room 1L-426 583 101 Crawfords Corner Road 584 Holmdel, NJ 07733-3030 585 USA 587 Appendix A 589 Note: 590 This is a proposal to T1X1 and should not be considered to be 591 in final form. 593 .--------<---------------<--------------<--------------<--------. 594 | ^ ^ ^ ^ 595 | | | | | 596 | | | | | 597 _V_ ___ ___ | ___ ___ | ___ ___ | ___ ___ | 598 |x39|-->x38|...|x21|-->x20|-->x19|-->x18|...|x2 |-->x1 |-->x0 |---> 599 |___| |___| |___| |___| |___| |___| |___| |___| |___| | 600 | 601 | 602 Scrambler | 603 Output | 604 _V_ 605 --------> | 606 Data |___| 607 | 608 | 609 To SONET/SDH | 610 Layer V 612 Fig. 2 Proposed Scrambler for PPP over SONET 614 Based on section 6 requirements, a scrambler polynomial has been 615 of degree 40 has been designed. This scrambler generates 616 a pseudo-random sequence of period (2**40)-1, that is it repeats 617 after (10**12) bits. This period is sufficiently long even for 618 rates up to OC-768. The probability of a malicious user locking 619 on to the phase of this scrambler is (2 ** -40) or (10 ** -12). 620 In conjunction with the SONET/SDH set-reset scrambler, the overall 621 probability of a malicious user causing loss of bit transparency is 622 (10 ** -14). The scrambler polynomial is 623 1 + x**2 + x**19 + x**21 + x**40 and its shift register implementation 624 is shown in Figure 2. 626 A. Transmitter and Receiver Synchronization. 628 The proposed scrambler is designed to scramble bits in the SONET/SDH 629 Payload envelope only. The section, line and path overheads are not 630 PPP over SONET/SDH October 1997 632 scrambled by this scrambler. Therefore the scrambler 633 state is transmitted using bytes available in the Path Overhead (POH). 634 Currently H4, Z3 and Z4 bytes are available. These bytes can be 635 used to transmit the scrambler state so that the descrambler 636 at the receiver can be synchronized with the scrambler at the 637 transmitter. 639 Since the scrambler state is 40 bits long, 5 bytes are needed to 640 transmit the scrambler state. This can be done by splitting the 641 scrambler state and carrying it in the H4, Z3 and Z4 bytes of 642 multiple frames. The state transmitted by the transmitter should 643 be such that upon its reception, the receiver could load that state 644 into its descrambler and immediately start descrambling. In order 645 to enable this, it is desirable for the transmitter to predict the 646 scrambler state needed at the receiver for immediate descrambling 647 and then place the predicted state in the H4, Z3 and Z4 bytes of the 648 Path Overhead (POH). Since the state is transmitted in multiple frames, 649 the scrambler state would have to be predicted across the number of 650 frames that it takes to transmit the scrambler state. For example, 651 if the scrambler state is transmitted in two successive frames then the 652 scrambler state needs to be predicted by at most two frames. However, 653 the prediction interval is pre-determined and all that is needed is 654 prediction of the current state by a fixed number of bytes. 655 Scrambler state prediction is very simple and can be accomplished in 656 many ways. A straightforward method is to run two scramblers, one at 657 the current state and the second one ahead by the number of bytes in 658 the prediction interval. Another elegant and fast method is to perform 659 prediction using table look-ups. This avoids the need for a serial bit 660 register implementation. Five tables each of 1.2 Kbytes can be used for 661 state prediction. Since the prediction interval is known, the tables are 662 precomputed and stored. The most significant byte (MSB) of the current 663 state indexes the first table and retrieves a 5 byte word, the second 664 most significant byte indexes the second table and retrieves another 665 5 byte word and so on. The retrieved 5 byte words are xored to provide 666 the predicted state. 668 .______________________________________________________. 669 |SN|Predicted State|SN|Predicted State|RSVD|SN|RSVD|CRC| 670 |__|_______________|__|_______________|____|__|____|___| 671 2 22 2 18 4 2 2 20 Bits 673 <---------------------- 9 Bytes -----------------------> 675 Fig. 3 Format of Predicted State 677 In order to provide immunity from random errors and to provide the 678 ability to quickly recover immediately after abnormal events such 679 as protection switching, are the predicted state be 680 covered by a CRC. Furthermore, to leave room for additional 681 functions that could be added in the future, the 682 PPP over SONET/SDH October 1997 684 H4, Z3 and Z4 bytes in some frames are reserved for future use. 685 This can be done by introducing a frame sequence number of two 686 bits. The H4, Z3 and Z4 bytes in three consecutive frames can be 687 used for transmitting the predicting scrambler state and the H4, Z3 688 and Z4 bytes in the fourth frame could be used for some other 689 purpose in the future. The proposed format of the predicted state 690 is shown in Figure 3. In this figure SN stands for sequence 691 number and RSVD is for reserved bits. 693 At initialization, the transmitter picks a random seed to load the 694 shift registers of the scrambler. The only requirement is that at 695 least one of the 40 bits be non-zero. The transmitter then picks 696 the corresponding predicted state and forms the predicted state 697 field as shown in Figure 3 and hands it down to the SONET/SDH 698 physical layer. The SONET/SDH physical layer transports the 699 predicted state in three consecutive frames. At the receiver, the 700 CRC is checked and if it passes the predicted state is loaded into 701 the descrambler and descrambling starts immediately. 703 Under normal conditions, the receiver checks to see if the CRC 704 passes. If the CRC does not pass then the receiver ignores the 705 predicted state. If the CRC passes and the predicted state does 706 not match the current state at the receiver, then the receiver loads 707 the predicted state into the descrambler and continues to 708 descrambler. The chance of loading an errored state is 1 in (10**6). 710 In the worst case, it will take six frame times (750 microsec) to regain 711 scrambler synchronization under abnormal conditions such as the 712 loss and recovery of physical layer synchronization.