+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
5 for Terminate-Request;
6 for Terminate-Ack.
Identifier
The Identifier field is one octet and aids in matching requests
and replies.
Data
The Data field is zero or more octets and contains uninterpreted
data for use by the sender. The data may consist of any binary
value and may be of any length from zero to the established value
for the peer's MRU.
4.3.6. Code-Reject
Description
Reception of a LCP packet with an unknown Code indicates that one
of the communicating LCP implementations is faulty or incomplete.
This error MUST be reported back to the sender of the unknown Code
by transmitting a LCP packet with the Code field set to 7 (Code-
Reject), and the inducing packet copied to the Rejected-Packet
field.
Upon reception of a Code-Reject, a LCP implementation should make
an immediate transition to the Closed state, and should report the
error, since it is unlikely that the situation can be rectified
automatically.
A summary of the Code-Reject packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Packet ...
+-+-+-+-+-+-+-+-+
Code
7 for Code-Reject.
Identifier
The Identifier field is one octet and is for use by the
transmitter.
Rejected-Packet
The Rejected-Packet field contains a copy of the LCP packet which
is being rejected. It begins with the rejected Code field; it
does not include any PPP Data Link Layer headers. The Rejected-
Packet should be truncated to comply with the established value of
the peer's MRU.
4.3.7. Protocol-Reject
Description
Reception of a PPP frame with an unknown Data Link Layer Protocol
indicates that the remote end is attempting to use a protocol
which is unsupported at the local end. This typically occurs when
the remote end attempts to configure a new, but unsupported
protocol. If the LCP state machine is in the Open state, then
this error MUST be reported back to the sender of the unknown
protocol by transmitting a LCP packet with the Code field set to 8
(Protocol-Reject), the Rejected-Protocol field set to the received
Protocol, and the Data field filled with any desired data.
Upon reception of a Protocol-Reject, a LCP implementation should
stop transmitting frames of the indicated protocol.
Protocol-Reject packets may only be sent in the LCP Open state.
Protocol-Reject packets received in any state other than the LCP
Open state should be discarded and no further action should be
taken.
A summary of the Protocol-Reject packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Protocol | Rejected-Information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
8 for Protocol-Reject.
Identifier
The Identifier field is one octet and is for use by the
transmitter.
Rejected-Protocol
The Rejected-Protocol field is two octets and contains the
Protocol of the Data Link Layer frame which is being rejected.
Rejected-Information
The Rejected-Information field contains a copy from the frame
which is being rejected. It begins with the Information field,
and does not include any PPP Data Link Layer headers or the FCS.
The Rejected-Information field should be truncated to comply with
the established value of the peer's MRU.
4.3.8. Echo-Request and Echo-Reply
Description
LCP includes Echo-Request and Echo-Reply Codes in order to provide
a Data Link Layer loopback mechanism for use in exercising both
directions of the link. This is useful as an aid in debugging,
link quality determination, performance testing, and for numerous
other functions.
An Echo-Request sender transmits a LCP packet with the Code field
set to 9 (Echo-Request) and the Data field filled with any desired
data, up to but not exceeding the receivers established MRU.
Upon reception of an Echo-Request, a LCP packet MUST be
transmitted with the Code field set to 10 (Echo-Reply), the
Identifier field copied from the received Echo-Request, and the
Data field copied from the Echo-Request, truncating as necessary
to avoid exceeding the peer's established MRU.
Echo-Request and Echo-Reply packets may only be sent in the LCP
Open state. Echo-Request and Echo-Reply packets received in any
state other than the LCP Open state should be discarded and no
further action should be taken.
A summary of the Echo-Request and Echo-Reply packet formats 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
9 for Echo-Request;
10 for Echo-Reply.
Identifier
The Identifier field is one octet and aids in matching Echo-
Requests and Echo-Replies.
Magic-Number
The Magic-Number field is four octets and aids in detecting
loopbacked links. Unless modified by a Configuration Option, the
Magic-Number MUST always be transmitted as zero and MUST always be
ignored on reception. Further use of the Magic-Number is beyond
the scope of this discussion.
Data
The Data field is zero or more octets and contains uninterpreted
data for use by the sender. The data may consist of any binary
value and may be of any length from zero to the established value
for the peer's MRU.
4.3.9. Discard-Request
Description
LCP includes a Discard-Request Code in order to provide a Data
Link Layer data sink mechanism for use in exercising the local to
remote direction of the link. This is useful as an aid in
debugging, performance testing, and and for numerous other
functions.
A discard sender transmits a LCP packet with the Code field set to
11 (Discard-Request) and the Data field filled with any desired
data, up to but not exceeding the receivers established MRU.
A discard receiver MUST simply throw away an Discard-Request that
it receives.
Discard-Request packets may only be sent in the LCP Open state.
A summary of the Discard-Request packet formats 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
11 for Discard-Request.
Identifier
The Identifier field is one octet and is for use by the Discard-
Request transmitter.
Magic-Number
The Magic-Number field is four octets and aids in detecting
loopbacked links. Unless modified by a configuration option, the
Magic-Number MUST always be transmitted as zero and MUST always be
ignored on reception. Further use of the Magic-Number is beyond
the scope of this discussion.
Data
The Data field is zero or more octets and contains uninterpreted
data for use by the sender. The data may consist of any binary
value and may be of any length from zero to the established value
for the peer's MRU.
4.4. Configuration Options
LCP Configuration Options allow modifications to the standard
characteristics of a point-to-point link to be negotiated.
Negotiable modifications include such things as the maximum receive
unit, async control character mapping, the link authentication
method, the link encryption method, etc.. The Configuration Options
themselves are described in separate documents. If a Configuration
Option is not included in a Configure-Request packet, the default
value for that Configuration Option is assumed.
The end of the list of Configuration Options is indicated by the end
of the LCP packet.
Unless otherwise specified, a specific Configuration Options should
be listed no more than once in a Configuration Options list.
Specific Configuration Options may override this general rule and may
be listed more than once. The effect of this is Configuration Option
specific and is specified by each such Configuration Option.
Also unless otherwise specified, all Configuration Options apply in a
half-duplex fashion. When negotiated, they apply to only one
direction of the link, typically in the receive direction when
interpreted from the point of view of the Configure-Request sender.
4.4.1. Format
A summary of the Configuration Option format is shown below. The
fields are transmitted from left to right.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
The Type field is one octet and indicates the type of
Configuration Option. The most up-to-date values of the Type
field are specified in the most recent "Assigned Numbers" RFC
[11].
Length
The Length field is one octet and indicates the length of this
Configuration Option including the Type, Length and Data fields.
If a negotiable Configuration Option is received in a Configure-
Request but with an invalid Length, a Configure-Nak should be
transmitted which includes the desired Configuration Option with
an appropriate Length and Data.
Data
The Data field is zero or more octets and indicates the value or
other information for this Configuration Option. The format and
length of the Data field is determined by the Type and Length
fields.
5. A PPP Network Control Protocol (NCP) for IP
The IP Control Protocol (IPCP) is responsible for configuring,
enabling, and disabling the IP protocol modules on both ends of the
point-to-point link. As with the Link Control Protocol, this is
accomplished through an exchange of packets. IPCP packets may not be
exchanged until LCP has reached the network-layer Protocol
Configuration Negotiation phase. Likewise, IP datagrams may not be
exchanged until IPCP has first opened the connection.
The IP Control Protocol is exactly the same as the Link Control
Protocol with the following exceptions:
Data Link Layer Protocol Field
Exactly one IP Control Protocol packet is encapsulated in the
Information field of PPP Data Link Layer frames where the Protocol
field indicates type hex 8021 (IP Control Protocol).
Code field
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
and Code-Reject) are used. Other Codes should be treated as
unrecognized and should result in Code-Rejects.
Timeouts
IPCP packets may not be exchanged until the Link Control Protocol
has reached the network-layer Protocol Configuration Negotiation
phase. An implementation should be prepared to wait for Link
Quality testing to finish before timing out waiting for a
Configure-Ack or other response. It is suggested that an
implementation give up only after user intervention or a
configurable amount of time.
Configuration Option Types
The IPCP has a separate set of Configuration Options. The most
up-to-date values of the type field are specified in the most
recent "Assigned Numbers" RFC[11].
5.1. Sending IP Datagrams
Before any IP packets may be communicated, both the Link Control
Protocol and the IP Control Protocol must reach the Open state.
Exactly one IP packet is encapsulated in the Information field of PPP
Data Link Layer frames where the Protocol field indicates type hex
0021 (Internet Protocol).
The maximum length of an IP packet transmitted over a PPP link is the
same as the maximum length of the Information field of a PPP data
link layer frame. Larger IP datagrams must be fragmented as
necessary. If a system wishes to avoid fragmentation and reassembly,
it should use the TCP Maximum Segment Size option [12], or a similar
mechanism, to discourage others from sending large datagrams.
A. Asynchronous HDLC
This appendix summarizes the modifications to ISO 3309-1979 proposed
in ISO 3309:1984/PDAD1. These modifications allow HDLC to be used
with 8-bit asynchronous links.
Transmission Considerations
Each octet is delimited by a start and a stop element.
Flag Sequence
The Flag Sequence is a single octet and indicates the beginning or
end of a frame. The Flag Sequence consists of the binary sequence
01111110 (hexadecimal 0x7e).
Transparency
On asynchronous links, a character stuffing procedure is used.
The Control Escape octet is defined as binary 01111101
(hexadecimal 0x7d) where the bit positions are numbered 87654321
(not 76543210, BEWARE).
After FCS computation, the transmitter examines the entire frame
between the two Flag Sequences. Each Flag Sequence, Control
Escape octet and octet with value less than hexadecimal 0x20 is
replaced by a two character sequence consisting of the Control
Escape octet and the original octet with bit 6 complemented (i.e.,
exclusive-or'd with hexadecimal 0x20).
Prior to FCS computation, the receiver examines the entire frame
between the two Flag Sequences. For each Control Escape octet,
that octet is removed and bit 6 of the following octet is
complemented. A Control Escape octet immediately preceding the
closing Flag Sequence indicates an invalid frame.
Note: The inclusion of all octets less than hexadecimal 0x20
allows all ASCII control characters [10] excluding DEL (Delete)
to be transparently communicated through almost all known data
communications equipment.
A few examples may make this more clear. Packet data is
transmitted on the link as follows:
0x7e is encoded as 0x7d, 0x5e.
0x7d is encoded as 0x7d, 0x5d.
0x01 is encoded as 0x7d, 0x21.
Aborting a Transmission
On asynchronous links, frames may be aborted by transmitting a "0"
stop bit where a "1" bit is expected (framing error) or by
transmitting a Control Escape octet followed immediately by a
closing Flag Sequence.
Inter-frame Time Fill
On asynchronous links, inter-octet and inter-frame time fill
should be accomplished by transmitting continuous "1" bits (mark-
hold state).
Note: On asynchronous links, 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 close and a frame begin. After having received
any frame, an idle receiver will always be in a frame begin
state.
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 transmit 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). Transmitters should avoid this by
transmitting an open Flag Sequence whenever "appreciable time"
has elapsed since the prior closing Flag Sequence. 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. The maximum value for "appreciable
time" is likely to be no greater than the typing rate of a slow
to average typist, say 1 second.
B. Fast Frame Check Sequence (FCS) Implementation
B.1. FCS Computation Method
The following code provides a table lookup computation for
calculating the Frame Check Sequence as data arrives at the
interface. The table is created by the code in section 2.
/*
* FCS lookup table as calculated by the table generator in section 2.
*/
static unsigned short 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,
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 PPPINITFCS 0xffff /* Initial FCS value */
#define PPPGOODFCS 0xf0b8 /* Good final FCS value */
/*
* Calculate a new fcs given the current fcs and the new data.
*/
unsigned short pppfcs(fcs, cp, len)
register unsigned short fcs;
register unsigned char *cp;
register int len;
{
while (len--)
fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
return (fcs);
}
B.2. Fast FCS table generator
The following code creates the lookup table used to calculate the
FCS.
/*
* Generate a FCS table for the HDLC FCS.
*
* Drew D. Perkins at Carnegie Mellon University.
*
* Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
*/
/*
* The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408).
*/
#define P 0x8408
main()
{
register unsigned int b, v;
register int i;
printf("static unsigned short fcstab[256] = {");
for (b = 0; ; ) {
if (b % 8 == 0)
printf("0);
v = b;
for (i = 8; i--; )
v = v & 1 ? (v >> 1) ^ P : v >> 1;
printf("0x%04x", v & 0xFFFF);
if (++b == 256)
break;
printf(",");
}
printf("0;0);
}
References
[1] Electronic Industries Association, "Interface Between Data
Terminal Equipment and Data Communications Equipment Employing
Serial Binary Data Interchange", EIA Standard RS-232-C, August
1969.
[2] International Organization For Standardization, "Data
Communication - High-level Data Link Control Procedures - Frame
Structure", ISO Standard 3309-1979, 1979.
[3] International Organization For Standardization, "Data
Communication - High-level Data Link Control Procedures -
Elements of Procedures", ISO Standard 4335-1979, 1979.
[4] International Organization For Standardization, "Data
Communication - High-Level Data Link Control Procedures -
Elements of Procedures - Addendum 1", ISO Standard 4335-
1979/Addendum 1, 1979.
[5] International Organization For Standardization, "Information
Processing Systems - Data Communication - High-level Data Link
Control Procedures - Frame structure - Addendum 1: Start/stop
Transmission", Proposed Draft International Standard ISO
3309:1983/PDAD1, 1984.
[6] International Telecommunication Union, CCITT Recommendation X.25,
"Interface Between Data Terminal Equipment (DTE) and Data Circuit
Terminating Equipment (DCE) for Terminals Operating in the Packet
Mode on Public Data Networks", CCITT Red Book, Volume VIII,
Fascicle VIII.3, Rec. X.25., October 1984.
[7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983.
Morse, G., "Calculating CRC's by Bits and Bytes", Byte, September
1986.
[8] LeVan, J., "A Fast CRC", Byte, November 1987.
[9] American National Standards Institute, "American National
Standard Code for Information Interchange", ANSI X3.4-1977, 1977.
[10] Postel, J., "Internet Protocol", RFC791, USC/Information
Sciences Institute, September 1981.
[11] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC1010,
USC/Information Sciences Institute, May 1987.
[12] Postel, J., "The TCP Maximum Segment Size Option and Related
Topics", RFC879, USC/Information Sciences Institute, November
1983.
Security Considerations
Security issues are not addressed in this memo.
Author's Address
This proposal is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). The working
group can be contacted via the chair:
Russ Hobby
UC Davis
Computing Services
Davis, CA 95616
Phone: (916) 752-0236
EMail: rdhobby@ucdavis.edu
Acknowledgments
Many people spent significant time helping to develop the Point-to-
Point Protocol. The complete list of people is too numerous to list,
but the following people deserve special thanks: Ken Adelman (TGV),
Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David
Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun
Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz
(cisco systems) and Asher Waldfogel (Wellfleet).