As per Relevance of the word implementation, we have this rfc below:
Network Working Group W. Simpson,
Request for Comments: 1662
STD: 51 July 1994
Obsoletes: 1549
Category: Standards
PPP in HDLC-like
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links
This document describes the use of HDLC-like framing for
encapsulated packets
Table of
1. Introduction .......................................... 1
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 2
2. Physical Layer Requirements ........................... 3
3. The Data Link Layer ................................... 4
3.1 Frame Format .................................... 5
3.2 Modification of the Basic Frame ................. 7
4. Octet-stuffed framing ................................. 8
4.1 Flag Sequence ................................... 8
4.2 Transparency .................................... 8
4.3 Invalid Frames .................................. 9
4.4 Time Fill ....................................... 9
4.4.1 Octet-synchronous ............................... 9
4.4.2 Asynchronous .................................... 9
4.5 Transmission Considerations ..................... 10
4.5.1 Octet-synchronous ............................... 10
4.5.2 Asynchronous .................................... 10
Simpson [Page i
RFC 1662 HDLC-like Framing July 1994
5. Bit-stuffed framing ................................... 11
5.1 Flag Sequence ................................... 11
5.2 Transparency .................................... 11
5.3 Invalid Frames .................................. 11
5.4 Time Fill ....................................... 11
5.5 Transmission Considerations ..................... 12
6. Asynchronous to Synchronous Conversion ................ 13
7. Additional LCP Configuration Options .................. 14
7.1 Async-Control-Character-Map (ACCM) .............. 14
APPENDICES ................................................... 17
A. Recommended LCP Options ............................... 17
B. Automatic Recognition of PPP Frames ................... 17
C. Fast Frame Check Sequence (FCS) Implementation ........ 18
C.1 FCS table generator ............................. 18
C.2 16-bit FCS Computation Method ................... 19
C.3 32-bit FCS Computation Method ................... 21
SECURITY CONSIDERATIONS ...................................... 24
REFERENCES ................................................... 24
ACKNOWLEDGEMENTS ............................................. 25
CHAIR'S ADDRESS .............................................. 25
EDITOR'S ADDRESS ............................................. 25
1.
This specification provides for framing over both bit-oriented
octet-oriented synchronous links, and asynchronous links with 8
of data and no parity. These links MUST be full-duplex, but MAY
either dedicated or circuit-switched
An escape mechanism is specified to allow control data such
XON/XOFF to be transmitted transparently over the link, and to
spurious control data which may be injected into the link
intervening hardware and software
Some protocols expect error free transmission, and either
error detection only on a conditional basis, or do not provide it
all. PPP uses the HDLC Frame Check Sequence for error detection
This is commonly available in hardware implementations, and
software implementation is provided
Simpson [Page 1]
RFC 1662 HDLC-like Framing July 1994
1.1. Specification of
In this document, several words are used to signify the
of the specification. These words are often capitalized
MUST This word, or the adjective "required", means that
definition is an absolute requirement of the specification
MUST NOT This phrase means that the definition is an
prohibition of the specification
SHOULD This word, or the adjective "recommended", means that
may exist valid reasons in particular circumstances
ignore this item, but the full implications must
understood and carefully weighed before choosing
different course
MAY This word, or the adjective "optional", means that
item is one of an allowed set of alternatives.
implementation which does not include this option MUST
prepared to interoperate with another implementation
does include the option
1.2.
This document frequently uses the following terms
datagram The unit of transmission in the network layer (such as IP).
A datagram may be encapsulated in one or more
passed to the data link layer
frame The unit of transmission at the data link layer. A
may include a header and/or a trailer, along with
number of units of data
packet The basic unit of encapsulation, which is passed across
interface between the network layer and the data
layer. A packet is usually mapped to a frame;
exceptions are when data link layer fragmentation is
performed, or when multiple packets are incorporated into
single frame
peer The other end of the point-to-point link
silently
The implementation discards the packet without
processing. The implementation SHOULD provide
capability of logging the error, including the contents
the silently discarded packet, and SHOULD record the
in a statistics counter
Simpson [Page 2]
RFC 1662 HDLC-like Framing July 1994
2. Physical Layer
PPP is capable of operating across most DTE/DCE interfaces (such as
EIA RS-232-E, EIA RS-422, and CCITT V.35). The only
requirement imposed by PPP is the provision of a full-duplex circuit
either dedicated or circuit-switched, which can operate in either
asynchronous (start/stop), bit-synchronous, or octet-
mode, transparent to PPP Data Link Layer frames
Interface
PPP presents an octet interface to the physical layer. There
no provision for sub-octets to be supplied or accepted
Transmission
PPP does not impose any restrictions regarding transmission rate
other than that of the particular DTE/DCE interface
Control
PPP does not require the use of control signals, such as
To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD),
Data Terminal Ready (DTR).
When available, using such signals can allow greater
and performance. In particular, such signals SHOULD be used
signal the Up and Down events in the LCP Option
Automaton [1]. When such signals are not available,
implementation MUST signal the Up event to LCP
initialization, and SHOULD NOT signal the Down event
Because signalling is not required, the physical layer MAY
decoupled from the data link layer, hiding the transient
of the physical transport. This has implications for mobility
cellular radio networks, and other rapidly switching links
When moving from cell to cell within the same zone,
implementation MAY choose to treat the entire zone as a
link, even though transmission is switched among
frequencies. The link is considered to be with the
control unit for the zone, rather than the individual
transceivers. However, the link SHOULD re-establish
configuration whenever the link is switched to a
administration
Due to the bursty nature of data traffic, some
have choosen to disconnect the physical layer during periods
Simpson [Page 3]
RFC 1662 HDLC-like Framing July 1994
inactivity, and reconnect when traffic resumes, without
the data link layer. Robust implementations should avoid
this trick over-zealously, since the price for decreased
latency is decreased security. Implementations SHOULD signal
Down event whenever "significant time" has elapsed since the
was disconnected. The value for "significant time" is a matter
considerable debate, and is based on the tariffs, call
times, and security concerns of the installation
3. The Data Link
PPP uses the principles described in ISO 3309-1979 HDLC
structure, most recently the fourth edition 3309:1991 [2],
specifies modifications to allow HDLC use in
environments
The PPP control procedures use the Control field encodings
in ISO 4335-1979 HDLC elements of procedures, most recently
fourth edition 4335:1991 [4].
This should not be construed to indicate that every feature of
above recommendations are included in PPP. Each feature
is explicitly described in the following sections
To remain consistent with standard Internet practice, and
confusion for people used to reading RFCs, all binary numbers in
following descriptions are in Most Significant Bit to
Significant Bit order, reading from left to right, unless
indicated. Note that this is contrary to standard ISO and
practice which orders bits as transmitted (network bit order).
this in mind when comparing this document with the
standards documents
Simpson [Page 4]
RFC 1662 HDLC-like Framing July 1994
3.1. Frame
A summary of the PPP HDLC-like frame structure is shown below.
figure does not include bits inserted for synchronization (such
start and stop bits for asynchronous links), nor any bits or
inserted for transparency. The fields are transmitted from left
right
+----------+----------+----------+
| Flag | Address | Control |
| 01111110 | 11111111 | 00000011 |
+----------+----------+----------+
+----------+-------------+---------+
| Protocol | Information | Padding |
| 8/16 bits| * | * |
+----------+-------------+---------+
+----------+----------+-----------------
| FCS | Flag | Inter-frame
|16/32 bits| 01111110 | or next
+----------+----------+-----------------
The Protocol, Information and Padding fields are described in
Point-to-Point Protocol Encapsulation [1].
Flag
Each frame begins and ends with a Flag Sequence, which is
binary sequence 01111110 (hexadecimal 0x7e). All
continuously check for this flag, which is used for
synchronization
Only one Flag Sequence is required between two frames.
consecutive Flag Sequences constitute an empty frame, which
silently discarded, and not counted as a FCS error
Address
The Address field is a single octet, which contains the
sequence 11111111 (hexadecimal 0xff), the All-Stations address
Individual station addresses are not assigned. The All-
address MUST always be recognized and received
The use of other address lengths and values may be defined at
later time, or by prior agreement. Frames with
Addresses SHOULD be silently discarded
Simpson [Page 5]
RFC 1662 HDLC-like Framing July 1994
Control
The Control field is a single octet, which contains the
sequence 00000011 (hexadecimal 0x03), the Unnumbered
(UI) command with the Poll/Final (P/F) bit set to zero
The use of other Control field values may be defined at a
time, or by prior agreement. Frames with unrecognized
field values SHOULD be silently discarded
Frame Check Sequence (FCS)
The Frame Check Sequence field defaults to 16 bits (two octets).
The FCS is transmitted least significant octet first,
contains the coefficient of the highest term
A 32-bit (four octet) FCS is also defined. Its use may
negotiated as described in "PPP LCP Extensions" [5].
The use of other FCS lengths may be defined at a later time, or
prior agreement
The FCS field is calculated over all bits of the Address, Control
Protocol, Information and Padding fields, not including any
and stop bits (asynchronous) nor any bits (synchronous) or
(asynchronous or synchronous) inserted for transparency.
also does not include the Flag Sequences nor the FCS field itself
When octets are received which are flagged in the Async
Control-Character-Map, they are discarded before
the FCS
For more information on the specification of the FCS, see
Appendices
The end of the Information and Padding fields is found by
the closing Flag Sequence and removing the Frame Check
field
Simpson [Page 6]
RFC 1662 HDLC-like Framing July 1994
3.2. Modification of the Basic
The Link Control Protocol can negotiate modifications to the
HDLC-like frame structure. However, modified frames will always
clearly distinguishable from standard frames
Address-and-Control-Field-
When using the standard HDLC-like framing, the Address and
fields contain the hexadecimal values 0xff and 0x03 respectively
When other Address or Control field values are in use, Address
and-Control-Field-Compression MUST NOT be negotiated
On transmission, compressed Address and Control fields are
omitted
On reception, the Address and Control fields are decompressed
examining the first two octets. If they contain the values 0
and 0x03, they are assumed to be the Address and Control fields
If not, it is assumed that the fields were compressed and were
transmitted
By definition, the first octet of a two octet Protocol
will never be 0xff (since it is not even). The Protocol
value 0x00ff is not allowed (reserved) to avoid ambiguity
Protocol-Field-Compression is enabled and the first
field octet is 0x03.
Simpson [Page 7]
RFC 1662 HDLC-like Framing July 1994
4. Octet-stuffed
This chapter summarizes the use of HDLC-like framing with 8-
asynchronous and octet-synchronous links
4.1. Flag
The Flag Sequence indicates the beginning or end of a frame.
octet stream is examined on an octet-by-octet basis for the
01111110 (hexadecimal 0x7e).
4.2.
An octet stuffing procedure is used. The Control Escape octet
defined as binary 01111101 (hexadecimal 0x7d), most significant
first
As a minimum, sending implementations MUST escape the Flag
and Control Escape octets
After FCS computation, the transmitter examines the entire
between the two Flag Sequences. Each Flag Sequence, Control
octet, and any octet which is flagged in the sending Async-Control
Character-Map (ACCM), is replaced by a two octet sequence
of the Control Escape octet followed by the original
exclusive-or'd with hexadecimal 0x20.
This is bit 5 complemented, where the bit positions are
76543210 (the 6th bit as used in ISO numbered 87654321 --
when comparing documents).
Receiving implementations MUST correctly process all Control
sequences
On reception, prior to FCS computation, each octet with value
than hexadecimal 0x20 is checked. If it is flagged in the
ACCM, it is simply removed (it may have been inserted by
data communications equipment). Each Control Escape octet is
removed, and the following octet is exclusive-or'd with
0x20, unless it is the Flag Sequence (which aborts a frame).
A few examples may make this more clear. Escaped data is
on the link as follows
Simpson [Page 8]
RFC 1662 HDLC-like Framing July 1994
0x7e is encoded as 0x7d, 0x5e. (Flag Sequence
0x7d is encoded as 0x7d, 0x5d. (Control Escape
0x03 is encoded as 0x7d, 0x23. (ETX
Some modems with software flow control may intercept outgoing DC1
DC3 ignoring the 8th (parity) bit. This data would be transmitted
the link as follows
0x11 is encoded as 0x7d, 0x31. (XON
0x13 is encoded as 0x7d, 0x33. (XOFF
0x91 is encoded as 0x7d, 0xb1. (XON with parity set
0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set
4.3. Invalid
Frames which are too short (less than 4 octets when using the 16-
FCS), or which end with a Control Escape octet followed
by a closing Flag Sequence, or in which octet-framing is violated (
transmitting a "0" stop bit where a "1" bit is expected),
silently discarded, and not counted as a FCS error
4.4. Time
4.4.1. Octet-
There is no provision for inter-octet time fill
The Flag Sequence MUST be transmitted during inter-frame time fill
4.4.2.
Inter-octet time fill MUST be accomplished by transmitting
"1" bits (mark-hold state).
Inter-frame time fill can be viewed as extended inter-octet
fill. Doing so can save one octet for every frame, decreasing
and increasing bandwidth. This is possible since a Flag Sequence
serve as both a frame end and a frame begin. After having
any frame, an idle receiver will always be in a frame begin state
Simpson [Page 9]
RFC 1662 HDLC-like Framing July 1994
Robust transmitters should avoid using this trick over-zealously
since the price for decreased delay is decreased reliability.
links may cause the receiver to receive garbage characters
interpret them as part of an incoming frame. If the transmitter
not send a new opening Flag Sequence before sending the next frame
then that frame will be appended to the noise characters causing
invalid frame (with high reliability).
It is suggested that implementations will achieve the best results
always sending an opening Flag Sequence if the new frame is
back-to-back with the last. Transmitters SHOULD send an open
Sequence whenever "appreciable time" has elapsed after the
closing Flag Sequence. The maximum value for "appreciable time"
likely to be no greater than the typing rate of a slow typist,
1 second
4.5. Transmission
4.5.1. Octet-
The definition of various encodings and scrambling is
responsibility of the DTE/DCE equipment in use, and is outside
scope of this specification
4.5.2.
All octets are transmitted least significant bit first, with
start bit, eight bits of data, and one stop bit. There is
provision for seven bit asynchronous links
Simpson [Page 10]
RFC 1662 HDLC-like Framing July 1994
5. Bit-stuffed
This chapter summarizes the use of HDLC-like framing with bit
synchronous links
5.1. Flag
The Flag Sequence indicates the beginning or end of a frame, and
used for frame synchronization. The bit stream is examined on
bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e).
The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT
used. When not avoidable, such an implementation MUST ensure
the first Flag Sequence detected (the end of the frame) is
communicated to the link layer. Use of the shared zero mode
interoperability with bit-synchronous to asynchronous and bit
synchronous to octet-synchronous converters
5.2.
After FCS computation, the transmitter examines the entire
between the two Flag Sequences. A "0" bit is inserted after
sequences of five contiguous "1" bits (including the last 5 bits
the FCS) to ensure that a Flag Sequence is not simulated
On reception, prior to FCS computation, any "0" bit that
follows five contiguous "1" bits is discarded
5.3. Invalid
Frames which are too short (less than 4 octets when using the 16-
FCS), or which end with a sequence of more than six "1" bits,
silently discarded, and not counted as a FCS error
5.4. Time
There is no provision for inter-octet time fill
The Flag Sequence SHOULD be transmitted during inter-frame time fill
However, certain types of circuit-switched links require the use
Simpson [Page 11]
RFC 1662 HDLC-like Framing July 1994
mark idle (continuous ones), particularly those that
accounting based on periods of bit activity. When mark idle is
on a bit-synchronous link, the implementation MUST ensure at least 15
consecutive "1" bits between Flags during the idle period, and
the Flag Sequence is always generated at the beginning of a
after an idle period
This differs from practice in ISO 3309, which allows 7 to 14
mark idle
5.5. Transmission
All octets are transmitted least significant bit first
The definition of various encodings and scrambling is
responsibility of the DTE/DCE equipment in use, and is outside
scope of this specification
While PPP will operate without regard to the
representation of the bit stream, lack of standards for
will hinder interoperability as surely as lack of data
standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is
most widely available, and on that basis is recommended as a default
When configuration of the encoding is allowed, NRZI is recommended
an alternative, because of its relative immunity to signal
configuration errors, and instances when it MAY allow
without an expensive DSU/CSU. Unfortunately, NRZI
exacerbates the missing x1 factor of the 16-bit FCS, so that
error in 2**15 goes undetected (instead of one in 2**16), and
errors are not detected. Therefore, when NRZI is in use, it
recommended that the 32-bit FCS be negotiated, which includes the x
factor
At higher speeds of up to 45 Mbps, some implementors have chosen
ANSI High Speed Synchronous Interface [HSSI]. While this
is currently limited, implementors are encouraged to cooperate
choosing transmission encoding
Simpson [Page 12]
RFC 1662 HDLC-like Framing July 1994
6. Asynchronous to Synchronous
There may be some use of asynchronous-to-synchronous converters (
built into modems and cellular interfaces), resulting in
asynchronous PPP implementation on one end of a link and
synchronous implementation on the other. It is the responsibility
the converter to do all stuffing conversions during operation
To enable this functionality, synchronous PPP implementations
always respond to the Async-Control-Character-Map
Option with the LCP Configure-Ack. However, acceptance of
Configuration Option does not imply that the
implementation will do any ACCM mapping. Instead, all such
mapping will be performed by the asynchronous-to-
converter
Simpson [Page 13]
RFC 1662 HDLC-like Framing July 1994
7. Additional LCP Configuration
The Configuration Option format and basic options are already
for LCP [1].
Up-to-date values of the LCP Option Type field are specified in
most recent "Assigned Numbers" RFC [10]. This document concerns
following values
2 Async-Control-Character-
7.1. Async-Control-Character-Map (ACCM
This Configuration Option provides a method to negotiate the
of control character transparency on asynchronous links
Each end of the asynchronous link maintains two Async-Control
Character-Maps. The receiving ACCM is 32 bits, but the
ACCM may be up to 256 bits. This results in four distinct ACCMs
two in each direction of the link
For asynchronous links, the default receiving ACCM is 0xffffffff
The default sending ACCM is 0xffffffff, plus the Control
and Flag Sequence characters themselves, plus whatever
outgoing characters are flagged (by prior configuration) as
to be intercepted
For other types of links, the default value is 0, since there
no need for mapping
The default inclusion of all octets less than hexadecimal 0x20
allows all ASCII control characters [6] excluding DEL (Delete
to be transparently communicated through all known
communications equipment
The transmitter MAY also send octets with values in the range 0x40
through 0xff (except 0x5e) in Control Escape format. Since
octet values are not negotiable, this does not solve the
of receivers which cannot handle all non-control characters
Also, since the technique does not affect the 8th bit, this
not solve problems for communications links that can send only 7-
bit characters
Simpson [Page 14]
RFC 1662 HDLC-like Framing July 1994
Note that this specification differs in detail from
amendments, such as 3309:1991/Amendment 2 [3]. However,
"extended transparency" is applied only by "prior agreement".
Use of the transparency methods in this
constitute a prior agreement with respect to PPP
For compatibility with 3309:1991/Amendment 2, the
MAY escape DEL and ACCM equivalents with the 8th (
significant) bit set. No change is required in the
algorithm
Following ACCM negotiation, the transmitter SHOULD
escaping DEL
However, it is rarely necessary to map all control characters,
often it is unnecessary to map any control characters.
Configuration Option is used to inform the peer which
characters MUST remain mapped when the peer sends them
The peer MAY still send any other octets in mapped format, if
is necessary because of constraints known to the peer. The
SHOULD Configure-Nak with the logical union of the sets of
octets, so that when such octets are spuriously introduced
can be ignored on receipt
A summary of the Async-Control-Character-Map Configuration
format is shown below. The fields are transmitted from left
right
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACCM (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2
6
Simpson [Page 15]
RFC 1662 HDLC-like Framing July 1994
The ACCM field is four octets, and indicates the set of
characters to be mapped. The map is sent most significant
first
Each numbered bit corresponds to the octet of the same value.
the bit is cleared to zero, then that octet need not be mapped
If the bit is set to one, then that octet MUST remain mapped.
example, if bit 19 is set to zero, then the ASCII
character 19 (DC3, Control-S) MAY be sent in the clear
Note: The least significant bit of the least significant
(the final octet transmitted) is numbered bit 0, and would
to the ASCII control character NUL
Simpson [Page 16]
RFC 1662 HDLC-like Framing July 1994
A. Recommended LCP
The following Configurations Options are recommended
High Speed
Magic
Link Quality
No Address and Control Field
No Protocol Field
Low Speed or Asynchronous
Async Control Character
Magic
Address and Control Field
Protocol Field
B. Automatic Recognition of PPP
It is sometimes desirable to detect PPP frames, for example during
login sequence. The following octet sequences all begin valid
LCP frames
7e ff 03 c0 21
7e ff 7d 23 c0 21
7e 7d df 7d 23 c0 21
Note that the first two forms are not a valid username for Unix
However, only the third form generates a correctly checksummed
frame, whenever 03 and ff are taken as the control characters ETX
DEL without regard to parity (they are correct for an even
link) and discarded
Many implementations deal with this by putting the interface
packet mode when one of the above username patterns are
during login, without examining the initial PPP checksum.
initial incoming PPP frame is discarded, but a Configure-Request
sent immediately
Simpson [Page 17]
RFC 1662 HDLC-like Framing July 1994
C. Fast Frame Check Sequence (FCS)
The FCS was originally designed with hardware implementations
mind. A serial bit stream is transmitted on the wire, the FCS
calculated over the serial data as it goes out, and the complement
the resulting FCS is appended to the serial stream, followed by
Flag Sequence
The receiver has no way of determining that it has
calculating the received FCS until it detects the Flag Sequence
Therefore, the FCS was designed so that a particular pattern
when the FCS operation passes over the complemented FCS. A
frame is indicated by this "good FCS" value
C.1. FCS table
The following code creates the lookup table used to calculate
FCS-16.
/*
* Generate a FCS-16 table
*
* Drew D. Perkins at Carnegie Mellon University
*
* Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier
*/
/*
* The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16.
*/
#define P 0x8408
main()
{
register unsigned int b, v
register int i
printf("typedef unsigned short u16;\n");
printf("static u16 fcstab[256] = {");
for (b = 0; ; ) {
if (b % 8 == 0)
printf("\n");
v = b
for (i = 8; i--; )
Simpson [Page 18]
RFC 1662 HDLC-like Framing July 1994
v = v & 1 ? (v >> 1) ^ P : v >> 1;
printf("\t0x%04x", v & 0xFFFF);
if (++b == 256)
break
printf(",");
}
printf("\n};\n");
}
C.2. 16-bit FCS Computation
The following code provides a table lookup computation
calculating the Frame Check Sequence as data arrives at
interface. This implementation is based on [7], [8], and [9].
/*
* u16 represents an unsigned 16-bit number. Adjust the typedef
* your hardware
*/
typedef unsigned short u16;
/*
* FCS lookup table as calculated by the table generator
*/
static u16 fcstab[256] = {
0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf
0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e
0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd
0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c
0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb
0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a
0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff
0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e
Simpson [Page 19]
RFC 1662 HDLC-like Framing July 1994
0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd
0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c
0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb
0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a
0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
};
#define PPPINITFCS16 0xffff /* Initial FCS value */
#define PPPGOODFCS16 0xf0b8 /* Good final FCS value */
/*
* Calculate a new fcs given the current fcs and the new data
*/
u16 pppfcs16(fcs, cp, len
register u16 fcs
register unsigned char *cp
register int len
{
ASSERT(sizeof (u16) == 2);
ASSERT(((u16) -1) > 0);
while (len--)
fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
return (fcs);
}
/*
* How to use the
*/
tryfcs16(cp, len
register unsigned char *cp
register int len
{
u16 trialfcs
/* add on output */
trialfcs = pppfcs16( PPPINITFCS16, cp, len );
trialfcs ^= 0xffff; /* complement */
cp[len] = (trialfcs & 0x00ff); /* least significant byte first */
cp[len+1] = ((trialfcs >> 8) & 0x00ff);
Simpson [Page 20]
RFC 1662 HDLC-like Framing July 1994
/* check on input */
trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 );
if ( trialfcs == PPPGOODFCS16 )
printf("Good FCS\n");
}
C.3. 32-bit FCS Computation
The following code provides a table lookup computation
calculating the 32-bit Frame Check Sequence as data arrives at
interface
/*
* The FCS-32 generator polynomial: x**0 + x**1 + x**2 + x**4 + x**5
* + x**7 + x**8 + x**10 + x**11 + x**12 + x**16
* + x**22 + x**23 + x**26 + x**32.
*/
/*
* u32 represents an unsigned 32-bit number. Adjust the typedef
* your hardware
*/
typedef unsigned long u32;
static u32 fcstab_32[256] =
{
0x00000000, 0x77073096, 0xee0e612c, 0x990951ba
0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de
0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec
0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b
0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f
0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d
0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a
0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
Simpson [Page 21]
RFC 1662 HDLC-like Framing July 1994
0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e
0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c
0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb
0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f
0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad
0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a
0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe
0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc
0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b
0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f
0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d
0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a
0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e
0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c
0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db
0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf
0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8
};
#define PPPINITFCS32 0xffffffff /* Initial FCS value */
#define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */
Simpson [Page 22]
RFC 1662 HDLC-like Framing July 1994
/*
* Calculate a new FCS given the current FCS and the new data
*/
u32 pppfcs32(fcs, cp, len
register u32 fcs
register unsigned char *cp
register int len
{
ASSERT(sizeof (u32) == 4);
ASSERT(((u32) -1) > 0);
while (len--)
fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
return (fcs);
}
/*
* How to use the
*/
tryfcs32(cp, len
register unsigned char *cp
register int len
{
u32 trialfcs
/* add on output */
trialfcs = pppfcs32( PPPINITFCS32, cp, len );
trialfcs ^= 0xffffffff; /* complement */
cp[len] = (trialfcs & 0x00ff); /* least significant byte first */
cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
cp[len+3] = ((trialfcs >> 8) & 0x00ff);
/* check on input */
trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
if ( trialfcs == PPPGOODFCS32 )
printf("Good FCS\n");
}
Simpson [Page 23]
RFC 1662 HDLC-like Framing July 1994
Security
As noted in the Physical Layer Requirements section, the link
might not be informed when the connected state of the physical
has changed. This results in possible security lapses due to over
reliance on the integrity and security of switching systems
administrations. An insertion attack might be undetected.
attacker which is able to spoof the same calling identity might
able to avoid link authentication
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD 50, RFC 1661, Daydreamer, July 1994.
[2] ISO/IEC 3309:1991(E), "Information Technology -
Telecommunications and information exchange between systems -
High-level data link control (HDLC) procedures -
structure", International Organization For Standardization
Fourth edition 1991-06-01.
[3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology -
Telecommunications and information exchange between systems -
High-level data link control (HDLC) procedures -
structure - Amendment 2: Extended transparency options
start/stop transmission", International Organization
Standardization, 1992-01-15.
[4] ISO/IEC 4335:1991(E), "Information Technology -
Telecommunications and information exchange between systems -
High-level data link control (HDLC) procedures - Elements
procedures", International Organization For Standardization
Fourth edition 1991-09-15.
[5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
Daydreamer, January 1994.
[6] ANSI X3.4-1977, "American National Standard Code
Information Interchange", American National
Institute, 1977.
[7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983.
[8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte
September 1986.
Simpson [Page 24]
RFC 1662 HDLC-like Framing July 1994
[9] LeVan, J., "A Fast CRC", Byte, November 1987.
[10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
1340, USC/Information Sciences Institute, July 1992.
This document is the product of the Point-to-Point Protocol
Group of the Internet Engineering Task Force (IETF). Comments
be submitted to the ietf-ppp@merit.edu mailing list
This specification is based on previous RFCs, where
contributions have been acknowleged
The 32-bit FCS example code was provided by Karl Fox (Morning
Technologies).
Special thanks to Morning Star Technologies for providing
resources and network access support for writing this specification
Chair's
The working group can be contacted via the current chair
Fred
Advanced Computer
315 Bollay
Santa Barbara, California 93117
fbaker@acc.
Editor's
Questions about this memo can also be directed to
William Allen
Computer Systems Consulting
1384
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.
bsimpson@MorningStar.
Simpson [Page 25]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
