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