1 2 3 4 5 6 7 8Network Working Group W. Simpson, Editor 9Request for Comments: 1662 Daydreamer 10STD: 51 July 1994 11Obsoletes: 1549 12Category: Standards Track 13 14 15 PPP in HDLC-like Framing 16 17 18Status of this Memo 19 20 This document specifies an Internet standards track protocol for the 21 Internet community, and requests discussion and suggestions for 22 improvements. Please refer to the current edition of the "Internet 23 Official Protocol Standards" (STD 1) for the standardization state 24 and status of this protocol. Distribution of this memo is unlimited. 25 26 27Abstract 28 29 The Point-to-Point Protocol (PPP) [1] provides a standard method for 30 transporting multi-protocol datagrams over point-to-point links. 31 32 This document describes the use of HDLC-like framing for PPP 33 encapsulated packets. 34 35 36Table of Contents 37 38 39 1. Introduction .......................................... 1 40 1.1 Specification of Requirements ................... 2 41 1.2 Terminology ..................................... 2 42 43 2. Physical Layer Requirements ........................... 3 44 45 3. The Data Link Layer ................................... 4 46 3.1 Frame Format .................................... 5 47 3.2 Modification of the Basic Frame ................. 7 48 49 4. Octet-stuffed framing ................................. 8 50 4.1 Flag Sequence ................................... 8 51 4.2 Transparency .................................... 8 52 4.3 Invalid Frames .................................. 9 53 4.4 Time Fill ....................................... 9 54 4.4.1 Octet-synchronous ............................... 9 55 4.4.2 Asynchronous .................................... 9 56 4.5 Transmission Considerations ..................... 10 57 4.5.1 Octet-synchronous ............................... 10 58 4.5.2 Asynchronous .................................... 10 59 60 61Simpson [Page i] 62RFC 1662 HDLC-like Framing July 1994 63 64 65 5. Bit-stuffed framing ................................... 11 66 5.1 Flag Sequence ................................... 11 67 5.2 Transparency .................................... 11 68 5.3 Invalid Frames .................................. 11 69 5.4 Time Fill ....................................... 11 70 5.5 Transmission Considerations ..................... 12 71 72 6. Asynchronous to Synchronous Conversion ................ 13 73 74 7. Additional LCP Configuration Options .................. 14 75 7.1 Async-Control-Character-Map (ACCM) .............. 14 76 77 APPENDICES ................................................... 17 78 A. Recommended LCP Options ............................... 17 79 B. Automatic Recognition of PPP Frames ................... 17 80 C. Fast Frame Check Sequence (FCS) Implementation ........ 18 81 C.1 FCS table generator ............................. 18 82 C.2 16-bit FCS Computation Method ................... 19 83 C.3 32-bit FCS Computation Method ................... 21 84 85 SECURITY CONSIDERATIONS ...................................... 24 86 REFERENCES ................................................... 24 87 ACKNOWLEDGEMENTS ............................................. 25 88 CHAIR'S ADDRESS .............................................. 25 89 EDITOR'S ADDRESS ............................................. 25 90 91 92 93 941. Introduction 95 96 This specification provides for framing over both bit-oriented and 97 octet-oriented synchronous links, and asynchronous links with 8 bits 98 of data and no parity. These links MUST be full-duplex, but MAY be 99 either dedicated or circuit-switched. 100 101 An escape mechanism is specified to allow control data such as 102 XON/XOFF to be transmitted transparently over the link, and to remove 103 spurious control data which may be injected into the link by 104 intervening hardware and software. 105 106 Some protocols expect error free transmission, and either provide 107 error detection only on a conditional basis, or do not provide it at 108 all. PPP uses the HDLC Frame Check Sequence for error detection. 109 This is commonly available in hardware implementations, and a 110 software implementation is provided. 111 112 113 114 115 116 117Simpson [Page 1] 118RFC 1662 HDLC-like Framing July 1994 119 120 1211.1. Specification of Requirements 122 123 In this document, several words are used to signify the requirements 124 of the specification. These words are often capitalized. 125 126 MUST This word, or the adjective "required", means that the 127 definition is an absolute requirement of the specification. 128 129 MUST NOT This phrase means that the definition is an absolute 130 prohibition of the specification. 131 132 SHOULD This word, or the adjective "recommended", means that there 133 may exist valid reasons in particular circumstances to 134 ignore this item, but the full implications must be 135 understood and carefully weighed before choosing a 136 different course. 137 138 MAY This word, or the adjective "optional", means that this 139 item is one of an allowed set of alternatives. An 140 implementation which does not include this option MUST be 141 prepared to interoperate with another implementation which 142 does include the option. 143 144 1451.2. Terminology 146 147 This document frequently uses the following terms: 148 149 datagram The unit of transmission in the network layer (such as IP). 150 A datagram may be encapsulated in one or more packets 151 passed to the data link layer. 152 153 frame The unit of transmission at the data link layer. A frame 154 may include a header and/or a trailer, along with some 155 number of units of data. 156 157 packet The basic unit of encapsulation, which is passed across the 158 interface between the network layer and the data link 159 layer. A packet is usually mapped to a frame; the 160 exceptions are when data link layer fragmentation is being 161 performed, or when multiple packets are incorporated into a 162 single frame. 163 164 peer The other end of the point-to-point link. 165 166 silently discard 167 The implementation discards the packet without further 168 processing. The implementation SHOULD provide the 169 capability of logging the error, including the contents of 170 the silently discarded packet, and SHOULD record the event 171 in a statistics counter. 172 173 174Simpson [Page 2] 175RFC 1662 HDLC-like Framing July 1994 176 177 1782. Physical Layer Requirements 179 180 PPP is capable of operating across most DTE/DCE interfaces (such as, 181 EIA RS-232-E, EIA RS-422, and CCITT V.35). The only absolute 182 requirement imposed by PPP is the provision of a full-duplex circuit, 183 either dedicated or circuit-switched, which can operate in either an 184 asynchronous (start/stop), bit-synchronous, or octet-synchronous 185 mode, transparent to PPP Data Link Layer frames. 186 187 Interface Format 188 189 PPP presents an octet interface to the physical layer. There is 190 no provision for sub-octets to be supplied or accepted. 191 192 Transmission Rate 193 194 PPP does not impose any restrictions regarding transmission rate, 195 other than that of the particular DTE/DCE interface. 196 197 Control Signals 198 199 PPP does not require the use of control signals, such as Request 200 To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and 201 Data Terminal Ready (DTR). 202 203 When available, using such signals can allow greater functionality 204 and performance. In particular, such signals SHOULD be used to 205 signal the Up and Down events in the LCP Option Negotiation 206 Automaton [1]. When such signals are not available, the 207 implementation MUST signal the Up event to LCP upon 208 initialization, and SHOULD NOT signal the Down event. 209 210 Because signalling is not required, the physical layer MAY be 211 decoupled from the data link layer, hiding the transient details 212 of the physical transport. This has implications for mobility in 213 cellular radio networks, and other rapidly switching links. 214 215 When moving from cell to cell within the same zone, an 216 implementation MAY choose to treat the entire zone as a single 217 link, even though transmission is switched among several 218 frequencies. The link is considered to be with the central 219 control unit for the zone, rather than the individual cell 220 transceivers. However, the link SHOULD re-establish its 221 configuration whenever the link is switched to a different 222 administration. 223 224 Due to the bursty nature of data traffic, some implementations 225 have choosen to disconnect the physical layer during periods of 226 227 228 229Simpson [Page 3] 230RFC 1662 HDLC-like Framing July 1994 231 232 233 inactivity, and reconnect when traffic resumes, without informing 234 the data link layer. Robust implementations should avoid using 235 this trick over-zealously, since the price for decreased setup 236 latency is decreased security. Implementations SHOULD signal the 237 Down event whenever "significant time" has elapsed since the link 238 was disconnected. The value for "significant time" is a matter of 239 considerable debate, and is based on the tariffs, call setup 240 times, and security concerns of the installation. 241 242 243 2443. The Data Link Layer 245 246 PPP uses the principles described in ISO 3309-1979 HDLC frame 247 structure, most recently the fourth edition 3309:1991 [2], which 248 specifies modifications to allow HDLC use in asynchronous 249 environments. 250 251 The PPP control procedures use the Control field encodings described 252 in ISO 4335-1979 HDLC elements of procedures, most recently the 253 fourth edition 4335:1991 [4]. 254 255 This should not be construed to indicate that every feature of the 256 above recommendations are included in PPP. Each feature included 257 is explicitly described in the following sections. 258 259 To remain consistent with standard Internet practice, and avoid 260 confusion for people used to reading RFCs, all binary numbers in the 261 following descriptions are in Most Significant Bit to Least 262 Significant Bit order, reading from left to right, unless otherwise 263 indicated. Note that this is contrary to standard ISO and CCITT 264 practice which orders bits as transmitted (network bit order). Keep 265 this in mind when comparing this document with the international 266 standards documents. 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284Simpson [Page 4] 285RFC 1662 HDLC-like Framing July 1994 286 287 2883.1. Frame Format 289 290 A summary of the PPP HDLC-like frame structure is shown below. This 291 figure does not include bits inserted for synchronization (such as 292 start and stop bits for asynchronous links), nor any bits or octets 293 inserted for transparency. The fields are transmitted from left to 294 right. 295 296 +----------+----------+----------+ 297 | Flag | Address | Control | 298 | 01111110 | 11111111 | 00000011 | 299 +----------+----------+----------+ 300 +----------+-------------+---------+ 301 | Protocol | Information | Padding | 302 | 8/16 bits| * | * | 303 +----------+-------------+---------+ 304 +----------+----------+----------------- 305 | FCS | Flag | Inter-frame Fill 306 |16/32 bits| 01111110 | or next Address 307 +----------+----------+----------------- 308 309 The Protocol, Information and Padding fields are described in the 310 Point-to-Point Protocol Encapsulation [1]. 311 312 Flag Sequence 313 314 Each frame begins and ends with a Flag Sequence, which is the 315 binary sequence 01111110 (hexadecimal 0x7e). All implementations 316 continuously check for this flag, which is used for frame 317 synchronization. 318 319 Only one Flag Sequence is required between two frames. Two 320 consecutive Flag Sequences constitute an empty frame, which is 321 silently discarded, and not counted as a FCS error. 322 323 Address Field 324 325 The Address field is a single octet, which contains the binary 326 sequence 11111111 (hexadecimal 0xff), the All-Stations address. 327 Individual station addresses are not assigned. The All-Stations 328 address MUST always be recognized and received. 329 330 The use of other address lengths and values may be defined at a 331 later time, or by prior agreement. Frames with unrecognized 332 Addresses SHOULD be silently discarded. 333 334 335 336 337 338 339Simpson [Page 5] 340RFC 1662 HDLC-like Framing July 1994 341 342 343 Control Field 344 345 The Control field is a single octet, which contains the binary 346 sequence 00000011 (hexadecimal 0x03), the Unnumbered Information 347 (UI) command with the Poll/Final (P/F) bit set to zero. 348 349 The use of other Control field values may be defined at a later 350 time, or by prior agreement. Frames with unrecognized Control 351 field values SHOULD be silently discarded. 352 353 Frame Check Sequence (FCS) Field 354 355 The Frame Check Sequence field defaults to 16 bits (two octets). 356 The FCS is transmitted least significant octet first, which 357 contains the coefficient of the highest term. 358 359 A 32-bit (four octet) FCS is also defined. Its use may be 360 negotiated as described in "PPP LCP Extensions" [5]. 361 362 The use of other FCS lengths may be defined at a later time, or by 363 prior agreement. 364 365 The FCS field is calculated over all bits of the Address, Control, 366 Protocol, Information and Padding fields, not including any start 367 and stop bits (asynchronous) nor any bits (synchronous) or octets 368 (asynchronous or synchronous) inserted for transparency. This 369 also does not include the Flag Sequences nor the FCS field itself. 370 371 When octets are received which are flagged in the Async- 372 Control-Character-Map, they are discarded before calculating 373 the FCS. 374 375 For more information on the specification of the FCS, see the 376 Appendices. 377 378 The end of the Information and Padding fields is found by locating 379 the closing Flag Sequence and removing the Frame Check Sequence 380 field. 381 382 383 384 385 386 387 388 389 390 391 392 393 394Simpson [Page 6] 395RFC 1662 HDLC-like Framing July 1994 396 397 3983.2. Modification of the Basic Frame 399 400 The Link Control Protocol can negotiate modifications to the standard 401 HDLC-like frame structure. However, modified frames will always be 402 clearly distinguishable from standard frames. 403 404 Address-and-Control-Field-Compression 405 406 When using the standard HDLC-like framing, the Address and Control 407 fields contain the hexadecimal values 0xff and 0x03 respectively. 408 When other Address or Control field values are in use, Address- 409 and-Control-Field-Compression MUST NOT be negotiated. 410 411 On transmission, compressed Address and Control fields are simply 412 omitted. 413 414 On reception, the Address and Control fields are decompressed by 415 examining the first two octets. If they contain the values 0xff 416 and 0x03, they are assumed to be the Address and Control fields. 417 If not, it is assumed that the fields were compressed and were not 418 transmitted. 419 420 By definition, the first octet of a two octet Protocol field 421 will never be 0xff (since it is not even). The Protocol field 422 value 0x00ff is not allowed (reserved) to avoid ambiguity when 423 Protocol-Field-Compression is enabled and the first Information 424 field octet is 0x03. 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449Simpson [Page 7] 450RFC 1662 HDLC-like Framing July 1994 451 452 4534. Octet-stuffed framing 454 455 This chapter summarizes the use of HDLC-like framing with 8-bit 456 asynchronous and octet-synchronous links. 457 458 459 4604.1. Flag Sequence 461 462 The Flag Sequence indicates the beginning or end of a frame. The 463 octet stream is examined on an octet-by-octet basis for the value 464 01111110 (hexadecimal 0x7e). 465 466 467 4684.2. Transparency 469 470 An octet stuffing procedure is used. The Control Escape octet is 471 defined as binary 01111101 (hexadecimal 0x7d), most significant bit 472 first. 473 474 As a minimum, sending implementations MUST escape the Flag Sequence 475 and Control Escape octets. 476 477 After FCS computation, the transmitter examines the entire frame 478 between the two Flag Sequences. Each Flag Sequence, Control Escape 479 octet, and any octet which is flagged in the sending Async-Control- 480 Character-Map (ACCM), is replaced by a two octet sequence consisting 481 of the Control Escape octet followed by the original octet 482 exclusive-or'd with hexadecimal 0x20. 483 484 This is bit 5 complemented, where the bit positions are numbered 485 76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE 486 when comparing documents). 487 488 Receiving implementations MUST correctly process all Control Escape 489 sequences. 490 491 On reception, prior to FCS computation, each octet with value less 492 than hexadecimal 0x20 is checked. If it is flagged in the receiving 493 ACCM, it is simply removed (it may have been inserted by intervening 494 data communications equipment). Each Control Escape octet is also 495 removed, and the following octet is exclusive-or'd with hexadecimal 496 0x20, unless it is the Flag Sequence (which aborts a frame). 497 498 A few examples may make this more clear. Escaped data is transmitted 499 on the link as follows: 500 501 502 503 504Simpson [Page 8] 505RFC 1662 HDLC-like Framing July 1994 506 507 508 509 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence) 510 0x7d is encoded as 0x7d, 0x5d. (Control Escape) 511 0x03 is encoded as 0x7d, 0x23. (ETX) 512 513 Some modems with software flow control may intercept outgoing DC1 and 514 DC3 ignoring the 8th (parity) bit. This data would be transmitted on 515 the link as follows: 516 517 0x11 is encoded as 0x7d, 0x31. (XON) 518 0x13 is encoded as 0x7d, 0x33. (XOFF) 519 0x91 is encoded as 0x7d, 0xb1. (XON with parity set) 520 0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set) 521 522 523 524 5254.3. Invalid Frames 526 527 Frames which are too short (less than 4 octets when using the 16-bit 528 FCS), or which end with a Control Escape octet followed immediately 529 by a closing Flag Sequence, or in which octet-framing is violated (by 530 transmitting a "0" stop bit where a "1" bit is expected), are 531 silently discarded, and not counted as a FCS error. 532 533 534 5354.4. Time Fill 536 5374.4.1. Octet-synchronous 538 539 There is no provision for inter-octet time fill. 540 541 The Flag Sequence MUST be transmitted during inter-frame time fill. 542 543 5444.4.2. Asynchronous 545 546 Inter-octet time fill MUST be accomplished by transmitting continuous 547 "1" bits (mark-hold state). 548 549 Inter-frame time fill can be viewed as extended inter-octet time 550 fill. Doing so can save one octet for every frame, decreasing delay 551 and increasing bandwidth. This is possible since a Flag Sequence may 552 serve as both a frame end and a frame begin. After having received 553 any frame, an idle receiver will always be in a frame begin state. 554 555 556 557 558Simpson [Page 9] 559RFC 1662 HDLC-like Framing July 1994 560 561 562 Robust transmitters should avoid using this trick over-zealously, 563 since the price for decreased delay is decreased reliability. Noisy 564 links may cause the receiver to receive garbage characters and 565 interpret them as part of an incoming frame. If the transmitter does 566 not send a new opening Flag Sequence before sending the next frame, 567 then that frame will be appended to the noise characters causing an 568 invalid frame (with high reliability). 569 570 It is suggested that implementations will achieve the best results by 571 always sending an opening Flag Sequence if the new frame is not 572 back-to-back with the last. Transmitters SHOULD send an open Flag 573 Sequence whenever "appreciable time" has elapsed after the prior 574 closing Flag Sequence. The maximum value for "appreciable time" is 575 likely to be no greater than the typing rate of a slow typist, about 576 1 second. 577 578 579 5804.5. Transmission Considerations 581 5824.5.1. Octet-synchronous 583 584 The definition of various encodings and scrambling is the 585 responsibility of the DTE/DCE equipment in use, and is outside the 586 scope of this specification. 587 588 5894.5.2. Asynchronous 590 591 All octets are transmitted least significant bit first, with one 592 start bit, eight bits of data, and one stop bit. There is no 593 provision for seven bit asynchronous links. 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612Simpson [Page 10] 613RFC 1662 HDLC-like Framing July 1994 614 615 6165. Bit-stuffed framing 617 618 This chapter summarizes the use of HDLC-like framing with bit- 619 synchronous links. 620 621 622 6235.1. Flag Sequence 624 625 The Flag Sequence indicates the beginning or end of a frame, and is 626 used for frame synchronization. The bit stream is examined on a 627 bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e). 628 629 The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be 630 used. When not avoidable, such an implementation MUST ensure that 631 the first Flag Sequence detected (the end of the frame) is promptly 632 communicated to the link layer. Use of the shared zero mode hinders 633 interoperability with bit-synchronous to asynchronous and bit- 634 synchronous to octet-synchronous converters. 635 636 637 6385.2. Transparency 639 640 After FCS computation, the transmitter examines the entire frame 641 between the two Flag Sequences. A "0" bit is inserted after all 642 sequences of five contiguous "1" bits (including the last 5 bits of 643 the FCS) to ensure that a Flag Sequence is not simulated. 644 645 On reception, prior to FCS computation, any "0" bit that directly 646 follows five contiguous "1" bits is discarded. 647 648 649 6505.3. Invalid Frames 651 652 Frames which are too short (less than 4 octets when using the 16-bit 653 FCS), or which end with a sequence of more than six "1" bits, are 654 silently discarded, and not counted as a FCS error. 655 656 657 6585.4. Time Fill 659 660 There is no provision for inter-octet time fill. 661 662 The Flag Sequence SHOULD be transmitted during inter-frame time fill. 663 However, certain types of circuit-switched links require the use of 664 665 666 667Simpson [Page 11] 668RFC 1662 HDLC-like Framing July 1994 669 670 671 mark idle (continuous ones), particularly those that calculate 672 accounting based on periods of bit activity. When mark idle is used 673 on a bit-synchronous link, the implementation MUST ensure at least 15 674 consecutive "1" bits between Flags during the idle period, and that 675 the Flag Sequence is always generated at the beginning of a frame 676 after an idle period. 677 678 This differs from practice in ISO 3309, which allows 7 to 14 bit 679 mark idle. 680 681 682 6835.5. Transmission Considerations 684 685 All octets are transmitted least significant bit first. 686 687 The definition of various encodings and scrambling is the 688 responsibility of the DTE/DCE equipment in use, and is outside the 689 scope of this specification. 690 691 While PPP will operate without regard to the underlying 692 representation of the bit stream, lack of standards for transmission 693 will hinder interoperability as surely as lack of data link 694 standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently 695 most widely available, and on that basis is recommended as a default. 696 697 When configuration of the encoding is allowed, NRZI is recommended as 698 an alternative, because of its relative immunity to signal inversion 699 configuration errors, and instances when it MAY allow connection 700 without an expensive DSU/CSU. Unfortunately, NRZI encoding 701 exacerbates the missing x1 factor of the 16-bit FCS, so that one 702 error in 2**15 goes undetected (instead of one in 2**16), and triple 703 errors are not detected. Therefore, when NRZI is in use, it is 704 recommended that the 32-bit FCS be negotiated, which includes the x1 705 factor. 706 707 At higher speeds of up to 45 Mbps, some implementors have chosen the 708 ANSI High Speed Synchronous Interface [HSSI]. While this experience 709 is currently limited, implementors are encouraged to cooperate in 710 choosing transmission encoding. 711 712 713 714 715 716 717 718 719 720 721 722Simpson [Page 12] 723RFC 1662 HDLC-like Framing July 1994 724 725 7266. Asynchronous to Synchronous Conversion 727 728 There may be some use of asynchronous-to-synchronous converters (some 729 built into modems and cellular interfaces), resulting in an 730 asynchronous PPP implementation on one end of a link and a 731 synchronous implementation on the other. It is the responsibility of 732 the converter to do all stuffing conversions during operation. 733 734 To enable this functionality, synchronous PPP implementations MUST 735 always respond to the Async-Control-Character-Map Configuration 736 Option with the LCP Configure-Ack. However, acceptance of the 737 Configuration Option does not imply that the synchronous 738 implementation will do any ACCM mapping. Instead, all such octet 739 mapping will be performed by the asynchronous-to-synchronous 740 converter. 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777Simpson [Page 13] 778RFC 1662 HDLC-like Framing July 1994 779 780 7817. Additional LCP Configuration Options 782 783 The Configuration Option format and basic options are already defined 784 for LCP [1]. 785 786 Up-to-date values of the LCP Option Type field are specified in the 787 most recent "Assigned Numbers" RFC [10]. This document concerns the 788 following values: 789 790 2 Async-Control-Character-Map 791 792 793 794 7957.1. Async-Control-Character-Map (ACCM) 796 797 Description 798 799 This Configuration Option provides a method to negotiate the use 800 of control character transparency on asynchronous links. 801 802 Each end of the asynchronous link maintains two Async-Control- 803 Character-Maps. The receiving ACCM is 32 bits, but the sending 804 ACCM may be up to 256 bits. This results in four distinct ACCMs, 805 two in each direction of the link. 806 807 For asynchronous links, the default receiving ACCM is 0xffffffff. 808 The default sending ACCM is 0xffffffff, plus the Control Escape 809 and Flag Sequence characters themselves, plus whatever other 810 outgoing characters are flagged (by prior configuration) as likely 811 to be intercepted. 812 813 For other types of links, the default value is 0, since there is 814 no need for mapping. 815 816 The default inclusion of all octets less than hexadecimal 0x20 817 allows all ASCII control characters [6] excluding DEL (Delete) 818 to be transparently communicated through all known data 819 communications equipment. 820 821 The transmitter MAY also send octets with values in the range 0x40 822 through 0xff (except 0x5e) in Control Escape format. Since these 823 octet values are not negotiable, this does not solve the problem 824 of receivers which cannot handle all non-control characters. 825 Also, since the technique does not affect the 8th bit, this does 826 not solve problems for communications links that can send only 7- 827 bit characters. 828 829 830 831 832Simpson [Page 14] 833RFC 1662 HDLC-like Framing July 1994 834 835 836 Note that this specification differs in detail from later 837 amendments, such as 3309:1991/Amendment 2 [3]. However, such 838 "extended transparency" is applied only by "prior agreement". 839 Use of the transparency methods in this specification 840 constitute a prior agreement with respect to PPP. 841 842 For compatibility with 3309:1991/Amendment 2, the transmitter 843 MAY escape DEL and ACCM equivalents with the 8th (most 844 significant) bit set. No change is required in the receiving 845 algorithm. 846 847 Following ACCM negotiation, the transmitter SHOULD cease 848 escaping DEL. 849 850 However, it is rarely necessary to map all control characters, and 851 often it is unnecessary to map any control characters. The 852 Configuration Option is used to inform the peer which control 853 characters MUST remain mapped when the peer sends them. 854 855 The peer MAY still send any other octets in mapped format, if it 856 is necessary because of constraints known to the peer. The peer 857 SHOULD Configure-Nak with the logical union of the sets of mapped 858 octets, so that when such octets are spuriously introduced they 859 can be ignored on receipt. 860 861 A summary of the Async-Control-Character-Map Configuration Option 862 format is shown below. The fields are transmitted from left to 863 right. 864 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Type | Length | ACCM 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 ACCM (cont) | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 873 874 Type 875 876 2 877 878 Length 879 880 6 881 882 883 884 885 886 887Simpson [Page 15] 888RFC 1662 HDLC-like Framing July 1994 889 890 891 ACCM 892 893 The ACCM field is four octets, and indicates the set of control 894 characters to be mapped. The map is sent most significant octet 895 first. 896 897 Each numbered bit corresponds to the octet of the same value. If 898 the bit is cleared to zero, then that octet need not be mapped. 899 If the bit is set to one, then that octet MUST remain mapped. For 900 example, if bit 19 is set to zero, then the ASCII control 901 character 19 (DC3, Control-S) MAY be sent in the clear. 902 903 Note: The least significant bit of the least significant octet 904 (the final octet transmitted) is numbered bit 0, and would map 905 to the ASCII control character NUL. 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942Simpson [Page 16] 943RFC 1662 HDLC-like Framing July 1994 944 945 946A. Recommended LCP Options 947 948 The following Configurations Options are recommended: 949 950 High Speed links 951 952 Magic Number 953 Link Quality Monitoring 954 No Address and Control Field Compression 955 No Protocol Field Compression 956 957 958 Low Speed or Asynchronous links 959 960 Async Control Character Map 961 Magic Number 962 Address and Control Field Compression 963 Protocol Field Compression 964 965 966 967B. Automatic Recognition of PPP Frames 968 969 It is sometimes desirable to detect PPP frames, for example during a 970 login sequence. The following octet sequences all begin valid PPP 971 LCP frames: 972 973 7e ff 03 c0 21 974 7e ff 7d 23 c0 21 975 7e 7d df 7d 23 c0 21 976 977 Note that the first two forms are not a valid username for Unix. 978 However, only the third form generates a correctly checksummed PPP 979 frame, whenever 03 and ff are taken as the control characters ETX and 980 DEL without regard to parity (they are correct for an even parity 981 link) and discarded. 982 983 Many implementations deal with this by putting the interface into 984 packet mode when one of the above username patterns are detected 985 during login, without examining the initial PPP checksum. The 986 initial incoming PPP frame is discarded, but a Configure-Request is 987 sent immediately. 988 989 990 991 992 993 994 995 996 997Simpson [Page 17] 998RFC 1662 HDLC-like Framing July 1994 999 1000 1001C. Fast Frame Check Sequence (FCS) Implementation 1002 1003 The FCS was originally designed with hardware implementations in 1004 mind. A serial bit stream is transmitted on the wire, the FCS is 1005 calculated over the serial data as it goes out, and the complement of 1006 the resulting FCS is appended to the serial stream, followed by the 1007 Flag Sequence. 1008 1009 The receiver has no way of determining that it has finished 1010 calculating the received FCS until it detects the Flag Sequence. 1011 Therefore, the FCS was designed so that a particular pattern results 1012 when the FCS operation passes over the complemented FCS. A good 1013 frame is indicated by this "good FCS" value. 1014 1015 1016 1017C.1. FCS table generator 1018 1019 The following code creates the lookup table used to calculate the 1020 FCS-16. 1021 1022 /* 1023 * Generate a FCS-16 table. 1024 * 1025 * Drew D. Perkins at Carnegie Mellon University. 1026 * 1027 * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. 1028 */ 1029 1030 /* 1031 * The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16. 1032 */ 1033 #define P 0x8408 1034 1035 1036 main() 1037 { 1038 register unsigned int b, v; 1039 register int i; 1040 1041 printf("typedef unsigned short u16;\n"); 1042 printf("static u16 fcstab[256] = {"); 1043 for (b = 0; ; ) { 1044 if (b % 8 == 0) 1045 printf("\n"); 1046 1047 v = b; 1048 for (i = 8; i--; ) 1049 1050 1051 1052Simpson [Page 18] 1053RFC 1662 HDLC-like Framing July 1994 1054 1055 1056 v = v & 1 ? (v >> 1) ^ P : v >> 1; 1057 1058 printf("\t0x%04x", v & 0xFFFF); 1059 if (++b == 256) 1060 break; 1061 printf(","); 1062 } 1063 printf("\n};\n"); 1064 } 1065 1066 1067 1068C.2. 16-bit FCS Computation Method 1069 1070 The following code provides a table lookup computation for 1071 calculating the Frame Check Sequence as data arrives at the 1072 interface. This implementation is based on [7], [8], and [9]. 1073 1074 /* 1075 * u16 represents an unsigned 16-bit number. Adjust the typedef for 1076 * your hardware. 1077 */ 1078 typedef unsigned short u16; 1079 1080 /* 1081 * FCS lookup table as calculated by the table generator. 1082 */ 1083 static u16 fcstab[256] = { 1084 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 1085 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 1086 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 1087 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 1088 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 1089 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 1090 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 1091 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 1092 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 1093 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 1094 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 1095 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 1096 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 1097 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 1098 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 1099 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 1100 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 1101 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 1102 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 1103 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 1104 1105 1106 1107Simpson [Page 19] 1108RFC 1662 HDLC-like Framing July 1994 1109 1110 1111 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 1112 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 1113 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 1114 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 1115 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 1116 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 1117 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 1118 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 1119 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 1120 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 1121 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 1122 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 1123 }; 1124 1125 #define PPPINITFCS16 0xffff /* Initial FCS value */ 1126 #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */ 1127 1128 /* 1129 * Calculate a new fcs given the current fcs and the new data. 1130 */ 1131 u16 pppfcs16(fcs, cp, len) 1132 register u16 fcs; 1133 register unsigned char *cp; 1134 register int len; 1135 { 1136 ASSERT(sizeof (u16) == 2); 1137 ASSERT(((u16) -1) > 0); 1138 while (len--) 1139 fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff]; 1140 1141 return (fcs); 1142 } 1143 1144 /* 1145 * How to use the fcs 1146 */ 1147 tryfcs16(cp, len) 1148 register unsigned char *cp; 1149 register int len; 1150 { 1151 u16 trialfcs; 1152 1153 /* add on output */ 1154 trialfcs = pppfcs16( PPPINITFCS16, cp, len ); 1155 trialfcs ^= 0xffff; /* complement */ 1156 cp[len] = (trialfcs & 0x00ff); /* least significant byte first */ 1157 cp[len+1] = ((trialfcs >> 8) & 0x00ff); 1158 1159 1160 1161 1162Simpson [Page 20] 1163RFC 1662 HDLC-like Framing July 1994 1164 1165 1166 /* check on input */ 1167 trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 ); 1168 if ( trialfcs == PPPGOODFCS16 ) 1169 printf("Good FCS\n"); 1170 } 1171 1172 1173 1174C.3. 32-bit FCS Computation Method 1175 1176 The following code provides a table lookup computation for 1177 calculating the 32-bit Frame Check Sequence as data arrives at the 1178 interface. 1179 1180 /* 1181 * The FCS-32 generator polynomial: x**0 + x**1 + x**2 + x**4 + x**5 1182 * + x**7 + x**8 + x**10 + x**11 + x**12 + x**16 1183 * + x**22 + x**23 + x**26 + x**32. 1184 */ 1185 1186 /* 1187 * u32 represents an unsigned 32-bit number. Adjust the typedef for 1188 * your hardware. 1189 */ 1190 typedef unsigned long u32; 1191 1192 static u32 fcstab_32[256] = 1193 { 1194 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 1195 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, 1196 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, 1197 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 1198 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, 1199 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 1200 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 1201 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, 1202 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, 1203 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 1204 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 1205 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 1206 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 1207 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, 1208 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, 1209 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 1210 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, 1211 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, 1212 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 1213 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, 1214 1215 1216 1217Simpson [Page 21] 1218RFC 1662 HDLC-like Framing July 1994 1219 1220 1221 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 1222 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 1223 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, 1224 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, 1225 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 1226 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, 1227 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, 1228 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, 1229 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, 1230 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f, 1231 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 1232 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, 1233 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, 1234 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, 1235 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, 1236 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 1237 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 1238 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7, 1239 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, 1240 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, 1241 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 1242 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b, 1243 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 1244 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79, 1245 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, 1246 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 1247 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 1248 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d, 1249 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 1250 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713, 1251 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 1252 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 1253 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, 1254 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777, 1255 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 1256 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, 1257 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, 1258 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 1259 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, 1260 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9, 1261 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 1262 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf, 1263 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, 1264 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d 1265 }; 1266 1267 #define PPPINITFCS32 0xffffffff /* Initial FCS value */ 1268 #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */ 1269 1270 1271 1272Simpson [Page 22] 1273RFC 1662 HDLC-like Framing July 1994 1274 1275 1276 /* 1277 * Calculate a new FCS given the current FCS and the new data. 1278 */ 1279 u32 pppfcs32(fcs, cp, len) 1280 register u32 fcs; 1281 register unsigned char *cp; 1282 register int len; 1283 { 1284 ASSERT(sizeof (u32) == 4); 1285 ASSERT(((u32) -1) > 0); 1286 while (len--) 1287 fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]); 1288 1289 return (fcs); 1290 } 1291 1292 /* 1293 * How to use the fcs 1294 */ 1295 tryfcs32(cp, len) 1296 register unsigned char *cp; 1297 register int len; 1298 { 1299 u32 trialfcs; 1300 1301 /* add on output */ 1302 trialfcs = pppfcs32( PPPINITFCS32, cp, len ); 1303 trialfcs ^= 0xffffffff; /* complement */ 1304 cp[len] = (trialfcs & 0x00ff); /* least significant byte first */ 1305 cp[len+1] = ((trialfcs >>= 8) & 0x00ff); 1306 cp[len+2] = ((trialfcs >>= 8) & 0x00ff); 1307 cp[len+3] = ((trialfcs >> 8) & 0x00ff); 1308 1309 /* check on input */ 1310 trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 ); 1311 if ( trialfcs == PPPGOODFCS32 ) 1312 printf("Good FCS\n"); 1313 } 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327Simpson [Page 23] 1328RFC 1662 HDLC-like Framing July 1994 1329 1330 1331Security Considerations 1332 1333 As noted in the Physical Layer Requirements section, the link layer 1334 might not be informed when the connected state of the physical layer 1335 has changed. This results in possible security lapses due to over- 1336 reliance on the integrity and security of switching systems and 1337 administrations. An insertion attack might be undetected. An 1338 attacker which is able to spoof the same calling identity might be 1339 able to avoid link authentication. 1340 1341 1342 1343References 1344 1345 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 1346 STD 50, RFC 1661, Daydreamer, July 1994. 1347 1348 [2] ISO/IEC 3309:1991(E), "Information Technology - 1349 Telecommunications and information exchange between systems - 1350 High-level data link control (HDLC) procedures - Frame 1351 structure", International Organization For Standardization, 1352 Fourth edition 1991-06-01. 1353 1354 [3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology - 1355 Telecommunications and information exchange between systems - 1356 High-level data link control (HDLC) procedures - Frame 1357 structure - Amendment 2: Extended transparency options for 1358 start/stop transmission", International Organization For 1359 Standardization, 1992-01-15. 1360 1361 [4] ISO/IEC 4335:1991(E), "Information Technology - 1362 Telecommunications and information exchange between systems - 1363 High-level data link control (HDLC) procedures - Elements of 1364 procedures", International Organization For Standardization, 1365 Fourth edition 1991-09-15. 1366 1367 [5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, 1368 Daydreamer, January 1994. 1369 1370 [6] ANSI X3.4-1977, "American National Standard Code for 1371 Information Interchange", American National Standards 1372 Institute, 1977. 1373 1374 [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983. 1375 1376 [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte, 1377 September 1986. 1378 1379 1380 1381 1382Simpson [Page 24] 1383RFC 1662 HDLC-like Framing July 1994 1384 1385 1386 [9] LeVan, J., "A Fast CRC", Byte, November 1987. 1387 1388 [10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1389 1340, USC/Information Sciences Institute, July 1992. 1390 1391 1392 1393Acknowledgements 1394 1395 This document is the product of the Point-to-Point Protocol Working 1396 Group of the Internet Engineering Task Force (IETF). Comments should 1397 be submitted to the ietf-ppp@merit.edu mailing list. 1398 1399 This specification is based on previous RFCs, where many 1400 contributions have been acknowleged. 1401 1402 The 32-bit FCS example code was provided by Karl Fox (Morning Star 1403 Technologies). 1404 1405 Special thanks to Morning Star Technologies for providing computing 1406 resources and network access support for writing this specification. 1407 1408 1409 1410Chair's Address 1411 1412 The working group can be contacted via the current chair: 1413 1414 Fred Baker 1415 Advanced Computer Communications 1416 315 Bollay Drive 1417 Santa Barbara, California 93117 1418 1419 fbaker@acc.com 1420 1421 1422Editor's Address 1423 1424 Questions about this memo can also be directed to: 1425 1426 William Allen Simpson 1427 Daydreamer 1428 Computer Systems Consulting Services 1429 1384 Fontaine 1430 Madison Heights, Michigan 48071 1431 1432 Bill.Simpson@um.cc.umich.edu 1433 bsimpson@MorningStar.com 1434 1435 1436Simpson [Page 25] 1437