idnits 2.17.1 draft-ietf-pppext-sdl-pol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 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 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [5], [6], [7], [8], [12], [13], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 195: '... implementation MUST provide a means ...' RFC 2119 keyword, line 197: '...PPP implementation SHOULD also provide...' RFC 2119 keyword, line 267: '... implementations MUST reject any LCP F...' RFC 2119 keyword, line 270: '... implementations MAY allow a configura...' RFC 2119 keyword, line 272: '... able option MUST default to CRC-32,...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 43 has weird spacing: '...hod for trans...' == Line 50 has weird spacing: '...hannels witho...' == Line 88 has weird spacing: '... to the gener...' == Line 143 has weird spacing: '...ulation requi...' -- 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 (June 1999) is 9076 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '0' is mentioned on line 871, but not defined == Missing Reference: '65536' is mentioned on line 850, but not defined ** Obsolete normative reference: RFC 1619 (ref. '3') (Obsoleted by RFC 2615) -- 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. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group James Carlson 2 Internet Draft IronBridge Networks 3 Expires December 1999 Enrique J. Hernandez-Valencia 4 Lucent Technologies Bell Laboratories 5 Nevin Jones 6 Lucent Technologies Microelectronics Group 7 Paul Langner 8 Lucent Technologies Microelectronics Group 9 June 1999 11 PPP over Simple Data Link (SDL) 12 using raw lightwave channels with ATM-like framing 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 This document is the product of the Point-to-Point Protocol 34 Extensions Working Group of the Internet Engineering Task Force 35 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 36 mailing list. 38 Distribution of this memo is unlimited. 40 Abstract 42 The Point-to-Point Protocol (PPP) in RFC-1661 [1] provides a standard 43 method for transporting multi-protocol datagrams over point-to-point 44 links, and RFCs 1662 [2] and 1619 [3] provide a means to carry PPP 45 over Synchronous Optical Network (SONET) [5] and Synchronous Digital 46 Hierarchy (SDH) [6] circuits. PPP over Simple Data Link (SDL) using 47 SONET/SDH with ATM-like framing (PPPEXT WG work in Progress) extended 48 these standards to include a new encapsulation for PPP called Simple 49 Data Link (SDL) [8]. This document extends the use of SDL over raw 50 lightwave channels without an intervening SONET/SDH layer, which are 51 also referred to as "dark fiber" or Packet-over-Lightwave" (POL) 52 links, 54 This document is the product of the Point-to-Point Protocol Working 55 Group of the Internet Engineering Task Force (IETF). Comments should 56 be submitted to the ietf-ppp@merit.edu mailing list. 58 Applicability 60 This specification is intended for those implementations which desire 61 to use PPP encapsulation over high speed point-to-point circuits with 62 the so-called "dark fiber" or raw lightwave channels. This enhanced 63 framing mechanisms for PPP encapsulation method has very low 64 overhead, good hardware scaling properties and is resilient to 65 payload expansion. It is anticipated that significantly higher 66 throughput can be attained with SDL when compared to other transport 67 and encapsulation mechanisms for high-speed packet data over 68 lightwave channels, and at a significantly lower cost for line 69 termination equipment. 71 SDL is defined over other media types and for other data link 72 protocols, but this specification covers only the use of PPP over SDL 73 raw lightwave channels. Systems requiring typical public network 74 functions such as transmission quality assessment, protection 75 switching/restoration, and OAM&P at the transmission level will may 76 require either an additional transmission layer (e.g., SONET/SDH or 77 OTN [7]) with or equivalent OAM&P functionality not defined in this 78 document. 80 The use of SDL requires the presentation of packet length information 81 in the SDL header. Thus, hardware implementing SDL must have access 82 to the packet length when generating the header, and where a router's 83 input link does not readily have this information (that is, for non- 84 SDL input links), the router may be required to buffer the entire 85 packet before transmission. "Worm-hole" routing is thus at least 86 problematic with SDL, unless the input links are also SDL. This, 87 however, does not appear to be a great disadvantage on modern routers 88 due to the general requirement of length information in other parts 89 of the system, notably in queueing and congestion control strategies 90 such as Weighted Fair Queuing [12] and Random Early Detection [13]. 92 Table of Contents 94 1. Introduction ............................................... 5 95 2. Physical Layer Requirements ................................ 6 96 2.1. Payload Types ............................................ 6 97 2.2. Control Signals .......................................... 6 98 2.3. Synchronization Modes .................................... 6 99 2.4. Framing .................................................. 6 100 2.5. Synchronization Procedure ................................ 9 101 2.6. Scrambler Operation ...................................... 9 102 2.7. CRC Generation ........................................... 10 103 2.8. Error Correction ......................................... 10 104 3. Performance Analysis ....................................... 11 105 3.1. Mean Time To Frame (MTTF) ................................ 12 106 3.2. Mean Time To Synchronization (MTTS) ...................... 13 107 3.3. Probability of False Frame (PFF) ......................... 13 108 3.4. Probability of False Synchronization (PFS) ............... 13 109 3.5. Probability of Loss of Frame (PLF) ....................... 14 110 4. The Special Messages ....................................... 14 111 4.1. Scrambler State .......................................... 14 112 4.2. A/B Message .............................................. 14 113 5. The Set-Reset Scrambler Option ............................. 14 114 5.1. The Killer Packet Problem ................................ 15 115 5.2. SDL Set-Reset Scrambler .................................. 15 116 5.3. SDL Scrambler Synchronization ............................ 15 117 5.4. SDL Scrambler Operation .................................. 16 118 6. Configuration Details ...................................... 18 119 Appendix A: CRC Generation .................................... 19 120 Appendix B: Error Correction Tables ........................... 21 121 7. Security Considerations .................................... 23 122 8. References ................................................. 23 123 9. Acknowledgments ............................................ 24 124 10. Intellectual Properties Considerations .................... 24 125 11. Authors' Addresses ........................................ 25 127 1. Introduction 129 The term packet-over-lightwave (POL) has been used to refer to the 130 capability of transmitting packet data directly over a raw lightwave 131 channel, also referred to as "dark fiber", without an intervening 132 SONET/SDH or optical transport network (OTN) layer. POL solutions are 133 attractive in data networking scenarios were neither multi- 134 segment/multi-path transport nor the OAM&P capabilities of optical 135 transport networking or SONET/SDH is required. SDL on POL does not 136 rely on SONET/SDH or OTN overheads to enable networking features such 137 as transmission quality assessment, protection switching/restoration, 138 and OAM&P. Performance assessment, switching and OAM&P capabilities 139 for SDL on POL are not defined in this document 141 This document describes a method to enable the use of SDL framing for 142 PPP over such raw lightwave channels and describes the framing and 143 encapsulation requirements for PPP.. The protocol stack is illus- 144 trated in Figure 1. While bit-synchronous HDLC-like framing has a 145 worst-case octet overhead of 20% for some specific data patterns, SDL 146 uses no payload encoding, and hence, has zero payload overhead. 148 +--------------------------+ 149 | | 150 | Higher-layer Protocol | 151 | | 152 +--------------------------+ 153 | | 154 | PPP | 155 | | 156 +--------------------------+ 157 | | 158 | SDL | 159 | | 160 +--------------------------+ 161 | | 162 | Raw Lightwave Channel | 163 | | 164 +--------------------------+ 166 Figure 1: Protocol stack for PPP over SDL over a raw lightwave channel. 168 2. Physical Layer Requirements 170 The transport mode for SDL on POL is packet-oriented. The raw 171 lightwave links are intrinsically bit-synchronous even though PPP 172 treats the lower transport layer as a full-duplex octet-oriented syn- 173 chronous interface. No provision is made to support sending or 174 receiving bare octets over lightwaves (as is the case with 175 SONET/SDH). 177 2.1. Payload Types 179 Only bit-synchronous payloads at STS-1 and higher line rates are 180 currently considered in this document. Operations at lower bit rates 181 is feasible but not considered at present. Mappings of plesiochronous 182 payloads, such as T1 and T3, on to SDL are not considered in this 183 document. 185 2.2. Control Signals 187 A prior-arrangement method is required to enable SDL framing for POL. 188 No LCP-negotiated method is currently proposed. LCP may be used to 189 negotiated other PPP-related parameters (see sections 2.4 and 6). 191 2.3. Synchronization Modes 193 Unlike non-SDL O-S encapsulations, SDL provides a positive indication 194 that it has achieved synchronization with the peer. An SDL PPP 195 implementation MUST provide a means to temporarily suspend PPP data 196 transmission (both user data and negotiation traffic) if synchroniza- 197 tion loss is detected. An SDL PPP implementation SHOULD also provide 198 a configurable timer that is started when SDL is initialized and res- 199 tarted on the loss of synchronization, and is terminated when link 200 synchronization is achieved. If this timer expires, implementation- 201 dependent action should be taken to report the hardware failure. 203 2.4. Framing 205 PPP over SDL over raw lightwave channels uses the same data link 206 frame format as for PPP over SDL over SONET/SDH [4]. When SDL framing 207 for PPP is employed, the SDL "Datagram Offset" is fixed at 4, and the 208 "A" and "B" messages are not used. Additional information on these 209 optional features of SDL can be found in Lucent's SDL specification 210 [8]. 212 Fixing the Datagram Offset to 4 allows a PPP MRU/MTU of 65536 using 213 SDL. 215 SDL framing is in general accomplished by the use of a four octet 216 header on the packet. This fixed-length header allows the use of a 217 simple framer to detect synchronization as described in section 2.6. 218 For use with PPP, this header precedes each raw PPP packet as fol- 219 lows: 221 0 1 2 3 222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Packet Length | Header CRC | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | PPP packet (beginning with address and control fields) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | ..... | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Packet CRC | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 The four octet length header is DC balanced by exclusive-OR (also 234 known as "modulo 2 addition") with the hex value B6AB31E0. This is 235 the maximum transition, minimum sidelobe, Barker-like sequence of 236 length 32. No other scrambling is done on the header itself. 238 Packet Length is an unsigned 16 bit number in network byte order. 239 Unlike the standard PPP FCS, the Header CRC is a CRC-16 generated 240 with initial value zero and transmitted in standard network byte 241 order. The PPP packet is scrambled, and begins with the standard 242 address and control fields, and may be any integral octet length 243 (i.e., it is not padded unless the Self Describing Padding option is 244 used). The Packet CRC is also scrambled, and has a mode-dependent 245 length (described below), and is located only on an octet boundary; 246 no alignment of this field may be assumed. 248 When the Packet Length value is 4 or greater, the distance in octets 249 between one message header and the next in SDL is the sum of Packet 250 Length field, Datagram Offset value, and the fixed size of the Packet 251 CRC field. The Datagram Offset is a configurable SDL parameter, 252 which is set to the fixed value 4 for PPP. When the Packet Length is 253 0, the distance to the next header is 4 octets. This is the idle 254 fill header. When the Packet Length is 1 to 3, the distance to the 255 next header is 12 octets. These headers are used for special SDL 256 messages used only with optional scrambling and management modes. 257 See section 5 for details of the messages. 259 General SDL, like PPP, allows the use of no CRC, ITU-T CRC-16, or 260 ITU-T CRC-32 for the packet data. However, because the Packet Length 261 field does not include the CRC length, synchronization cannot be 262 maintained if the CRC type is changed per RFC 1570, because frame- 263 to-frame distance is, as described above, calculated including the 264 CRC length. Although synchronization can be regained by readjusting 265 the receiver's frame-to-frame distance after a CRC negotiation, this 266 PPP over SDL specification fixes the CRC type to CRC-32 (four 267 octets), and all SDL implementations MUST reject any LCP FCS Alterna- 268 tives Option [9] requested by the peer when in SDL mode. 270 PPP over SDL implementations MAY allow a configuration option to set 271 different CRC types for use by prior arrangement. Any such configur- 272 able option MUST default to CRC-32, and MUST NOT be include LCP nego- 273 tiation of FCS Alternatives. 275 With the SDL Datagram Offset set to 4, the value placed in the Packet 276 Length field is exactly the length in octets of the PPP frame itself, 277 including the address and control fields but not including the FCS 278 field. 280 Because Packet Lengths below 4 are reserved, the Packet Length MUST 281 be 4 or greater for any legal PPP packet. PPP packets with fewer 282 octets, which are not possible without address/control or protocol 283 field compression, MUST be padded to length 4 for SDL. 285 Inter-packet time fill is accomplished by sending the four octet 286 length header with the Packet Length set to zero. No provision is 287 made for intra-packet time fill. 289 By default, an independent, self-synchronous x^43+1 scrambler is used 290 on the data portion of the message including the 32 bit CRC. This is 291 done in exactly the same manner as with the ATM x^43+1 scrambler on a 292 SONET/SDH link. The scrambler is not clocked when SDL header bits 293 are transmitted. Thus, the data scrambling can be implemented in an 294 entirely independent manner from the SDL framing. 296 Optionally, by prior arrangement, SDL links MAY use a set-reset 297 scrambler as described in section 2.9. If this option is provided, 298 it MUST be configurable by the administrator, and the option MUST 299 default to the self-synchronous scrambler. 301 Once the link enters SYNCH state, the SDL header single bit error 302 correction logic is enabled (see section 2.9). Any unrecoverable 303 header CRC error returns the link to HUNT state, disables PPP 304 transmission, and disables the error correction logic. 306 2.5. Synchronization Procedure 308 The link synchronization procedure is similar to the I.432 section 309 4.5.1.1 ATM HEC delineation procedure [10], except that the SDL mes- 310 sages are variable length. The machine starts in HUNT state until a 311 four octet sequence in the data stream with a valid CRC-16 is found. 312 (Note that the CRC-16 single-bit error correction technique described 313 in section 2.9 is not employed until the machine is in in SYNCH 314 state. The header must have no bit errors in order to leave HUNT 315 state.) Such a valid sequence is a candidate SDL header. On finding 316 the valid sequence, the machine enters PRESYNCH state. Any one 317 invalid SDL header in PRESYNCH state returns the link to HUNT state. 319 If a second valid SDL header is seen after entering PRESYNCH state, 320 then the link enters SYNCH state and PPP transmission is enabled. If 321 an invalid SDL header is detected, then the link is returned to HUNT 322 state without enabling PPP transmission. 324 2.6. Scrambler Operation 326 The transmit and receive scramblers are shift registers with 43 327 stages that MAY be initialized to all-ones when the link is initial- 328 ized. Synchronization is maintained by the data itself. 330 Transmit Receive 332 DATA-STREAM (FROM PPP) IN (FROM SDL FRAMER) 333 | | 334 v | 335 XOR<-------------------------+ +->D0-+->D1-> ... ->D41->D42-+ 336 | | | | 337 +->D0-+->D1-> ... ->D41->D42-+ XOR<-------------------------+ 338 | | 339 v v 340 OUT (TO SDL FRAMER) DATA-STREAM (TO PPP) 342 Each XOR is an exclusive-or gate; also known as a modulo-2 adder. 343 Each Dn block is a D-type flip-flop clocked on the appropriate data 344 clock. 346 The scrambler is clocked once after transmission or reception of each 347 bit of payload and before the next bit is applied as input. Bits 348 within an octet are, per SONET/SDH standard practice, transmitted and 349 received MSB-first. 351 2.7. CRC Generation 353 The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-T 354 standard polynomials [11]. These are: 356 x^16+x^12+x^5+1 358 x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1 360 The SDL Header CRC and the CRC-16 used for each of the three special 361 messages (scrambler state, message A, and message B; see section 5) 362 are all generated using an initial remainder value of 0000 hex. 364 The optional CRC-16 on the payload data (this mode is not used with 365 PPP over SDL except by prior arrangement) uses the standard initial 366 remainder value of FFFF hex for calculation and the bits are comple- 367 mented before transmission. The final CRC remainder, however, is 368 transmitted in network byte order, unlike the regular PPP FCS. If 369 the CRC-16 algorithm is run over all of the octets including the 370 appended CRC itself, then the remainder value on intact packets will 371 always be E2F0 hex. Alternatively, an implementation may stop CRC 372 calculation before processing the appended CRC itself, and do a 373 direct comparison. 375 The standard CRC-32 on the payload data (used for standard PPP over 376 SDL) uses the initial remainder value of FFFFFFFF hex for calculation 377 and the bits are complemented before transmission. The CRC, however, 378 is transmitted in network byte order, most significant bit first, 379 unlike the optional PPP 32 bit FCS, which is transmitted in reverse 380 order. The remainder value on intact packets when the appended CRC 381 value is included in the calculation is 38FB2284. 383 C code to generate these CRCs is found in Appendix A. 385 2.8. Error Correction 387 The error correction technique is based on the use of a Galois number 388 field, as with the ATM HEC correction. In a Galois number field, 389 f(a+b) = f(a) + f(b). Since the CRC-16 used for SDL forms such a 390 field, we can state that CRC(message+error) = CRC(message) + 391 CRC(error). Since the CRC-16 remainder of a properly formed message 392 is always zero, this means that, for the N distinct "error" strings 393 corresponding to a single bit error, there are N distinct CRC(error) 394 values, where N is the number of bits in the message. 396 A table look-up is thus applied to the CRC-16 residue after calcula- 397 tion over the four octet SDL header to correct bit errors in the 398 header and to detect multiple bit errors. For the optional set-reset 399 scrambler, a table look-up is similarly applied to the CRC-16 residue 400 after calculation over the eight octet scrambler state message to 401 correct bit errors and to detect multiple bit errors. (This second 402 correction is also used for the special SDL A and B messages, which 403 are not used for standard PPP over SDL.) 405 Note: No error correction is performed for the payload. 407 Note: This error correction technique is used only when the link has 408 entered SYNCH state. While in HUNT or PRESYNCH state, error correc- 409 tion should not be performed, and only messages with syndrome 0000 410 are accepted. If the calculated syndrome does not appear in this 411 table, then an unrecoverable error has occurred. Any such error in 412 the SDL header will return the link to HUNT state. 414 Since the CRC calculation is started with zero, the two tables can be 415 merged. The four octet table is merely the last 32 entries of the 416 eight octet table. 418 Eight octet (64 bit) single bit error syndrome table (in hex): 420 FD81 F6D0 7B68 3DB4 1EDA 0F6D 8FA6 47D3 421 ABF9 DDEC 6EF6 377B 93AD C1C6 60E3 B861 422 D420 6A10 3508 1A84 0D42 06A1 8B40 45A0 423 22D0 1168 08B4 045A 022D 8906 4483 AA51 424 DD38 6E9C 374E 1BA7 85C3 CAF1 ED68 76B4 425 3B5A 1DAD 86C6 4363 A9A1 DCC0 6E60 3730 426 1B98 0DCC 06E6 0373 89A9 CCC4 6662 3331 427 9188 48C4 2462 1231 8108 4084 2042 1021 429 Thus, if the syndrome 6EF6 is seen on an eight octet message, then 430 the third bit (hex 20) of the second octet is in error. Similarly, 431 if 48C4 is seen on an eight octet message, then the second bit (hex 432 40) in the eighth octet is in error. For a four octet message, the 433 same two syndromes would indicate a multiple bit error for 6EF6, and 434 a single bit error in the second bit of the fourth octet for 48C4. 436 Note that eight octet messages are used only for the optional set- 437 reset scrambling mode, described in section 6. 439 Corresponding C code to generate this table is found in Appendix B. 441 3. Performance Analysis 443 There are five general statistics that are important for framing 444 algorithms. These are: 446 MTTF Mean time to frame 447 MTTS Mean time to synchronization 448 PFF Probability of false frame 449 PFS Probability of false synchronization 450 PLF Probability of loss of frame 452 The following sections summarize each of these statistics for SDL. 453 Details and mathematic development can be found in the Lucent SDL 454 documentation [8]. 456 3.1. Mean Time To Frame (MTTF) 458 This metric measures the amount of time required to establish correct 459 framing in the input data. This may be measured in any convenient 460 units, such as seconds or bytes. For SDL, the relevant measurement 461 is in packets, since fragments of packets are not useful. 463 In order to calculate MTTF, we must first determine how often the 464 frame detection state machine is "unavailable" because it failed to 465 detect the next incoming SDL frame within the user data. 467 Since the probability of a false header detection using CRC-16 in 468 random data is 2^-16 and this rate is large compared to the allowable 469 packet size, it is worthwhile to run multiple parallel frame- 470 detection state machines. Each machine starts with a different can- 471 didate framing point in order to reduce the probability of falsely 472 detecting user data as a valid frame header. 474 The results for this calculation for 64KB, 8KB and 384B packets are: 476 Number of Unavailability Unavailability Unavailability 477 Framers 64Kb Packets 8KB packets 384 byte pkts 478 1 8.75E-1 3.68E-1 2.31E-2 479 2 7.50E-1 1.04E-1 3.57E-4 480 3 6.27E-1 2.32E-2 4.17E-6 481 4 5.08E-1 4.35E-3 3.89E-8 483 Using these values, MTTF can be calculated as a function of the Bit 484 Error Rate (BER). These plots show a characteristically flat region 485 for all BERs up to a knee, beyond which the begins to rise sharply. 486 In all cases, this knee point has been found to occur at a BER of 487 approximately 1E-4, which is several orders of magnitude above that 488 observed on existing SONET/SDH links. The flat rate values are sum- 489 marized as: 491 Number of Flat Region Flat region Flat region 492 Framers 64KB Packets 8KB packets 384B packets 493 1 8.50 2.08 1.52 494 2 4.57 1.62 1.50 495 3 3.18 1.52 1.50 496 4 2.53 1.50 1.50 498 Thus, for common packet sizes in an implementation with two parallel 499 framers using links with a BER of 1E-4 or better, the MTTF is approx- 500 imately 1.5 packets. This is also the optimal time, since it 501 represents initiating framing at an average point half-way into one 502 packet, and achieving good framing after seeing exactly one correctly 503 framed packet. 505 Note that the numbers in both tables apply only after the link loses 506 synchronization, which is by itself a very rare event as per the 507 estimate PLF in seccion 3.5. 509 3.2. Mean Time To Synchronization (MTTS) 511 The MTTS for standard SDL with a self-synchronous scrambler is the 512 same as the MTTF, or 1.5 packets. 514 The MTTS for SDL using the optional set-reset scrambler is one half 515 of the scrambling state transmission interval (in packets) plus the 516 MTTF. For insertion at the default rate of one per eight packets, 517 the MTTS is 5.5 packets. 519 (The probability of receiving a bad scrambling state transmission 520 should also be included in this calculation. The probability of ran- 521 dom corruption of this short message is shown in the SDL document [8] 522 to be small enough that it can be neglected for this calculation.) 524 3.3. Probability of False Frame (PFF) 526 The PFF is 232.8E-12 (2^-32), since false framing requires two con- 527 secutive headers with falsely correct CRC-16. 529 3.4. Probability of False Synchronization (PFS) 531 The PFS for the standard self-synchronous scrambler is the same as 532 the PFF, or 232.8E-21 (2^-32). 534 The PFS for the set-reset scrambler is 54.21E-21 (2^-64), and is cal- 535 culated as the PFF above multiplied by the probability of a falsely 536 detected scrambler state message, which itself contains two indepen- 537 dent CRC-16 calculations. 539 3.5. Probability of Loss of Frame (PLF) 541 The PLF is a function of the BER, and for SDL is approximately the 542 square of the BER multiplied by 500, which is the probability of two 543 or more bit errors occurring within the 32 bit SDL header. Thus, at a 544 BER of 1E-5, the PLF is 5E-8. For the typical fiber BER, between 1E- 545 10 to 1E-12, frame delineation loss would occur less than once every 546 year, on the average, even at OC-768 rates. 548 4. The Special Messages 550 When the SDL Packet Length field has any value between 0000 and 0003, 551 the message following the header has a special, pre-defined length. 552 The 0 value is a time-fill on an idle link, and no other data fol- 553 lows. The next octet on the link is the first octet of the next SDL 554 header. 556 The values 1 through 3 are defined in the following subsections. 557 These special messages each consist of a six octet data portion fol- 558 lowed by another CRC-16 over that data portion, as with the SDL 559 header, and this CRC is used for single bit error correction. 561 4.1. Scrambler State 563 The special value of 1 for Packet Length is reserved to transfer the 564 scrambler state from the transmitter to the receiver for the optional 565 set-reset scrambler. In this case, the SDL header is followed by six 566 octets (48 bits) of scrambler state. Neither the scrambler state nor 567 the CRC are scrambled. 569 4.2. A/B Message 571 The special values of 2 and 3 for Packet Length are reserved for "A" 572 and "B" messages, which are also six octets in length followed by two 573 octets of CRC-16. Each of these eight octets are scrambled. No use 574 for these messages with PPP SDL is defined. These messages are 575 reserved for use by link maintenance protocols, in a manner analogous 576 to ATM's OAM cells. 578 5. The Set-Reset Scrambler Option 580 Standard PPP over SDL uses a self-synchronous scrambler. SDL imple- 581 mentations MAY also employ a set-reset scrambler to avoid some of the 582 possible inherent problems with self-synchronous scramblers. 584 5.1. The Killer Packet Problem 586 Scrambling in general solves two problems. First, most line inter- 587 faces (e.g., SONET/SDH) require a minimum density of bit transitions 588 in order to maintain hardware clock recovery. Since data streams 589 frequently contain long runs of all zeros or all ones, scrambling the 590 bits using a pseudo-random number sequence breaks up these patters. 591 Second, all link-layer synchronization mechanisms rely on detecting 592 long-range patterns in the received data to detect framing. 594 Self-synchronous scramblers are an easy way to partially avoid these 595 problems. One problem that is inherent with self-synchronous, how- 596 ever, is that long user packets from malicious sites can make use of 597 the known properties of these scramblers to inject either long 598 strings of zeros or other synchronization-destroying patterns into 599 the link. 601 Such carefully constructed packets are called "killer packets." 603 5.2. SDL Set-Reset Scrambler 605 An alternative to the self-synchronous scrambler is the externally 606 synchronized or "set-reset" scrambler. This is a free-running scram- 607 bler that is not affected by the patterns in the user data, and 608 therefore minimizes the possibility that a malicious user could 609 present data to the network that mimics an undesirable data pattern. 611 The option set-reset scrambler defined for SDL is an 612 x^48+x^28+x^27+x+1 independent scrambler initialized to all ones when 613 the link enters PRESYNCH state and reinitialized if the value ever 614 becomes all zero bits. As with the self-synchronous scrambler, all 615 octets in the PPP packet data following the SDL header through the 616 final packet CRC are scrambled. 618 5.3. SDL Scrambler Synchronization 620 As described in the previous section, the special value of 1 for 621 Packet Length is reserved to transfer the scrambler state from the 622 transmitter to the receiver. In this case, the SDL header is fol- 623 lowed by six octets (48 bits) of scrambler state plus two octets of 624 CRC-16 over the scrambler state. None of these eight octets are 625 scrambled. 627 SDL synchronization consists of two components, link and scrambler 628 synchronization. Both must be completed before PPP data flows on the 629 link. 631 If a valid SDL header is seen in PRESYNCH state, then the link enters 632 SYNCH state, and the scrambler synchronization sequence is started. 633 If an invalid SDL header is detected, then the link is returned to 634 HUNT state, and PPP transmission is suspended. 636 When scrambler synchronization is started, a scrambler state message 637 is sent (Packet Length set to 1 and six octets of scrambler state in 638 network byte order follow the SDL header). This message is sent 639 once. At this point, PPP transmission is enabled. 641 Scrambler state messages are periodically transmitted to keep the 642 peers in synchronization. A period of once per eight transmitted 643 packets is suggested, and it SHOULD be configurable. Excessive 644 packet CRC errors detected indicates an extended loss of synchroniza- 645 tion and should trigger link resynchronization. 647 On reception of a scrambler state message, an SDL implementation MUST 648 compare the received 48 bits of state with the receiver's scrambler 649 state. If any of these bits differ, then a synchronization slip 650 error is declared. After such an error, the next valid scrambler 651 state message received MUST be loaded into the receiver's scrambler, 652 and the error condition is then cleared. 654 5.4. SDL Scrambler Operation 656 The transmit and receive scramblers are shift registers with 48 657 stages that are initialized to all-ones when the link is initialized. 658 Each is refilled with all one bits if the value in the shift register 659 ever becomes all zeros. This scrambler is not reset at the beginning 660 of each frame, as is the SONET/SDH X^7+X^6+1 scrambler, nor is it 661 modified by the transmitted data, as is the ATM self-synchronous 662 scrambler. Instead it is kept in synchronization using special SDL 663 messages. 665 +----XOR<--------------XOR<---XOR<----------------+ 666 | ^ ^ ^ | 667 | | | | | 668 +->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+ 669 | 670 v 671 OUT 673 Each XOR is an exclusive-or gate; also known as a modulo-2 adder. 674 Each Dn block is a D-type flip-flop clocked on the appropriate data 675 clock. 677 The scrambler is clocked once after transmission of each bit of SDL 678 data, whether or not the transmitted bit is scrambled. When scram- 679 bling is enabled for a given octet, the OUT bit is exclusive-ored 680 with the raw data bit to produce the transmitted bit. Bits within an 681 octet are transmitted MSB-first. 683 Reception of scrambled data is identical to transmission. Each 684 received bit is exclusive-ored with the output of the separate 685 receive data scrambler. 687 To generate a scrambler state message, the contents of D47 through D0 688 are snapshot at the point where the first scrambler state bit is 689 sent. D47 is transmitted as the first bit of the output. The first 690 octet transmitted contains D47 through D40, the second octet D39 691 through D32, and the sixth octet D7 through D0. 693 The receiver of a scrambler state message MUST first run the CRC-16 694 check and correct algorithm over this message. If the CRC-16 message 695 check detects multiple bit errors, then the message is dropped and is 696 not processed further. 698 Otherwise, it then should compare the contents of the entire receive 699 scrambler state D47:D0 with the corrected message. (By pipelining 700 the receiver with multiple clock stages between SDL Header error- 701 correction block and the descrambling block, the receive descrambler 702 will be on the correct clock boundary when the message arrives at the 703 descrambler. This means that the decoded scrambler state can be 704 treated as immediately available at the beginning of the D47 clock 705 cycle into the receive scrambler.) 707 If any of the received scrambler state bits is different from the 708 corresponding shift register bit, then a soft error flag is set. If 709 the flag was already set when this occurs, then a synchronization 710 slip error is declared. This error SHOULD be counted and reported 711 through implementation-defined network management procedures. When 712 the receiver has this soft error flag set, any scrambler state mes- 713 sage that passes the CRC-16 message check without multiple bit errors 714 is clocked directly into the receiver's state register after the com- 715 parison is done, and the soft error flag is then cleared. Otherwise, 716 while uncorrectable scrambler state messages are received, the soft 717 error flag state is maintained. 719 (The intent of this mechanism is to reduce the likelihood that a 720 falsely corrected scrambler state message with multiple bit errors 721 can corrupt the running scrambler state.) 723 6. Configuration Details 725 The following PPP Configuration Options are recommended: 727 Magic Number 728 No Address and Control Field Compression 729 No Protocol Field Compression 730 No FCS alternatives (32-bit FCS default) 732 This configuration means that standard PPP over SDL on POL generally 733 presents a 32-bit aligned datagram to the network layer. With the 734 address, control, and protocol field intact, the PPP overhead on each 735 packet is four octets. If the SDL framer presents the SDL packet 736 header to the PPP input handling in order to communicate the packet 737 length , this header is also four octets, and word-alignment is 738 preserved. 740 Since SDL does take the place of HDLC as a transport for PPP, it is 741 at least tempting to remove the HDLC-derived overhead. This is not 742 done for standard PPP over SDL in order to preserve the message 743 alignment and the future possibility of Frame Relay internetworking. 745 By prior external arrangement, any two SDL implementations MAY omit 746 the address and control fields or implement protocol field compres- 747 sion. Such use is not standardized and MUST NOT be the default on 748 any SDL implementation. 750 Appendix A: CRC Generation 752 The following unoptimized code generates proper CRC-16 and CRC-32 753 values for SDL messages. Note that the polynomial bits are numbered 754 in big-endian order for SDL CRCs; bit 0 is the MSB. 756 typedef unsigned char u8; 757 typedef unsigned short u16; 758 typedef unsigned long u32; 760 #define POLY16 0x1021 761 #define POLY32 0x04C11DB7 763 u16 764 crc16(u16 crcval, u8 cval) 765 { 766 int i; 768 crcval ^= cval << 8; 769 for (i = 8; i--; ) 770 crcval = crcval & 0x8000 ? (crcval << 1) ^ POLY16 : 771 crcval << 1; 772 return crcval; 773 } 775 u32 776 crc32(u32 crcval, u8 cval) 777 { 778 int i; 780 crcval ^= cval << 24; 781 for (i = 8; i--; ) 782 crcval = crcval & 0x80000000 ? (crcval << 1) ^ POLY32 : 783 crcval << 1; 784 return crcval; 785 } 787 u16 788 crc16_special(u8 *buffer, int len) 789 { 790 u16 crc; 792 crc = 0; 793 while (--len >= 0) 794 crc = crc16(crc,*buffer++); 795 return crc; 796 } 797 u16 798 crc16_payload(u8 *buffer, int len) 799 { 800 u16 crc; 802 crc = 0xFFFF; 803 while (--len >= 0) 804 crc = crc16(crc,*buffer++); 805 return crc ^ 0xFFFF; 806 } 808 u32 809 crc32_payload(u8 *buffer, int len) 810 { 811 u32 crc; 813 crc = 0xFFFFFFFFul; 814 while (--len >= 0) 815 crc = crc32(crc,*buffer++); 816 return crc ^ 0xFFFFFFFFul; 817 } 819 void 820 make_sdl_header(int packet_length, u8 *buffer) 821 { 822 u16 crc; 824 buffer[0] = (packet_length >> 8) & 0xFF; 825 buffer[1] = packet_length & 0xFF; 826 crc = crc16_special(buffer,2); 827 buffer[0] ^= 0xB6; 828 buffer[1] ^= 0xAB; 829 buffer[2] = ((crc >> 8) & 0xFF) ^ 0x31; 830 buffer[3] = (crc & 0xFF) ^ 0xE0; 831 } 833 Appendix B: Error Correction Tables 835 To generate the error correction table, the following implementation 836 may be used. It creates a table called sdl_error_position, which is 837 indexed on CRC residue value. The tables can be used to determine if 838 no error exists (table entry is equal to FE hex), one correctable 839 error exists (table entry is zero-based index to errored bit with MSB 840 of first octet being 0), or more than one error exists, and error is 841 uncorrectable (table entry is FF hex). To use for eight octet mes- 842 sages, the bit index from this table is used directly. To use for 843 four octet messages, the index is treated as an unrecoverable error 844 if it is below 32, and as bit index plus 32 if it is above 32. 846 The program also prints out the error syndrome table shown in section 847 2.9. This may be used as part of a "switch" statement in a hardware 848 implementation. 850 u8 sdl_error_position[65536]; 852 /* Calculate new CRC from old^(byte<<8) */ 853 u16 854 crc16_t8(u16 crcval) 855 { 856 u16 f1,f2,f3; 858 f1 = (crcval>>8) | (crcval<<8); 859 f2 = (crcval>>12) | (crcval&0xF000) | ((crcval>>7)&0x01E0); 860 f3 = ((crcval>>3) & 0x1FE0) ^ ((crcval<<4) & 0xF000); 861 return f1^f2^f3; 862 } 864 void 865 generate_error_table(u8 *bptab, int nbytes) 866 { 867 u16 crc; 868 int i, j, k; 870 /* Marker for no error */ 871 bptab[0] = 0xFE; 873 /* Marker for >1 error */ 874 for (i = 1; i < 65536; i++ ) 875 bptab[i] = 0xFF; 877 /* Mark all single bit error cases. */ 878 printf("Error syndrome table:\n"); 879 for (i = 0; i < nbytes; i++) { 880 putchar(' '); 881 for (j = 0; j < 8; j++) { 882 crc = 0; 883 for (k = 0; k < i; k++) 884 crc = crc16_t8(crc); 885 crc = crc16_t8(crc ^ (0x8000>>j)); 886 for (k++; k < nbytes; k++) 887 crc = crc16_t8(crc); 888 bptab[crc] = (i * 8) + j; 889 printf(" %04X",crc); 890 } 891 putchar('\n'); 892 } 893 } 895 int 896 main(int argc, char **argv) 897 { 898 u8 buffer[8] = { 899 0x01,0x55,0x02,0xaa, 900 0x99,0x72,0x18,0x56 901 }; 902 u16 crc; 903 int i; 905 generate_error_table(sdl_error_position,8); 907 /* Run sample message through check routine. */ 908 crc = 0; 909 for (i = 0; i < 8; i++) 910 crc = crc16_t8(crc ^ (buffer[i]<<8)); 912 /* Output is 0000 64 -- no error encountered. */ 913 printf("\nError test: CRC %04X, bit position %d\n", 914 crc,sdl_message_error_position[crc]); 915 } 917 7. Security Considerations 919 The reliability of communication networks places special requirements 920 in the handling of data payloads as appropriate to the specific line 921 encoding schemes. This document describes framing and scrambling 922 options for SDL over raw lightwave channels that enable the use of 923 current typical design (non burst mode) optical transceiver and tim- 924 ing subsystem. In particular, this proposal is compatible with DWDM 925 regenerator networks. No other security concerns have been identi- 926 fied. 928 8. References 930 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)," RFC 931 1661, Daydreamer, July 1994. 933 [2] Simpson, W., Editor, "PPP in HDLC-like Framing," RFC 1662, 934 Daydreamer, July 1994. 936 [3] Simpson, W., Editor, "PPP over SONET/SDH," RFC 1619, Daydreamer, 937 May 1994. 939 [4] Carlson, Langner, Hernandez-Valencia, Manchester, "PPP over 940 Simple Data Link (SDL) using SONET/SDH with ATM-like 941 framing." PPPEXT WG work in progress. 943 [5] "American National Standard for Telecommunications - 944 Synchronous Optical Network (SONET) Payload Mappings," ANSI 945 T1.105.02-1995. 947 [6] ITU-T Recommendation G.707, "Network Node Interface for the 948 Synchronous Digital Hierarchy (SDH)," March 1996. 950 [7] ITU-T Recommendation G.872, "Architecture of Optical 951 Transport Networks," February 1999. 953 [8] Doshi,B., Dravida, S., Hernandez-Valencia, E., Matragi, W., 954 Qureshi, M., Anderson, J., Manchester, J.,"A Simple Data Link 955 Protocol for High Speed Packet Networks", Bell Labs Technical 956 Journal, pp. 85-104, Vol.4 No.1, January-March 1999. 958 [9] Simpson, W., Editor, "PPP LCP Extensions," RFC 1570, Daydreamer, 959 January 1994. 961 [10] ITU-T Recommendation I.432.1, "B-ISDN User-Network Interface - 962 Physical Layer Specification: General Characteristics," 963 February 1999. 965 [11] ITU-T Recommendation V.41, "Code-independent error-control 966 system," November 1989. 968 [12] Demers, A., S. Keshav, and S. Shenker, "Analysis and 969 simulation of a fair queueing algorithm," ACM SIGCOMM volume 970 19 number 4, pp. 1-12, September 1989. 972 [13] Floyd, S. and V. Jacobson, "Random Early Detection Gateways 973 for Congestion Avoidance," IEEE/ACM Transactions on 974 Networking, August 1993. 976 9. Acknowledgments 978 The authors recognize Jon Anderson, Bharat Doshi, Subra Dravida and 979 James Manchester from Lucent Technologies for their various contribu- 980 tions to this work. 982 10. Intellectual Properties Considerations 984 Lucent Technologies Inc. may own intellectual property on some of the 985 technologies disclosed in this document. The patent licensing policy 986 of Lucent Technologies Inc. with respect to any patents or patent 987 applications relating to this submission is stated in the March 1, 988 1999, letter to the IETF from Dr. Roger E. Stricker, Intellectual 989 Property Vice President, Lucent Technologies Inc. This letter is on 990 file in the offices of the IETF Secretariat. 992 IronBridge Networks has no claim on any of this material. 994 11. Authors' Addresses 996 James Carlson 997 IronBridge Networks 998 55 Hayden Avenue 999 Lexington MA 02421-7996 1000 Phone: +1 781 372 8132 1001 Fax: +1 781 372 8090 1002 Email: carlson@ibnets.com 1004 Enrique J. Hernandez-Valencia 1005 Lucent Technologies Bell Laboratories 1006 101 Crawford Corners Rd. 1007 Holmdel NJ 07733-3030 1008 Email: enrique@lucent.com 1010 Nevin Jones 1011 Lucent Technologies Microelectronics Group 1012 555 Union Boulevard 1013 Allentown PA 18103-1286 1014 Email: nrjones@lucent.com 1016 Paul Langner 1017 Lucent Technologies Microelectronics Group 1018 555 Union Boulevard 1019 Allentown PA 18103-1286 1020 Email: plangner@lucent.com