idnits 2.17.1 draft-ietf-pppext-sdl-05.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: ---------------------------------------------------------------------------- ** 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 0 form feeds but 29 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [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 196: '... of the MUST or MUST NOT requirement...' RFC 2119 keyword, line 197: '...sfies all of the MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 199: '...atisfies all the MUST and MUST NOT req...' RFC 2119 keyword, line 200: '... but not all the SHOULD or SHOULD NOT ...' RFC 2119 keyword, line 228: '...ploying only SDL MUST be capable of tr...' (40 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 1999) is 8959 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 1059, but not defined == Missing Reference: '65536' is mentioned on line 1038, but not defined -- 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' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group J. Carlson 2 Internet Draft IronBridge Networks 3 Expires April 2000 P. Langner 4 Lucent Technologies Microelectronics Group 5 E. J. Hernandez-Valencia 6 Lucent Technologies 7 J. Manchester 8 Lucent Technologies 9 October 1999 11 PPP over Simple Data Link (SDL) 12 using SONET/SDH 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) [1] provides a standard method for 43 transporting multi-protocol datagrams over point-to-point links, and 44 RFCs 1662 [2] and 2615 [3] provide a means to carry PPP over 45 Synchronous Optical Network (SONET) [4] and Synchronous Digital 46 Hierarchy (SDH) [5] circuits. This document extends these standards 47 to include a new encapsulation for PPP called Simple Data Link (SDL) 48 [6]. SDL provides a very low overhead alternative to HDLC-like 49 encapsulation, and can also be used on SONET/SDH links. 51 Applicability 53 This specification is intended for those implementations that use PPP 54 over high speed point-to-point circuits, both with so-called "dark 55 fiber" and over public telecommunications networks. Because this 56 enhanced PPP encapsulation has very low overhead and good hardware 57 scaling characteristics, it is anticipated that significantly higher 58 throughput can be attained when compared to other possible SONET/SDH 59 payload mappings, and at a significantly lower cost for line 60 termination equipment. 62 SDL is defined over other media types and for other data link 63 protocols, but this specification covers only the use of PPP over SDL 64 on SONET/SDH. 66 The use of SDL requires the presentation of packet length information 67 in the SDL header. Thus, hardware implementing SDL must have access 68 to the packet length when generating the header, and where a router's 69 input link does not have this information (that is, for non-SDL input 70 links), the router may be required to buffer the entire packet before 71 transmission. "Worm-hole" routing is thus at least problematic with 72 SDL, unless the input links are also SDL. This, however, does not 73 appear to be a great disadvantage on modern routers due to the 74 general requirement of length information in other parts of the 75 system, notably in queuing and congestion control strategies such as 76 Weighted Fair Queuing [7] and Random Early Detect [8]. 78 This document is not a replacement for the existing HDLC-like framing 79 mandated by RFC 2615 [3]. Instead, the authors intend to gain 80 implementation experience with this technique for operational and 81 performance evaluation purposes, and would like to hear from others 82 either considering or using the protocol as described in this 83 document. Please see Section 15 of this document for contact 84 information. 86 Table of Contents 88 1. Introduction ............................................... 4 89 2. Compliance ................................................. 4 90 3. Physical Layer Requirements ................................ 5 91 3.1. Payload Types ............................................ 5 92 3.2. Control Signals .......................................... 6 93 3.3. Synchronization Modes .................................... 7 94 3.4. Simple-Data-Link LCP Option .............................. 7 95 3.5. Framing .................................................. 8 96 3.6. Framing Example .......................................... 10 97 3.7. Synchronization Procedure ................................ 11 98 3.8. Scrambler Operation ...................................... 11 99 3.9. CRC Generation ........................................... 12 100 3.10. Error Correction ........................................ 13 101 4. Performance Analysis ....................................... 14 102 4.1. Mean Time To Frame (MTTF) ................................ 14 103 4.2. Mean Time To Synchronization (MTTS) ...................... 15 104 4.3. Probability of False Frame (PFF) ......................... 16 105 4.4. Probability of False Synchronization (PFS) ............... 16 106 4.5. Probability of Loss of Frame (PLF) ....................... 16 107 5. The Special Messages ....................................... 16 108 5.1. Scrambler State .......................................... 17 109 5.2. A/B Message .............................................. 17 110 6. The Set-Reset Scrambler Option ............................. 17 111 6.1. The Killer Packet Problem ................................ 17 112 6.2. SDL Set-Reset Scrambler .................................. 18 113 6.3. SDL Scrambler Synchronization ............................ 18 114 6.4. SDL Scrambler Operation .................................. 19 115 7. Configuration Details ...................................... 21 116 7.1. Default LCP Configuration ................................ 21 117 7.2. Modification of the Standard Frame Format ................ 21 118 8. Implementation Details ..................................... 22 119 8.1. CRC Generation ........................................... 22 120 8.2. Error Correction Tables .................................. 24 121 9. Security Considerations .................................... 25 122 10. References ................................................ 26 123 11. Acknowledgments ........................................... 27 124 12. Working Group and Chair Address ........................... 27 125 13. Intellectual Property Notices ............................. 27 126 14. Copyright Notice .......................................... 28 127 15. Authors' Addresses ........................................ 29 129 1. Introduction 131 The Path Signal Label (SONET/SDH overhead byte named C2; referred to 132 as PSL in this document) is intended to indicate the type of data 133 carried on the path. This data, in turn, is referred to as the SONET 134 Synchronous Payload Envelope (SPE) or SDH Administrative Unit Group 135 (AUG). The experimental PSL value of decimal 207 (CF hex) is 136 currently [3] used to indicate that the SPE contains PPP framed using 137 RFC 1662 Octet Synchronous (O-S) framing and transmission without 138 scrambling, and the value 22 (16 hex) is used to indicated PPP framed 139 using O-S framing and transmission with ATM-style X^43+1 scrambling. 141 This document describes a method to enable the use of SDL framing for 142 PPP over SONET/SDH, and describes the framing technique and require- 143 ments for PPP. While O-S framing on SONET/SDH has a fixed seven 144 octet overhead per frame plus a worst-case overhead of 100% of all 145 data octets transmitted, SDL has a fixed eight octet per frame over- 146 head with zero data overhead. Unlike O-S framing, SDL also provides 147 positive indication of link synchronization. 149 Note: This document describes two new SONET/SDH Path Signal Label 150 (PSL) values, 23 (17 hex) and 24 (18 hex). These values have not 151 been allocated by any applicable standards body. A joint contribu- 152 tion has been made to ANSI subcommittee T1X1.5 requesting the assign- 153 ment of 17 hex as the PSL for an SDL over SONET mapping with the pro- 154 posed self synchronous scrambler, and the assignment of 18 hex as the 155 PSL for an SDL over SONET mapping with the proposed set-reset scram- 156 bler in recommendation T1.105. 158 2. Compliance 160 In this document, the words that are used to define the significance 161 of each particular requirement are capitalized. 163 These words are: 165 * "MUST" 167 This word means that the item is an absolute requirement of the 168 specification. 170 * "MUST NOT" 172 This phrase means that the item is an absolute prohibition of the 173 specification. 175 * "SHOULD" 176 This word means that there may exist valid reasons in particular 177 circumstances to ignore this item, but the full implications 178 should be understood and the case carefully weighed before 179 choosing a different course. 181 * "SHOULD NOT" 183 This phrase means that there may exist valid reasons in 184 particular circumstances to apply this item, but the full 185 implications should be understood and the case carefully weighed 186 before choosing a different course. 188 * "MAY" 190 This word means that this item is truly optional. One vendor may 191 choose to include the item because a particular marketplace 192 requires it or because it enhances the product, for example; 193 another vendor may omit the same item. 195 An implementation is not compliant if it fails to satisfy one or more 196 of the MUST or MUST NOT requirements for this protocol. An implemen- 197 tation that satisfies all of the MUST, MUST NOT, SHOULD, and SHOULD 198 NOT requirements for this protocol is said to be "unconditionally 199 compliant." One that satisfies all the MUST and MUST NOT require- 200 ments but not all the SHOULD or SHOULD NOT requirements is said to be 201 "conditionally compliant." 203 3. Physical Layer Requirements 205 PPP treats SONET/SDH transport as octet-oriented synchronous links. 206 No provision is made to transmit partial octets. Also, SONET/SDH 207 links are full-duplex by definition. 209 3.1. Payload Types 211 Only synchronous payloads STS-1 and higher are considered in this 212 document. Lower speed synchronous, such as VT1.5-SPE/VC-11, and 213 plesiochronous payload mappings, such as T1 and T3, are defined for 214 SONET/SDH and for the SDL algorithm itself, but, since HDLC-like 215 framing is defined for PPP on those media, PPP over SDL is not 216 defined. 218 SDL is separately defined as a PPP transport for use on raw fiber 219 without SONET/SDH framing for use as an alternative to bit- 220 synchronous HDLC. Please see the separate work-in-progress for 221 details. 223 3.2. Control Signals 225 The PPP over SONET/SDH mapping allows the use of the PSL as a control 226 signal. Not all equipment, however, is capable of setting or detect- 227 ing this value, and any use must take this into account. Equipment 228 employing only SDL MUST be capable of transmitting PSL with value 23, 229 and MAY also be capable of transmitting PSL with value 24, but need 230 not be capable of detecting the peer's value or capable of changing 231 its own value. 233 There are two methods to enable SDL, an LCP-negotiated method and a 234 prior-arrangement method. The former allows for easier configuration 235 and compatibility with existing equipment, while the latter allows 236 general use with separate SONET/SDH transmission equipment with PSL 237 limitations. Both types of implementations will freely interoperate 238 given the procedures below. 240 LCP-negotiated systems MUST be capable of changing their transmitted 241 PSL value and detecting the peer's value. Equipment without these 242 features MUST NOT support LCP negotiation of SDL. 244 When SDL is negotiated by LCP, LCP negotiation MUST be started with 245 the PSL value initially set to 22 or 207 and the corresponding non- 246 SDL O-S PPP encapsulation MUST be used. The SDL LCP option is then 247 placed in the LCP Configure-Request messages transmitted. On recep- 248 tion of LCP Configure-Request with an SDL LCP option or when the 249 peer's transmitted PSL value is received as 23 (or 24), the implemen- 250 tation MUST shut down LCP by sending a Down event to its state 251 machine, then switch its transmitted PSL value to 23 (or 24), switch 252 encapsulation mode to SDL, wait for SDL synchronization, and then 253 restart LCP by sending an Up event into LCP. Otherwise, if the peer 254 does not transmit PSL value 23 (or 24) and it does not include the 255 SDL LCP option in its LCP Configure-Request messages, then operation 256 using non-SDL O-S PPP encapsulation continues. If the received PSL 257 value subsequently received reverts from 23 (or 24) to any other 258 value, then this is treated as a Down event into the LCP state 259 machine, and an Up event MUST be generated if the new value is recog- 260 nized as a valid PPP framing mode. 262 When SDL is enabled by prior arrangement, the PSL SHOULD be transmit- 263 ted as 23 (or 24). Any other value may also be used by prior exter- 264 nal arrangement with the peer, although the values 22 and 207 are 265 discouraged. (Such use is enforced by an administrator, and is out- 266 side the scope of this specification.) When SDL is enabled by prior 267 arrangement, the SDL LCP option SHOULD NOT be negotiated by the 268 peers. 270 An implementation-specific configuration option SHOULD exist to 271 enable the use of prior-arrangement versus LCP-negotiated modes. 272 This option SHOULD be presented to an administrator, and SHOULD 273 default to LCP-negotiated if the hardware permits. Otherwise, if the 274 hardware implementation precludes non-SDL modes of operation, then it 275 MUST default to prior-arrangement mode. 277 The LCP-negotiated method of operation is compatible with the current 278 version of G.783 [12]. This method may not be compatible, however, 279 with some non-intrusive SDH path monitoring equipment based on 280 obsolete versions of G.783. The change in PSL value indicated by the 281 LCP negotiation method will cause this equipment to declare an alarm 282 condition on the path. For this reason, the prior-arrangement method 283 MUST be used on any SDH network that is using such monitoring equip- 284 ment. 286 3.3. Synchronization Modes 288 Unlike O-S encapsulation, SDL provides a positive indication that it 289 has achieved synchronization with the peer. An SDL PPP implementa- 290 tion MUST provide a means to temporarily suspend PPP data transmis- 291 sion (both user data and negotiation traffic) if synchronization loss 292 is detected. An SDL PPP implementation SHOULD also provide a confi- 293 gurable timer that is started when SDL is initialized and restarted 294 on the loss of synchronization, and is terminated when link synchron- 295 ization is achieved. If this timer expires, implementation-dependent 296 action should be taken to report the hardware failure. 298 3.4. Simple-Data-Link LCP Option 300 A new LCP Configuration Option is used to request Simple Data Link 301 (SDL) [6] operation for the PPP link. 303 A summary of the Simple-Data-Link Configuration Option format for the 304 Link Control Protocol (LCP) is shown below. The fields are transmit- 305 ted from left to right. 307 0 1 308 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type | Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Type 315 29 317 Length 319 2 321 This option is used only as a hint to the peer that SDL over 322 SONET/SDH operation is preferred by the sender. If the current 323 encapsulation mode is not SDL, then the only appropriate response to 324 reception of this option by an SDL speaker is to then switch the 325 encapsulation mode to SDL (as detailed in the section above) and res- 326 tart LCP. Non SDL-speakers SHOULD instead send LCP Configure-Reject 327 for the option. 329 If either LCP Configure-Nak or LCP Configure-Reject is received for 330 this option, then the next transmitted LCP Configure-Request MUST NOT 331 include this option. If LCP Configure-Ack with this option is 332 received, it MUST NOT be treated as a request to switch into SDL 333 mode. If the received LCP Configure-Request message does not contain 334 an SDL LCP option, an implementation MUST NOT send an unsolicited 335 Configure-Nak for the option. 337 (An implementation of SDL that is already in SDL framing mode and 338 receives this option in an LCP Configure-Request message MAY, both 339 for clarity and for convergence reasons, elect to send LCP 340 Configure-Ack. It MUST NOT restart LCP nor change framing modes in 341 this case.) 343 3.5. Framing 345 The PPP frames are located by row within the SPE payload. Because 346 frames are variable in length, the frames are allowed to cross SPE 347 boundaries. Bytes marked as "overhead" or "fixed stuff" in SONET/SDH 348 documentation for concatenated streams are not used as payload bytes. 350 With reference to the Lucent SDL specification [6] when SDL framing 351 for PPP is employed, the SDL "Datagram Offset" feature is set to the 352 value 4. This corresponds to the fixed overhead value 4 in the 353 description below. The "A" and "B" messages are never used. These 354 optional features of SDL are not described in this document, but are 355 rather described in Lucent's SDL specification. 357 Fixing the Datagram Offset value described in the Lucent documenta- 358 tion to 4 allows a PPP MRU/MTU up to 65536 using SDL. 360 SDL framing is in general accomplished by the use of a four octet 361 header on the packet. This fixed-length header allows the use of a 362 simple framer to detect synchronization as described in section 3.7. 363 For use with PPP, this fixed-length header precedes each PPP/HDLC 364 packet as follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Packet Length | Header CRC | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | PPP packet (beginning with address and control fields) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | ..... | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | SDL CRC | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 The four octet length header is DC balanced by exclusive-OR (also 379 known as "modulo 2 addition") with the hex value B6AB31E0. This is 380 the maximum transition, minimum sidelobe, Barker-like sequence of 381 length 32. No other scrambling is done on the header itself. 383 Packet Length is an unsigned 16 bit number in network byte order. 384 Unlike the PPP FCS, the Header CRC is a CRC-16 generated with initial 385 value zero and transmitted in network byte order. The PPP packet is 386 scrambled, begins with the address and control fields, and may be any 387 integral octet length (i.e., it is not padded unless the Self 388 Describing Padding option is used). The Packet CRC is also scram- 389 bled, and has a mode-dependent length (described below), and is 390 located only on an octet boundary; no alignment of this field may be 391 assumed. 393 When the Packet Length value is 4 or greater, the distance in octets 394 between one message header and the next in SDL is the sum of 8 plus 395 the Packet Length field. The value 8 represents a fixed overhead of 396 4 octets plus the fixed length of the Packet CRC field. When the 397 Packet Length is 0, the distance to the next header is 4 octets. 398 This is the idle fill header. When the Packet Length is 1 to 3, the 399 distance to the next header is 12 octets. These headers are used for 400 special SDL messages used only with optional scrambling and manage- 401 ment modes. See section 5 for details of the messages. 403 General SDL, like PPP, allows the use of no CRC, ITU-T CRC-16, or 404 ITU-T CRC-32 for the packet data. However, because the Packet Length 405 field does not include the CRC length, synchronization cannot be 406 maintained if the CRC type is changed per RFC 1570 [9], because 407 frame-to-frame distance is, as described above, calculated including 408 the CRC length. Thus, this PPP over SDL specification fixes the CRC 409 type to CRC-32 (four octets), and all SDL implementations MUST reject 410 any LCP FCS Alternatives Option [9] requested by the peer when in SDL 411 mode. 413 PPP over SDL implementations MAY allow a configuration option to set 414 different CRC types for use by prior arrangement. Any such configur- 415 able option MUST default to CRC-32, and MUST NOT include LCP negotia- 416 tion of FCS Alternatives. 418 Setting the SDL Datagram Offset value to 4 accounts for the 4 octet 419 SDL header overhead. With the SDL Datagram Offset set to 4, the 420 value placed in the Packet Length field is exactly the length in 421 octets of the PPP frame itself, including the address and control 422 fields but not including the CRC field (the RFC 1662 PPP FCS field is 423 not used with SDL). Note again that the Datagram Offset is just an 424 arithmetic value; it does not occupy bits in the message itself. 426 Because Packet Lengths below 4 are reserved, the Packet Length MUST 427 be 4 or greater for any legal PPP packet. PPP packets with fewer 428 octets, which are not possible without address/control or protocol 429 field compression, MUST be padded to length 4 for SDL. 431 Inter-packet time fill is accomplished by sending the four octet 432 length header with the Packet Length set to zero. No provision is 433 made for intra-packet time fill. 435 By default, an independent, self-synchronous x^43+1 scrambler is used 436 on the data portion of the message including the 32 bit CRC. This is 437 done in exactly the same manner as with the ATM x^43+1 scrambler on 438 an ATM channel. The scrambler is not clocked when SDL header bits 439 are transmitted. Thus, the data scrambling MAY be implemented in an 440 entirely independent manner from the SDL framing, and the data stream 441 may be prescrambled before insertion of SDL framing marks. 443 Optionally, by prior arrangement, SDL links MAY use a set-reset 444 scrambler as described in section 6. If this option is provided, it 445 MUST be configurable by the administrator, and the option MUST 446 default to the self-synchronous scrambler. 448 3.6. Framing Example 450 To help clarify this structure, the following example may be helpful. 451 First we have an LCP Configure-Request message that we wish to 452 transmit over SDL: 454 FF 03 C0 21 01 01 00 04 456 Next, we create an SDL header for the length of this packet (8 457 octets), a header CRC, and an SDL CRC. 459 00 08 81 08 FF 03 C0 21 01 01 00 04 D1 F5 21 5E 461 Finally, we DC-balance the header with the barker-like sequence: 463 B6 A3 B0 E8 FF 03 C0 21 01 01 00 04 D1 F5 21 5E 465 Note that the final length of the message is 8 (original message 466 length) plus 4 (fixed datagram offset value) plus 4 (fixed CRC 467 length), or 16 octets. 469 3.7. Synchronization Procedure 471 The link synchronization procedure is similar to the I.432 section 472 4.5.1.1 ATM HEC delineation procedure [10], except that the SDL mes- 473 sages are variable length. The machine starts in HUNT state until a 474 four octet sequence in the data stream with a valid CRC-16 is found. 475 (Note that the CRC-16 single-bit error correction technique described 476 in section 3.10 is not employed until the machine is in in SYNCH 477 state. The header must have no bit errors in order to leave HUNT 478 state.) Such a valid sequence is a candidate SDL header. On finding 479 the valid sequence, the machine enters PRESYNCH state. Any one 480 invalid SDL header in PRESYNCH state returns the link to HUNT state. 482 If a second valid SDL header is seen after entering PRESYNCH state, 483 then the link enters SYNCH state and PPP transmission is enabled. If 484 an invalid SDL header is detected, then the link is returned to HUNT 485 state without enabling PPP transmission. 487 Once the link enters SYNCH state, the SDL header single bit error 488 correction logic is enabled (see section 3.10). Any unrecoverable 489 header CRC error returns the link to HUNT state, disables PPP 490 transmission, and disables the error correction logic. 492 3.8. Scrambler Operation 494 The transmit and receive scramblers are shift registers with 43 495 stages that MAY be initialized to all-ones when the link is initial- 496 ized. Synchronization is maintained by the data itself. 498 Transmit Receive 500 DATA-STREAM (FROM PPP) IN (FROM SDL FRAMER) 501 | | 502 v | 503 XOR<-------------------------+ +->D0-+->D1-> ... ->D41->D42-+ 504 | | | | 505 +->D0-+->D1-> ... ->D41->D42-+ XOR<-------------------------+ 506 | | 507 v v 508 OUT (TO SDL FRAMER) DATA-STREAM (TO PPP) 510 Each XOR is an exclusive-or gate; also known as a modulo-2 adder. 511 Each Dn block is a D-type flip-flop clocked on the appropriate data 512 clock. 514 The scrambler is clocked once after transmission or reception of each 515 bit of payload and before the next bit is applied as input. Bits 516 within an octet are, per SONET/SDH practice, transmitted and received 517 MSB-first. 519 3.9. CRC Generation 521 The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-T 522 polynomials [11]. These are: 524 x^16+x^12+x^5+1 526 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 528 The SDL Header CRC and the CRC-16 used for each of the three special 529 messages (scrambler state, message A, and message B; see section 5) 530 are all generated using an initial remainder value of 0000 hex. 532 The optional CRC-16 on the payload data (this mode is not used with 533 PPP over SDL except by prior arrangement) uses the initial remainder 534 value of FFFF hex for calculation and the bits are complemented 535 before transmission. The final CRC remainder, however, is transmit- 536 ted in network byte order, unlike the regular PPP FCS. If the CRC-16 537 algorithm is run over all of the octets including the appended CRC 538 itself, then the remainder value on intact packets will always be 539 E2F0 hex. Alternatively, an implementation may stop CRC calculation 540 before processing the appended CRC itself, and do a direct com- 541 parison. 543 The CRC-32 on the payload data (used for PPP over SDL) uses the ini- 544 tial remainder value of FFFFFFFF hex for calculation and the bits are 545 complemented before transmission. The CRC, however, is transmitted 546 in network byte order, most significant bit first, unlike the 547 optional PPP 32 bit FCS, which is transmitted in reverse order. The 548 remainder value on intact packets when the appended CRC value is 549 included in the calculation is 38FB2284. 551 C code to generate these CRCs is found in section 8.1. 553 3.10. Error Correction 555 The error correction technique is based on the use of a Galois number 556 field, as with the ATM HEC correction. In a Galois number field, 557 f(a+b) = f(a) + f(b). Since the CRC-16 used for SDL forms such a 558 field, we can state that CRC(message+error) = CRC(message) + 559 CRC(error). Since the CRC-16 remainder of a properly formed message 560 is always zero, this means that, for the N distinct "error" strings 561 corresponding to a single bit error, there are N distinct CRC(error) 562 values, where N is the number of bits in the message. 564 A table look-up is thus applied to the CRC-16 residue after calcula- 565 tion over the four octet SDL header to correct bit errors in the 566 header and to detect multiple bit errors. For the optional set-reset 567 scrambler, a table look-up is similarly applied to the CRC-16 residue 568 after calculation over the eight octet scrambler state message to 569 correct bit errors and to detect multiple bit errors. (This second 570 correction is also used for the special SDL A and B messages, which 571 are not used for PPP over SDL.) 573 Note: No error correction is performed for the payload. 575 Note: This error correction technique is used only when the link has 576 entered SYNCH state. While in HUNT or PRESYNCH state, error correc- 577 tion should not be performed, and only messages with syndrome 0000 578 are accepted. If the calculated syndrome does not appear in this 579 table, then an unrecoverable error has occurred. Any such error in 580 the SDL header will return the link to HUNT state. 582 Since the CRC calculation is started with zero, the two tables can be 583 merged. The four octet table is merely the last 32 entries of the 584 eight octet table. 586 Eight octet (64 bit) single bit error syndrome table (in hexade- 587 cimal): 589 FD81 F6D0 7B68 3DB4 1EDA 0F6D 8FA6 47D3 590 ABF9 DDEC 6EF6 377B 93AD C1C6 60E3 B861 591 D420 6A10 3508 1A84 0D42 06A1 8B40 45A0 592 22D0 1168 08B4 045A 022D 8906 4483 AA51 593 DD38 6E9C 374E 1BA7 85C3 CAF1 ED68 76B4 594 3B5A 1DAD 86C6 4363 A9A1 DCC0 6E60 3730 595 1B98 0DCC 06E6 0373 89A9 CCC4 6662 3331 596 9188 48C4 2462 1231 8108 4084 2042 1021 598 Thus, if the syndrome 6EF6 is seen on an eight octet message, then 599 the third bit (hex 20) of the second octet is in error. Similarly, 600 if 48C4 is seen on an eight octet message, then the second bit (hex 601 40) in the eighth octet is in error. For a four octet message, the 602 same two syndromes would indicate a multiple bit error for 6EF6, and 603 a single bit error in the second bit of the fourth octet for 48C4. 605 Note that eight octet messages are used only for the optional set- 606 reset scrambling mode, described in section 6. 608 Corresponding C code to generate this table is found in section 8.2. 610 4. Performance Analysis 612 There are five general statistics that are important for framing 613 algorithms. These are: 615 MTTF Mean time to frame 616 MTTS Mean time to synchronization 617 PFF Probability of false frame 618 PFS Probability of false synchronization 619 PLF Probability of loss of frame 621 The following sections summarize each of these statistics for SDL. 622 Details and mathematic development can be found in the Lucent SDL 623 documentation [6]. 625 4.1. Mean Time To Frame (MTTF) 627 This metric measures the amount of time required to establish correct 628 framing in the input data. This may be measured in any convenient 629 units, such as seconds or bytes. For SDL, the relevant measurement 630 is in packets, since fragments of packets are not useful. 632 In order to calculate MTTF, we must first determine how often the 633 frame detection state machine is "unavailable" because it failed to 634 detect the next incoming SDL frame in the data stream. 636 Since the probability of a false header detection using CRC-16 in 637 random data is 2^-16 and this rate is large compared to the allowable 638 packet size, it is worthwhile to run multiple parallel frame- 639 detection state machines. Each machine starts with a different can- 640 didate framing point in order to reduce the probability of falsely 641 detecting user data as a valid frame header. 643 The results for this calculation, given maximal 64KB packets and 644 slightly larger than Internet average 354 byte packets, are: 646 Number of Unavailability Unavailability 647 Framers 64KB packets 354 byte pkts 648 1 3.679E-1 5.373E-3 649 2 3.083E-2 1.710E-6 650 3 2.965E-3 9.712E-10 651 4 2.532E-4 4.653E-13 653 Using these values, MTTF can be calculated as a function of the Bit 654 Error Rate (BER). These plots show a characteristically flat region 655 for all BERs up to a knee, beyond which the begins to rise sharply. 656 In all cases, this knee point has been found to occur at a BER of 657 approximately 1E-4, which is several orders of magnitude above that 658 observed on existing SONET/SDH links. The flat rate values are sum- 659 marized as: 661 Number of Flat region Flat region 662 Framers 64KB packets 354 bytes 663 1 3.58 1.52 664 2 1.595 1.5 665 3 1.52 1.5 666 4 1.5 1.5 668 Thus, for common packet sizes in an implementation with two parallel 669 framers using links with a BER of 1E-4 or better, the MTTF is approx- 670 imately 1.5 packets. This is also the optimal time, since it 671 represents initiating framing at an average point half-way into one 672 packet, and achieving good framing after seeing exactly one correctly 673 framed packet. 675 4.2. Mean Time To Synchronization (MTTS) 677 The MTTS for SDL with a self-synchronous scrambler is the same as the 678 MTTF, or 1.5 packets. 680 The MTTS for SDL using the optional set-reset scrambler is one half 681 of the scrambling state transmission interval (in packets) plus the 682 MTTF. For insertion at the default rate of one per eight packets, 683 the MTTS is 5.5 packets. 685 (The probability of receiving a bad scrambling state transmission 686 should also be included in this calculation. The probability of ran- 687 dom corruption of this short message is shown in the SDL document [6] 688 to be small enough that it can be neglected for this calculation.) 690 4.3. Probability of False Frame (PFF) 692 The PFF is 2.328E-10 (2^-32), since false framing requires two con- 693 secutive headers with falsely correct CRC-16. 695 4.4. Probability of False Synchronization (PFS) 697 The PFS for SDL with the self-synchronous scrambler is the same as 698 the PFF, or 2.328E-10 (2^-32). 700 The PFS for SDL with the set-reset scrambler is 5.421E-20 (2^-64), 701 and is calculated as the PFF above multiplied by the probability of a 702 falsely detected scrambler state message, which itself contains two 703 independent CRC-16 calculations. 705 4.5. Probability of Loss of Frame (PLF) 707 The PLF is a function of the BER, and for SDL is approximately the 708 square of the BER multiplied by 500, which is the probability of two 709 or more bit errors occurring within the 32 bit SDL header. Thus, at 710 a BER of 1E-5, the PLF is 5E-8. 712 5. The Special Messages 714 When the SDL Packet Length field has any value between 0000 and 0003, 715 the message following the header has a special, pre-defined length. 716 The 0 value is a time-fill on an idle link, and no other data fol- 717 lows. The next octet on the link is the first octet of the next SDL 718 header. 720 The values 1 through 3 are defined in the following subsections. 721 These special messages each consist of a six octet data portion fol- 722 lowed by another CRC-16 over that data portion, as with the SDL 723 header, and this CRC is used for single bit error correction. 725 5.1. Scrambler State 727 The special value of 1 for Packet Length is reserved to transfer the 728 scrambler state from the transmitter to the receiver for the optional 729 set-reset scrambler. In this case, the SDL header is followed by six 730 octets (48 bits) of scrambler state. Neither the scrambler state nor 731 the CRC are scrambled. 733 5.2. A/B Message 735 The special values of 2 and 3 for Packet Length are reserved for "A" 736 and "B" messages, which are also six octets in length followed by two 737 octets of CRC-16. Each of these eight octets are scrambled. No use 738 for these messages with PPP SDL is defined. These messages are 739 reserved for use by link maintenance protocols, in a manner analogous 740 to ATM's OAM cells. 742 6. The Set-Reset Scrambler Option 744 PPP over SDL uses a self-synchronous scrambler. SDL implementations 745 MAY also employ a set-reset scrambler to avoid some of the possible 746 inherent problems with self-synchronous scramblers. 748 6.1. The Killer Packet Problem 750 Scrambling in general solves two problems. First, SONET and SDH 751 interfaces require a minimum density of bit transitions in order to 752 maintain hardware clock recovery. Since data streams frequently con- 753 tain long runs of all zeros or all ones, scrambling the bits using a 754 pseudo-random number sequence breaks up these patters. Second, all 755 link-layer synchronization mechanisms rely on detecting long-range 756 patterns in the received data to detect framing. 758 Self-synchronous scramblers are an easy way to partially avoid these 759 problems. One problem that is inherent with self-synchronous, how- 760 ever, is that long user packets from malicious sites can make use of 761 the known properties of these scramblers to inject either long 762 strings of zeros or other synchronization-destroying patterns into 763 the link. For public networks, where the data presented to the net- 764 work is usually multiplexed (interleaved) with multiple unrelated 765 streams, the clocking problem does not pose a significant threat to 766 the public network. It does, however, pose a threat to the PPP- 767 speaking device, and it poses a threat to long lines that are unchan- 768 nelized. 770 Such carefully constructed packets are called "killer packets." 772 6.2. SDL Set-Reset Scrambler 774 An alternative to the self-synchronous scrambler is the externally 775 synchronized or "set-reset" scrambler. This is a free-running scram- 776 bler that is not affected by the patterns in the user data, and 777 therefore minimizes the possibility that a malicious user could 778 present data to the network that mimics an undesirable data pattern. 780 The option set-reset scrambler defined for SDL is an 781 x^48+x^28+x^27+x+1 independent scrambler initialized to all ones when 782 the link enters PRESYNCH state and reinitialized if the value ever 783 becomes all zero bits. As with the self-synchronous scrambler, all 784 octets in the PPP packet data following the SDL header through the 785 final packet CRC are scrambled. 787 This mode MAY be detected automatically. If a scrambler state mes- 788 sage is received (as described in the following section), an SDL 789 implementation that includes the set-reset scrambler option may 790 switch from self-synchronous into set-reset mode automatically. An 791 SDL implementation that does not include the set-reset scrambler MUST 792 NOT send scrambler state messages. 794 6.3. SDL Scrambler Synchronization 796 As described in the previous section, the special value of 1 for 797 Packet Length is reserved to transfer the scrambler state from the 798 transmitter to the receiver. In this case, the SDL header is fol- 799 lowed by six octets (48 bits) of scrambler state plus two octets of 800 CRC-16 over the scrambler state. None of these eight octets are 801 scrambled. 803 SDL synchronization consists of two components, link and scrambler 804 synchronization. Both must be completed before PPP data flows on the 805 link. 807 If a valid SDL header is seen in PRESYNCH state, then the link enters 808 SYNCH state, and the scrambler synchronization sequence is started. 809 If an invalid SDL header is detected, then the link is returned to 810 HUNT state, and PPP transmission is suspended. 812 When scrambler synchronization is started, a scrambler state message 813 is sent (Packet Length set to 1 and six octets of scrambler state in 814 network byte order follow the SDL header). When a scrambler syn- 815 chronization message is received from the peer, PPP transmission is 816 enabled. 818 Scrambler state messages are periodically transmitted to keep the 819 peers in synchronization. A period of once per eight transmitted 820 packets is suggested, and it SHOULD be configurable. Excessive 821 packet CRC errors detected indicates an extended loss of synchroniza- 822 tion and should trigger link resynchronization. 824 On reception of a scrambler state message, an SDL implementation MUST 825 compare the received 48 bits of state with the receiver's scrambler 826 state. If any of these bits differ, then a synchronization slip 827 error is declared. After such an error, the next valid scrambler 828 state message received MUST be loaded into the receiver's scrambler, 829 and the error condition is then cleared. 831 6.4. SDL Scrambler Operation 833 The transmit and receive scramblers are shift registers with 48 834 stages that are initialized to all-ones when the link is initialized. 835 Each is refilled with all one bits if the value in the shift register 836 ever becomes all zeros. This scrambler is not reset at the beginning 837 of each frame, as is the SONET/SDH X^7+X^6+1 scrambler, nor is it 838 modified by the transmitted data, as is the ATM self-synchronous 839 scrambler. Instead it is kept in synchronization using special SDL 840 messages. 842 +----XOR<--------------XOR<---XOR<----------------+ 843 | ^ ^ ^ | 844 | | | | | 845 +->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+ 846 | 847 v 848 OUT 850 Each XOR is an exclusive-or gate; also known as a modulo-2 adder. 851 Each Dn block is a D-type flip-flop clocked on the appropriate data 852 clock. 854 The scrambler is clocked once after transmission of each bit of SDL 855 data, whether or not the transmitted bit is scrambled. When scram- 856 bling is enabled for a given octet, the OUT bit is exclusive-ored 857 with the raw data bit to produce the transmitted bit. Bits within an 858 octet are transmitted MSB-first. 860 Reception of scrambled data is identical to transmission. Each 861 received bit is exclusive-ored with the output of the separate 862 receive data scrambler. 864 To generate a scrambler state message, the contents of D47 through D0 865 are snapshot at the point where the first scrambler state bit is 866 sent. D47 is transmitted as the first bit of the output. The first 867 octet transmitted contains D47 through D40, the second octet D39 868 through D32, and the sixth octet D7 through D0. 870 The receiver of a scrambler state message MUST first run the CRC-16 871 check and correct algorithm over this message. If the CRC-16 message 872 check detects multiple bit errors, then the message is dropped and is 873 not processed further. 875 Otherwise, it then should compare the contents of the entire receive 876 scrambler state D47:D0 with the corrected message. (By pipelining 877 the receiver with multiple clock stages between SDL Header error- 878 correction block and the descrambling block, the receive descrambler 879 will be on the correct clock boundary when the message arrives at the 880 descrambler. This means that the decoded scrambler state can be 881 treated as immediately available at the beginning of the D47 clock 882 cycle into the receive scrambler.) 884 If any of the received scrambler state bits is different from the 885 corresponding shift register bit, then a soft error flag is set. If 886 the flag was already set when this occurs, then a synchronization 887 slip error is declared. This error SHOULD be counted and reported 888 through implementation-defined network management procedures. When 889 the receiver has this soft error flag set, any scrambler state mes- 890 sage that passes the CRC-16 message check without multiple bit errors 891 is clocked directly into the receiver's state register after the com- 892 parison is done, and the soft error flag is then cleared. Otherwise, 893 while uncorrectable scrambler state messages are received, the soft 894 error flag state is maintained. 896 (The intent of this mechanism is to reduce the likelihood that a 897 falsely corrected scrambler state message with multiple bit errors 898 can corrupt the running scrambler state.) 900 7. Configuration Details 902 7.1. Default LCP Configuration 904 The LCP synchronous configuration defaults apply to SONET/SDH links. 906 The following Configuration Options are recommended: 908 Magic Number 909 No Address and Control Field Compression 910 No Protocol Field Compression 911 No FCS alternatives (32-bit FCS default) 913 This configuration means that PPP over SDL generally presents a 32- 914 bit aligned datagram to the network layer. With the address, con- 915 trol, and protocol field intact, the PPP overhead on each packet is 916 four octets. If the SDL framer presents the SDL packet header to the 917 PPP input handling in order to communicate the packet length (the 918 Lucent implementation does not do this, but other hardware implemen- 919 tations may), this header is also four octets, and alignment is 920 preserved. 922 7.2. Modification of the Standard Frame Format 924 Since SDL does take the place of HDLC as a transport for PPP, it is 925 at least tempting to remove the HDLC-derived overhead. This is not 926 done for PPP over SDL in order to preserve the message alignment and 927 to allow for the future possibility interworking with other services 928 (e.g., Frame Relay). 930 By prior external arrangement or via LCP negotiation, any two SDL 931 implementations MAY agree to omit the address and control fields or 932 implement protocol field compression on a link. Such use is not 933 described by this document and MUST NOT be the default on any SDL 934 implementation. 936 8. Implementation Details 938 8.1. CRC Generation 940 The following unoptimized code generates proper CRC-16 and CRC-32 941 values for SDL messages. Note that the polynomial bits are numbered 942 in big-endian order for SDL CRCs; bit 0 is the MSB. 944 typedef unsigned char u8; 945 typedef unsigned short u16; 946 typedef unsigned long u32; 948 #define POLY16 0x1021 949 #define POLY32 0x04C11DB7 951 u16 952 crc16(u16 crcval, u8 cval) 953 { 954 int i; 956 crcval ^= cval << 8; 957 for (i = 8; i--; ) 958 crcval = crcval & 0x8000 ? (crcval << 1) ^ POLY16 : 959 crcval << 1; 960 return crcval; 961 } 963 u32 964 crc32(u32 crcval, u8 cval) 965 { 966 int i; 968 crcval ^= cval << 24; 969 for (i = 8; i--; ) 970 crcval = crcval & 0x80000000 ? (crcval << 1) ^ POLY32 : 971 crcval << 1; 972 return crcval; 973 } 974 u16 975 crc16_special(u8 *buffer, int len) 976 { 977 u16 crc; 979 crc = 0; 980 while (--len >= 0) 981 crc = crc16(crc,*buffer++); 982 return crc; 983 } 985 u16 986 crc16_payload(u8 *buffer, int len) 987 { 988 u16 crc; 990 crc = 0xFFFF; 991 while (--len >= 0) 992 crc = crc16(crc,*buffer++); 993 return crc ^ 0xFFFF; 994 } 996 u32 997 crc32_payload(u8 *buffer, int len) 998 { 999 u32 crc; 1001 crc = 0xFFFFFFFFul; 1002 while (--len >= 0) 1003 crc = crc32(crc,*buffer++); 1004 return crc ^ 0xFFFFFFFFul; 1005 } 1007 void 1008 make_sdl_header(int packet_length, u8 *buffer) 1009 { 1010 u16 crc; 1012 buffer[0] = (packet_length >> 8) & 0xFF; 1013 buffer[1] = packet_length & 0xFF; 1014 crc = crc16_special(buffer,2); 1015 buffer[0] ^= 0xB6; 1016 buffer[1] ^= 0xAB; 1017 buffer[2] = ((crc >> 8) & 0xFF) ^ 0x31; 1018 buffer[3] = (crc & 0xFF) ^ 0xE0; 1019 } 1021 8.2. Error Correction Tables 1023 To generate the error correction table, the following implementation 1024 may be used. It creates a table called sdl_error_position, which is 1025 indexed on CRC residue value. The tables can be used to determine if 1026 no error exists (table entry is equal to FE hex), one correctable 1027 error exists (table entry is zero-based index to errored bit with MSB 1028 of first octet being 0), or more than one error exists, and error is 1029 uncorrectable (table entry is FF hex). To use for eight octet mes- 1030 sages, the bit index from this table is used directly. To use for 1031 four octet messages, the index is treated as an unrecoverable error 1032 if it is below 32, and as bit index plus 32 if it is above 32. 1034 The program also prints out the error syndrome table shown in section 1035 3.10. This may be used as part of a "switch" statement in a hardware 1036 implementation. 1038 u8 sdl_error_position[65536]; 1040 /* Calculate new CRC from old^(byte<<8) */ 1041 u16 1042 crc16_t8(u16 crcval) 1043 { 1044 u16 f1,f2,f3; 1046 f1 = (crcval>>8) | (crcval<<8); 1047 f2 = (crcval>>12) | (crcval&0xF000) | ((crcval>>7)&0x01E0); 1048 f3 = ((crcval>>3) & 0x1FE0) ^ ((crcval<<4) & 0xF000); 1049 return f1^f2^f3; 1050 } 1052 void 1053 generate_error_table(u8 *bptab, int nbytes) 1054 { 1055 u16 crc; 1056 int i, j, k; 1058 /* Marker for no error */ 1059 bptab[0] = 0xFE; 1061 /* Marker for >1 error */ 1062 for (i = 1; i < 65536; i++ ) 1063 bptab[i] = 0xFF; 1065 /* Mark all single bit error cases. */ 1066 printf("Error syndrome table:\n"); 1067 for (i = 0; i < nbytes; i++) { 1068 putchar(' '); 1069 for (j = 0; j < 8; j++) { 1070 crc = 0; 1071 for (k = 0; k < i; k++) 1072 crc = crc16_t8(crc); 1073 crc = crc16_t8(crc ^ (0x8000>>j)); 1074 for (k++; k < nbytes; k++) 1075 crc = crc16_t8(crc); 1076 bptab[crc] = (i * 8) + j; 1077 printf(" %04X",crc); 1078 } 1079 putchar('\n'); 1080 } 1081 } 1083 int 1084 main(int argc, char **argv) 1085 { 1086 u8 buffer[8] = { 1087 0x01,0x55,0x02,0xaa, 1088 0x99,0x72,0x18,0x56 1089 }; 1090 u16 crc; 1091 int i; 1093 generate_error_table(sdl_error_position,8); 1095 /* Run sample message through check routine. */ 1096 crc = 0; 1097 for (i = 0; i < 8; i++) 1098 crc = crc16_t8(crc ^ (buffer[i]<<8)); 1100 /* Output is 0000 64 -- no error encountered. */ 1101 printf("\nError test: CRC %04X, bit position %d\n", 1102 crc,sdl_message_error_position[crc]); 1103 } 1105 9. Security Considerations 1107 The reliability of public SONET/SDH networks depends on well-behaved 1108 traffic that does not disrupt the synchronous data recovery mechan- 1109 isms. This document describes framing and scrambling options that 1110 are used to ensure the distribution of transmitted data such that 1111 SONET/SDH design assumptions are not likely to be violated. 1113 10. References 1115 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)," 1116 RFC 1661, Daydreamer, July 1994. 1118 [2] Simpson, W., Editor, "PPP in HDLC-like Framing," RFC 1662, 1119 Daydreamer, July 1994. 1121 [3] Malis, A. and W. Simpson, "PPP over SONET/SDH," RFC 2615, 1122 June 1999. 1124 [4] "American National Standard for Telecommunications - 1125 Synchronous Optical Network (SONET) Payload Mappings," ANSI 1126 T1.105.02-1995. 1128 [5] ITU-T Recommendation G.707, "Network Node Interface for the 1129 Synchronous Digital Hierarchy (SDH)," March 1996. 1131 [6] Doshi, B., Dravida, S., Hernandez-Valencia, E., Matragi, W., 1132 Qureshi, M., Anderson, J., Manchester, J.,"A Simple Data 1133 Link Protocol for High Speed Packet Networks", Bell Labs 1134 Technical Journal, pp. 85-104, Vol.4 No.1, January-March 1135 1999. 1137 [7] Demers, A., S. Keshav, and S. Shenker, "Analysis and 1138 simulation of a fair queueing algorithm," ACM SIGCOMM volume 1139 19 number 4, pp. 1-12, September 1989. 1141 [8] Floyd, S. and V. Jacobson, "Random Early Detection Gateways 1142 for Congestion Avoidance," IEEE/ACM Transactions on 1143 Networking, August 1993. 1145 [9] Simpson, W., Editor, "PPP LCP Extensions," RFC 1570, 1146 Daydreamer, January 1994. 1148 [10] ITU-T Recommendation I.432.1, "B-ISDN User-Network Interface 1149 - Physical Layer Specification: General Characteristics," 1150 February 1999. 1152 [11] ITU-T Recommendation V.41, "Code-independent error-control 1153 system," November 1989. 1155 [12] ITU-T Recommendation G.783, "Characteristics of synchronous 1156 digital hierarchy (SDH) equipment functional blocks," April 1157 1997. 1159 11. Acknowledgments 1161 PPP over SONET was first proposed by Craig Partridge (BBN) and is 1162 documented by Andrew Malis and William Simpson as RFC 2615. 1164 Much of the material in this document was supplied by Lucent. 1166 Other length-prefixed forms of framing for PPP have gone before SDL, 1167 such as William Simpson's "PPP in Ether-like Framing" expired draft. 1169 12. Working Group and Chair Address 1171 The working group can be contacted via the mailing list (ietf- 1172 ppp@merit.edu; send mail to ietf-ppp-request@merit.edu to subscribe), 1173 or via the current chair: 1175 Karl Fox 1176 Extant, Inc. 1177 3496 Snouffer Road, Suite 100 1178 Columbus, Ohio 43235 1180 Email: karl@extant.net 1182 13. Intellectual Property Notices 1184 The IETF takes no position regarding the validity or scope of any 1185 intellectual property or other rights that might be claimed to per- 1186 tain to the implementation or use of the technology described in this 1187 document or the extent to which any license under such rights might 1188 or might not be available; neither does it represent that it has made 1189 any effort to identify any such rights. Information on the IETF's 1190 procedures with respect to rights in standards-track and standards- 1191 related documentation can be found in BCP-11. Copies of claims of 1192 rights made available for publication and any assurances of licenses 1193 to be made available, or the result of an attempt made to obtain a 1194 general license or permission for the use of such proprietary rights 1195 by implementors or users of this specification can be obtained from 1196 the IETF Secretariat. 1198 The IETF invites any interested party to bring to its attention any 1199 copyrights, patents or patent applications, or other proprietary 1200 rights which may cover technology that may be required to practice 1201 this standard. Please address the information to the IETF Executive 1202 Director. 1204 14. Copyright Notice 1206 Copyright (C) The Internet Society 1999. All Rights Reserved. 1208 This document and translations of it may be copied and furnished to 1209 others, and derivative works that comment on or otherwise explain it 1210 or assist in its implementation may be prepared, copied, published 1211 and distributed, in whole or in part, without restriction of any 1212 kind, provided that the above copyright notice and this paragraph are 1213 included on all such copies and derivative works. However, this 1214 document itself may not be modified in any way, such as by removing 1215 the copyright notice or references to the Internet Society or other 1216 Internet organizations, except as needed for the purpose of develop- 1217 ing Internet standards in which case the procedures for copyrights 1218 defined in the Internet Standards process must be followed, or as 1219 required to translate it into languages other than English. 1221 The limited permissions granted above are perpetual and will not be 1222 revoked by the Internet Society or its successors or assigns. 1224 This document and the information contained herein is provided on an 1225 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1226 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1227 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1228 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 1229 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1231 15. Authors' Addresses 1233 James Carlson 1234 IronBridge Networks 1235 55 Hayden Avenue 1236 Lexington MA 02421-7996 1237 Phone: +1 781 372 8132 1238 Fax: +1 781 372 8090 1239 Email: carlson@ibnets.com 1241 Paul Langner 1242 Lucent Technologies Microelectronics Group 1243 555 Union Boulevard 1244 Allentown PA 18103-1286 1245 Email: plangner@lucent.com 1247 Enrique J. Hernandez-Valencia 1248 Lucent Technologies 1249 101 Crawford Corners Rd. 1250 Holmdel NJ 07733-3030 1251 Email: enrique@lucent.com 1253 James Manchester 1254 Lucent Technologies 1255 101 Crawford Corners Rd. 1256 Holmdel NJ 07733-3030 1257 Email: sterling@hotair.hobl.lucent.com