1441 lines
47 KiB
Plaintext
1441 lines
47 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group W. Simpson, Editor
|
||
Request for Comments: 1662 Daydreamer
|
||
STD: 51 July 1994
|
||
Obsoletes: 1549
|
||
Category: Standards Track
|
||
|
||
|
||
PPP in HDLC-like Framing
|
||
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
|
||
Abstract
|
||
|
||
The Point-to-Point Protocol (PPP) [1] provides a standard method for
|
||
transporting multi-protocol datagrams over point-to-point links.
|
||
|
||
This document describes the use of HDLC-like framing for PPP
|
||
encapsulated packets.
|
||
|
||
|
||
Table of Contents
|
||
|
||
|
||
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. Introduction
|
||
|
||
This specification provides for framing over both bit-oriented and
|
||
octet-oriented synchronous links, and asynchronous links with 8 bits
|
||
of data and no parity. These links MUST be full-duplex, but MAY be
|
||
either dedicated or circuit-switched.
|
||
|
||
An escape mechanism is specified to allow control data such as
|
||
XON/XOFF to be transmitted transparently over the link, and to remove
|
||
spurious control data which may be injected into the link by
|
||
intervening hardware and software.
|
||
|
||
Some protocols expect error free transmission, and either provide
|
||
error detection only on a conditional basis, or do not provide it at
|
||
all. PPP uses the HDLC Frame Check Sequence for error detection.
|
||
This is commonly available in hardware implementations, and a
|
||
software implementation is provided.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 1]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
1.1. Specification of Requirements
|
||
|
||
In this document, several words are used to signify the requirements
|
||
of the specification. These words are often capitalized.
|
||
|
||
MUST This word, or the adjective "required", means that the
|
||
definition is an absolute requirement of the specification.
|
||
|
||
MUST NOT This phrase means that the definition is an absolute
|
||
prohibition of the specification.
|
||
|
||
SHOULD This word, or the adjective "recommended", means that there
|
||
may exist valid reasons in particular circumstances to
|
||
ignore this item, but the full implications must be
|
||
understood and carefully weighed before choosing a
|
||
different course.
|
||
|
||
MAY This word, or the adjective "optional", means that this
|
||
item is one of an allowed set of alternatives. An
|
||
implementation which does not include this option MUST be
|
||
prepared to interoperate with another implementation which
|
||
does include the option.
|
||
|
||
|
||
1.2. Terminology
|
||
|
||
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 packets
|
||
passed to the data link layer.
|
||
|
||
frame The unit of transmission at the data link layer. A frame
|
||
may include a header and/or a trailer, along with some
|
||
number of units of data.
|
||
|
||
packet The basic unit of encapsulation, which is passed across the
|
||
interface between the network layer and the data link
|
||
layer. A packet is usually mapped to a frame; the
|
||
exceptions are when data link layer fragmentation is being
|
||
performed, or when multiple packets are incorporated into a
|
||
single frame.
|
||
|
||
peer The other end of the point-to-point link.
|
||
|
||
silently discard
|
||
The implementation discards the packet without further
|
||
processing. The implementation SHOULD provide the
|
||
capability of logging the error, including the contents of
|
||
the silently discarded packet, and SHOULD record the event
|
||
in a statistics counter.
|
||
|
||
|
||
Simpson [Page 2]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
2. Physical Layer Requirements
|
||
|
||
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 absolute
|
||
requirement imposed by PPP is the provision of a full-duplex circuit,
|
||
either dedicated or circuit-switched, which can operate in either an
|
||
asynchronous (start/stop), bit-synchronous, or octet-synchronous
|
||
mode, transparent to PPP Data Link Layer frames.
|
||
|
||
Interface Format
|
||
|
||
PPP presents an octet interface to the physical layer. There is
|
||
no provision for sub-octets to be supplied or accepted.
|
||
|
||
Transmission Rate
|
||
|
||
PPP does not impose any restrictions regarding transmission rate,
|
||
other than that of the particular DTE/DCE interface.
|
||
|
||
Control Signals
|
||
|
||
PPP does not require the use of control signals, such as Request
|
||
To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and
|
||
Data Terminal Ready (DTR).
|
||
|
||
When available, using such signals can allow greater functionality
|
||
and performance. In particular, such signals SHOULD be used to
|
||
signal the Up and Down events in the LCP Option Negotiation
|
||
Automaton [1]. When such signals are not available, the
|
||
implementation MUST signal the Up event to LCP upon
|
||
initialization, and SHOULD NOT signal the Down event.
|
||
|
||
Because signalling is not required, the physical layer MAY be
|
||
decoupled from the data link layer, hiding the transient details
|
||
of the physical transport. This has implications for mobility in
|
||
cellular radio networks, and other rapidly switching links.
|
||
|
||
When moving from cell to cell within the same zone, an
|
||
implementation MAY choose to treat the entire zone as a single
|
||
link, even though transmission is switched among several
|
||
frequencies. The link is considered to be with the central
|
||
control unit for the zone, rather than the individual cell
|
||
transceivers. However, the link SHOULD re-establish its
|
||
configuration whenever the link is switched to a different
|
||
administration.
|
||
|
||
Due to the bursty nature of data traffic, some implementations
|
||
have choosen to disconnect the physical layer during periods of
|
||
|
||
|
||
|
||
Simpson [Page 3]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
inactivity, and reconnect when traffic resumes, without informing
|
||
the data link layer. Robust implementations should avoid using
|
||
this trick over-zealously, since the price for decreased setup
|
||
latency is decreased security. Implementations SHOULD signal the
|
||
Down event whenever "significant time" has elapsed since the link
|
||
was disconnected. The value for "significant time" is a matter of
|
||
considerable debate, and is based on the tariffs, call setup
|
||
times, and security concerns of the installation.
|
||
|
||
|
||
|
||
3. The Data Link Layer
|
||
|
||
PPP uses the principles described in ISO 3309-1979 HDLC frame
|
||
structure, most recently the fourth edition 3309:1991 [2], which
|
||
specifies modifications to allow HDLC use in asynchronous
|
||
environments.
|
||
|
||
The PPP control procedures use the Control field encodings described
|
||
in ISO 4335-1979 HDLC elements of procedures, most recently the
|
||
fourth edition 4335:1991 [4].
|
||
|
||
This should not be construed to indicate that every feature of the
|
||
above recommendations are included in PPP. Each feature included
|
||
is explicitly described in the following sections.
|
||
|
||
To remain consistent with standard Internet practice, and avoid
|
||
confusion for people used to reading RFCs, all binary numbers in the
|
||
following descriptions are in Most Significant Bit to Least
|
||
Significant Bit order, reading from left to right, unless otherwise
|
||
indicated. Note that this is contrary to standard ISO and CCITT
|
||
practice which orders bits as transmitted (network bit order). Keep
|
||
this in mind when comparing this document with the international
|
||
standards documents.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 4]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
3.1. Frame Format
|
||
|
||
A summary of the PPP HDLC-like frame structure is shown below. This
|
||
figure does not include bits inserted for synchronization (such as
|
||
start and stop bits for asynchronous links), nor any bits or octets
|
||
inserted for transparency. The fields are transmitted from left to
|
||
right.
|
||
|
||
+----------+----------+----------+
|
||
| Flag | Address | Control |
|
||
| 01111110 | 11111111 | 00000011 |
|
||
+----------+----------+----------+
|
||
+----------+-------------+---------+
|
||
| Protocol | Information | Padding |
|
||
| 8/16 bits| * | * |
|
||
+----------+-------------+---------+
|
||
+----------+----------+-----------------
|
||
| FCS | Flag | Inter-frame Fill
|
||
|16/32 bits| 01111110 | or next Address
|
||
+----------+----------+-----------------
|
||
|
||
The Protocol, Information and Padding fields are described in the
|
||
Point-to-Point Protocol Encapsulation [1].
|
||
|
||
Flag Sequence
|
||
|
||
Each frame begins and ends with a Flag Sequence, which is the
|
||
binary sequence 01111110 (hexadecimal 0x7e). All implementations
|
||
continuously check for this flag, which is used for frame
|
||
synchronization.
|
||
|
||
Only one Flag Sequence is required between two frames. Two
|
||
consecutive Flag Sequences constitute an empty frame, which is
|
||
silently discarded, and not counted as a FCS error.
|
||
|
||
Address Field
|
||
|
||
The Address field is a single octet, which contains the binary
|
||
sequence 11111111 (hexadecimal 0xff), the All-Stations address.
|
||
Individual station addresses are not assigned. The All-Stations
|
||
address MUST always be recognized and received.
|
||
|
||
The use of other address lengths and values may be defined at a
|
||
later time, or by prior agreement. Frames with unrecognized
|
||
Addresses SHOULD be silently discarded.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 5]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
Control Field
|
||
|
||
The Control field is a single octet, which contains the binary
|
||
sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
|
||
(UI) command with the Poll/Final (P/F) bit set to zero.
|
||
|
||
The use of other Control field values may be defined at a later
|
||
time, or by prior agreement. Frames with unrecognized Control
|
||
field values SHOULD be silently discarded.
|
||
|
||
Frame Check Sequence (FCS) Field
|
||
|
||
The Frame Check Sequence field defaults to 16 bits (two octets).
|
||
The FCS is transmitted least significant octet first, which
|
||
contains the coefficient of the highest term.
|
||
|
||
A 32-bit (four octet) FCS is also defined. Its use may be
|
||
negotiated as described in "PPP LCP Extensions" [5].
|
||
|
||
The use of other FCS lengths may be defined at a later time, or by
|
||
prior agreement.
|
||
|
||
The FCS field is calculated over all bits of the Address, Control,
|
||
Protocol, Information and Padding fields, not including any start
|
||
and stop bits (asynchronous) nor any bits (synchronous) or octets
|
||
(asynchronous or synchronous) inserted for transparency. This
|
||
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 calculating
|
||
the FCS.
|
||
|
||
For more information on the specification of the FCS, see the
|
||
Appendices.
|
||
|
||
The end of the Information and Padding fields is found by locating
|
||
the closing Flag Sequence and removing the Frame Check Sequence
|
||
field.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 6]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
3.2. Modification of the Basic Frame
|
||
|
||
The Link Control Protocol can negotiate modifications to the standard
|
||
HDLC-like frame structure. However, modified frames will always be
|
||
clearly distinguishable from standard frames.
|
||
|
||
Address-and-Control-Field-Compression
|
||
|
||
When using the standard HDLC-like framing, the Address and Control
|
||
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 simply
|
||
omitted.
|
||
|
||
On reception, the Address and Control fields are decompressed by
|
||
examining the first two octets. If they contain the values 0xff
|
||
and 0x03, they are assumed to be the Address and Control fields.
|
||
If not, it is assumed that the fields were compressed and were not
|
||
transmitted.
|
||
|
||
By definition, the first octet of a two octet Protocol field
|
||
will never be 0xff (since it is not even). The Protocol field
|
||
value 0x00ff is not allowed (reserved) to avoid ambiguity when
|
||
Protocol-Field-Compression is enabled and the first Information
|
||
field octet is 0x03.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 7]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
4. Octet-stuffed framing
|
||
|
||
This chapter summarizes the use of HDLC-like framing with 8-bit
|
||
asynchronous and octet-synchronous links.
|
||
|
||
|
||
|
||
4.1. Flag Sequence
|
||
|
||
The Flag Sequence indicates the beginning or end of a frame. The
|
||
octet stream is examined on an octet-by-octet basis for the value
|
||
01111110 (hexadecimal 0x7e).
|
||
|
||
|
||
|
||
4.2. Transparency
|
||
|
||
An octet stuffing procedure is used. The Control Escape octet is
|
||
defined as binary 01111101 (hexadecimal 0x7d), most significant bit
|
||
first.
|
||
|
||
As a minimum, sending implementations MUST escape the Flag Sequence
|
||
and Control Escape octets.
|
||
|
||
After FCS computation, the transmitter examines the entire frame
|
||
between the two Flag Sequences. Each Flag Sequence, Control Escape
|
||
octet, and any octet which is flagged in the sending Async-Control-
|
||
Character-Map (ACCM), is replaced by a two octet sequence consisting
|
||
of the Control Escape octet followed by the original octet
|
||
exclusive-or'd with hexadecimal 0x20.
|
||
|
||
This is bit 5 complemented, where the bit positions are numbered
|
||
76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE
|
||
when comparing documents).
|
||
|
||
Receiving implementations MUST correctly process all Control Escape
|
||
sequences.
|
||
|
||
On reception, prior to FCS computation, each octet with value less
|
||
than hexadecimal 0x20 is checked. If it is flagged in the receiving
|
||
ACCM, it is simply removed (it may have been inserted by intervening
|
||
data communications equipment). Each Control Escape octet is also
|
||
removed, and the following octet is exclusive-or'd with hexadecimal
|
||
0x20, unless it is the Flag Sequence (which aborts a frame).
|
||
|
||
A few examples may make this more clear. Escaped data is transmitted
|
||
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 and
|
||
DC3 ignoring the 8th (parity) bit. This data would be transmitted on
|
||
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
|
||
|
||
Frames which are too short (less than 4 octets when using the 16-bit
|
||
FCS), or which end with a Control Escape octet followed immediately
|
||
by a closing Flag Sequence, or in which octet-framing is violated (by
|
||
transmitting a "0" stop bit where a "1" bit is expected), are
|
||
silently discarded, and not counted as a FCS error.
|
||
|
||
|
||
|
||
4.4. Time Fill
|
||
|
||
4.4.1. Octet-synchronous
|
||
|
||
There is no provision for inter-octet time fill.
|
||
|
||
The Flag Sequence MUST be transmitted during inter-frame time fill.
|
||
|
||
|
||
4.4.2. Asynchronous
|
||
|
||
Inter-octet time fill MUST be accomplished by transmitting continuous
|
||
"1" bits (mark-hold state).
|
||
|
||
Inter-frame time fill can be viewed as extended inter-octet time
|
||
fill. Doing so can save one octet for every frame, decreasing delay
|
||
and increasing bandwidth. This is possible since a Flag Sequence may
|
||
serve as both a frame end and a frame begin. After having received
|
||
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. Noisy
|
||
links may cause the receiver to receive garbage characters and
|
||
interpret them as part of an incoming frame. If the transmitter does
|
||
not send a new opening Flag Sequence before sending the next frame,
|
||
then that frame will be appended to the noise characters causing an
|
||
invalid frame (with high reliability).
|
||
|
||
It is suggested that implementations will achieve the best results by
|
||
always sending an opening Flag Sequence if the new frame is not
|
||
back-to-back with the last. Transmitters SHOULD send an open Flag
|
||
Sequence whenever "appreciable time" has elapsed after the prior
|
||
closing Flag Sequence. The maximum value for "appreciable time" is
|
||
likely to be no greater than the typing rate of a slow typist, about
|
||
1 second.
|
||
|
||
|
||
|
||
4.5. Transmission Considerations
|
||
|
||
4.5.1. Octet-synchronous
|
||
|
||
The definition of various encodings and scrambling is the
|
||
responsibility of the DTE/DCE equipment in use, and is outside the
|
||
scope of this specification.
|
||
|
||
|
||
4.5.2. Asynchronous
|
||
|
||
All octets are transmitted least significant bit first, with one
|
||
start bit, eight bits of data, and one stop bit. There is no
|
||
provision for seven bit asynchronous links.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 10]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
5. Bit-stuffed framing
|
||
|
||
This chapter summarizes the use of HDLC-like framing with bit-
|
||
synchronous links.
|
||
|
||
|
||
|
||
5.1. Flag Sequence
|
||
|
||
The Flag Sequence indicates the beginning or end of a frame, and is
|
||
used for frame synchronization. The bit stream is examined on a
|
||
bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e).
|
||
|
||
The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be
|
||
used. When not avoidable, such an implementation MUST ensure that
|
||
the first Flag Sequence detected (the end of the frame) is promptly
|
||
communicated to the link layer. Use of the shared zero mode hinders
|
||
interoperability with bit-synchronous to asynchronous and bit-
|
||
synchronous to octet-synchronous converters.
|
||
|
||
|
||
|
||
5.2. Transparency
|
||
|
||
After FCS computation, the transmitter examines the entire frame
|
||
between the two Flag Sequences. A "0" bit is inserted after all
|
||
sequences of five contiguous "1" bits (including the last 5 bits of
|
||
the FCS) to ensure that a Flag Sequence is not simulated.
|
||
|
||
On reception, prior to FCS computation, any "0" bit that directly
|
||
follows five contiguous "1" bits is discarded.
|
||
|
||
|
||
|
||
5.3. Invalid Frames
|
||
|
||
Frames which are too short (less than 4 octets when using the 16-bit
|
||
FCS), or which end with a sequence of more than six "1" bits, are
|
||
silently discarded, and not counted as a FCS error.
|
||
|
||
|
||
|
||
5.4. Time Fill
|
||
|
||
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 of
|
||
|
||
|
||
|
||
Simpson [Page 11]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
mark idle (continuous ones), particularly those that calculate
|
||
accounting based on periods of bit activity. When mark idle is used
|
||
on a bit-synchronous link, the implementation MUST ensure at least 15
|
||
consecutive "1" bits between Flags during the idle period, and that
|
||
the Flag Sequence is always generated at the beginning of a frame
|
||
after an idle period.
|
||
|
||
This differs from practice in ISO 3309, which allows 7 to 14 bit
|
||
mark idle.
|
||
|
||
|
||
|
||
5.5. Transmission Considerations
|
||
|
||
All octets are transmitted least significant bit first.
|
||
|
||
The definition of various encodings and scrambling is the
|
||
responsibility of the DTE/DCE equipment in use, and is outside the
|
||
scope of this specification.
|
||
|
||
While PPP will operate without regard to the underlying
|
||
representation of the bit stream, lack of standards for transmission
|
||
will hinder interoperability as surely as lack of data link
|
||
standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently
|
||
most widely available, and on that basis is recommended as a default.
|
||
|
||
When configuration of the encoding is allowed, NRZI is recommended as
|
||
an alternative, because of its relative immunity to signal inversion
|
||
configuration errors, and instances when it MAY allow connection
|
||
without an expensive DSU/CSU. Unfortunately, NRZI encoding
|
||
exacerbates the missing x1 factor of the 16-bit FCS, so that one
|
||
error in 2**15 goes undetected (instead of one in 2**16), and triple
|
||
errors are not detected. Therefore, when NRZI is in use, it is
|
||
recommended that the 32-bit FCS be negotiated, which includes the x1
|
||
factor.
|
||
|
||
At higher speeds of up to 45 Mbps, some implementors have chosen the
|
||
ANSI High Speed Synchronous Interface [HSSI]. While this experience
|
||
is currently limited, implementors are encouraged to cooperate in
|
||
choosing transmission encoding.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 12]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
6. Asynchronous to Synchronous Conversion
|
||
|
||
There may be some use of asynchronous-to-synchronous converters (some
|
||
built into modems and cellular interfaces), resulting in an
|
||
asynchronous PPP implementation on one end of a link and a
|
||
synchronous implementation on the other. It is the responsibility of
|
||
the converter to do all stuffing conversions during operation.
|
||
|
||
To enable this functionality, synchronous PPP implementations MUST
|
||
always respond to the Async-Control-Character-Map Configuration
|
||
Option with the LCP Configure-Ack. However, acceptance of the
|
||
Configuration Option does not imply that the synchronous
|
||
implementation will do any ACCM mapping. Instead, all such octet
|
||
mapping will be performed by the asynchronous-to-synchronous
|
||
converter.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 13]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
7. Additional LCP Configuration Options
|
||
|
||
The Configuration Option format and basic options are already defined
|
||
for LCP [1].
|
||
|
||
Up-to-date values of the LCP Option Type field are specified in the
|
||
most recent "Assigned Numbers" RFC [10]. This document concerns the
|
||
following values:
|
||
|
||
2 Async-Control-Character-Map
|
||
|
||
|
||
|
||
|
||
7.1. Async-Control-Character-Map (ACCM)
|
||
|
||
Description
|
||
|
||
This Configuration Option provides a method to negotiate the use
|
||
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 sending
|
||
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 Escape
|
||
and Flag Sequence characters themselves, plus whatever other
|
||
outgoing characters are flagged (by prior configuration) as likely
|
||
to be intercepted.
|
||
|
||
For other types of links, the default value is 0, since there is
|
||
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 data
|
||
communications equipment.
|
||
|
||
The transmitter MAY also send octets with values in the range 0x40
|
||
through 0xff (except 0x5e) in Control Escape format. Since these
|
||
octet values are not negotiable, this does not solve the problem
|
||
of receivers which cannot handle all non-control characters.
|
||
Also, since the technique does not affect the 8th bit, this does
|
||
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 later
|
||
amendments, such as 3309:1991/Amendment 2 [3]. However, such
|
||
"extended transparency" is applied only by "prior agreement".
|
||
Use of the transparency methods in this specification
|
||
constitute a prior agreement with respect to PPP.
|
||
|
||
For compatibility with 3309:1991/Amendment 2, the transmitter
|
||
MAY escape DEL and ACCM equivalents with the 8th (most
|
||
significant) bit set. No change is required in the receiving
|
||
algorithm.
|
||
|
||
Following ACCM negotiation, the transmitter SHOULD cease
|
||
escaping DEL.
|
||
|
||
However, it is rarely necessary to map all control characters, and
|
||
often it is unnecessary to map any control characters. The
|
||
Configuration Option is used to inform the peer which control
|
||
characters MUST remain mapped when the peer sends them.
|
||
|
||
The peer MAY still send any other octets in mapped format, if it
|
||
is necessary because of constraints known to the peer. The peer
|
||
SHOULD Configure-Nak with the logical union of the sets of mapped
|
||
octets, so that when such octets are spuriously introduced they
|
||
can be ignored on receipt.
|
||
|
||
A summary of the Async-Control-Character-Map Configuration Option
|
||
format is shown below. The fields are transmitted from left to
|
||
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
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
ACCM (cont) |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
|
||
Type
|
||
|
||
2
|
||
|
||
Length
|
||
|
||
6
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 15]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
ACCM
|
||
|
||
The ACCM field is four octets, and indicates the set of control
|
||
characters to be mapped. The map is sent most significant octet
|
||
first.
|
||
|
||
Each numbered bit corresponds to the octet of the same value. If
|
||
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. For
|
||
example, if bit 19 is set to zero, then the ASCII control
|
||
character 19 (DC3, Control-S) MAY be sent in the clear.
|
||
|
||
Note: The least significant bit of the least significant octet
|
||
(the final octet transmitted) is numbered bit 0, and would map
|
||
to the ASCII control character NUL.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 16]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
A. Recommended LCP Options
|
||
|
||
The following Configurations Options are recommended:
|
||
|
||
High Speed links
|
||
|
||
Magic Number
|
||
Link Quality Monitoring
|
||
No Address and Control Field Compression
|
||
No Protocol Field Compression
|
||
|
||
|
||
Low Speed or Asynchronous links
|
||
|
||
Async Control Character Map
|
||
Magic Number
|
||
Address and Control Field Compression
|
||
Protocol Field Compression
|
||
|
||
|
||
|
||
B. Automatic Recognition of PPP Frames
|
||
|
||
It is sometimes desirable to detect PPP frames, for example during a
|
||
login sequence. The following octet sequences all begin valid PPP
|
||
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 PPP
|
||
frame, whenever 03 and ff are taken as the control characters ETX and
|
||
DEL without regard to parity (they are correct for an even parity
|
||
link) and discarded.
|
||
|
||
Many implementations deal with this by putting the interface into
|
||
packet mode when one of the above username patterns are detected
|
||
during login, without examining the initial PPP checksum. The
|
||
initial incoming PPP frame is discarded, but a Configure-Request is
|
||
sent immediately.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 17]
|
||
RFC 1662 HDLC-like Framing July 1994
|
||
|
||
|
||
C. Fast Frame Check Sequence (FCS) Implementation
|
||
|
||
The FCS was originally designed with hardware implementations in
|
||
mind. A serial bit stream is transmitted on the wire, the FCS is
|
||
calculated over the serial data as it goes out, and the complement of
|
||
the resulting FCS is appended to the serial stream, followed by the
|
||
Flag Sequence.
|
||
|
||
The receiver has no way of determining that it has finished
|
||
calculating the received FCS until it detects the Flag Sequence.
|
||
Therefore, the FCS was designed so that a particular pattern results
|
||
when the FCS operation passes over the complemented FCS. A good
|
||
frame is indicated by this "good FCS" value.
|
||
|
||
|
||
|
||
C.1. FCS table generator
|
||
|
||
The following code creates the lookup table used to calculate the
|
||
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 Method
|
||
|
||
The following code provides a table lookup computation for
|
||
calculating the Frame Check Sequence as data arrives at the
|
||
interface. This implementation is based on [7], [8], and [9].
|
||
|
||
/*
|
||
* u16 represents an unsigned 16-bit number. Adjust the typedef for
|
||
* 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 fcs
|
||
*/
|
||
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 Method
|
||
|
||
The following code provides a table lookup computation for
|
||
calculating the 32-bit Frame Check Sequence as data arrives at the
|
||
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 for
|
||
* 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, 0x2d02ef8d
|
||
};
|
||
|
||
#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 fcs
|
||
*/
|
||
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 Considerations
|
||
|
||
As noted in the Physical Layer Requirements section, the link layer
|
||
might not be informed when the connected state of the physical layer
|
||
has changed. This results in possible security lapses due to over-
|
||
reliance on the integrity and security of switching systems and
|
||
administrations. An insertion attack might be undetected. An
|
||
attacker which is able to spoof the same calling identity might be
|
||
able to avoid link authentication.
|
||
|
||
|
||
|
||
References
|
||
|
||
[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 - Frame
|
||
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 - Frame
|
||
structure - Amendment 2: Extended transparency options for
|
||
start/stop transmission", International Organization For
|
||
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 of
|
||
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 for
|
||
Information Interchange", American National Standards
|
||
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, RFC
|
||
1340, USC/Information Sciences Institute, July 1992.
|
||
|
||
|
||
|
||
Acknowledgements
|
||
|
||
This document is the product of the Point-to-Point Protocol Working
|
||
Group of the Internet Engineering Task Force (IETF). Comments should
|
||
be submitted to the ietf-ppp@merit.edu mailing list.
|
||
|
||
This specification is based on previous RFCs, where many
|
||
contributions have been acknowleged.
|
||
|
||
The 32-bit FCS example code was provided by Karl Fox (Morning Star
|
||
Technologies).
|
||
|
||
Special thanks to Morning Star Technologies for providing computing
|
||
resources and network access support for writing this specification.
|
||
|
||
|
||
|
||
Chair's Address
|
||
|
||
The working group can be contacted via the current chair:
|
||
|
||
Fred Baker
|
||
Advanced Computer Communications
|
||
315 Bollay Drive
|
||
Santa Barbara, California 93117
|
||
|
||
fbaker@acc.com
|
||
|
||
|
||
Editor's Address
|
||
|
||
Questions about this memo can also be directed to:
|
||
|
||
William Allen Simpson
|
||
Daydreamer
|
||
Computer Systems Consulting Services
|
||
1384 Fontaine
|
||
Madison Heights, Michigan 48071
|
||
|
||
Bill.Simpson@um.cc.umich.edu
|
||
bsimpson@MorningStar.com
|
||
|
||
|
||
Simpson [Page 25]
|
||
|
||
|
||
|
||
|
||
|