📄 rfc1171.txt
字号:
Perkins [Page 4]
RFC 1171 Point-to-Point Protocol July 1990
3.1. Frame Format
A summary of the standard PPP frame structure is shown below. The
fields are transmitted from left to right.
+----------+----------+----------+----------+------------
| Flag | Address | Control | Protocol | Information
| 01111110 | 11111111 | 00000011 | 16 bits | *
+----------+----------+----------+----------+------------
---+---------+----------+
| FCS | Flag |
| 16 bits | 01111110 |
---+---------+----------+
This figure does not include start/stop bits (for asynchronous links)
or any bits or octets inserted for transparency. When asynchronous
links are used, all octets are transmitted with one start bit, eight
bits of data, and one stop bit. There is no provision in either PPP
or ISO 3309:1984/PDAD1 for seven bit asynchronous links.
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 (i.e., network bit order).
Keep this in mind when comparing this document with the international
standards documents.
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).
Address Field
The Address field is a single octet and contains the binary
sequence 11111111 (hexadecimal 0xff), the All-Stations address.
PPP does not assign individual station addresses. The All-
Stations address should 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 reported through the normal network management facility.
Control Field
The Control field is a single octet and contains the binary
Perkins [Page 5]
RFC 1171 Point-to-Point Protocol July 1990
sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
(UI) command with the P/F bit set to zero. Frames with other
Control field values should be silently discarded.
Protocol Field
The Protocol field is two octets and its value identifies the
protocol encapsulated in the Information field of the frame. The
most up-to-date values of the Protocol field are specified in the
most recent "Assigned Numbers" RFC [12]. Initial values are also
listed below.
Protocol field values in the "cxxx" range identify datagrams as
belonging to the Link Control Protocol (LCP) or associated
protocols. Values in the "8xxx" range identify datagrams belonging
to the family of Network Control Protocols (NCP). Values in the
"0xxx" range identify the network protocol of specific datagrams.
This Protocol field is defined by PPP and is not a field defined
by HDLC. However, the Protocol field is consistent with the ISO
3309 extension mechanism for Address fields. All Protocols MUST be
odd; the least significant bit of the least significant octet MUST
equal "1". Also, all Protocols MUST be assigned such that the
least significant bit of the most significant octet equals "0".
Frames received which don't comply with these rules should be
considered as having an unrecognized Protocol, and should be
handled as specified by the LCP. The Protocol field is
transmitted and received most significant octet first.
Perkins [Page 6]
RFC 1171 Point-to-Point Protocol July 1990
The Protocol field is initially assigned as follows:
Value (in hex) Protocol
0001 to 001f reserved (transparency inefficient)
0021 Internet Protocol
0023 * OSI Network Layer
0025 * Xerox NS IDP
0027 * DECnet Phase IV
0029 * Appletalk
002b * Novell IPX
002d * Van Jacobson Compressed TCP/IP 1
002f * Van Jacobson Compressed TCP/IP 2
8021 Internet Protocol Control Protocol
8023 * OSI Network Layer Control Protocol
8025 * Xerox NS IDP Control Protocol
8027 * DECnet Phase IV Control Protocol
8029 * Appletalk Control Protocol
802b * Novell IPX Control Protocol
802d * Reserved
802f * Reserved
c021 Link Control Protocol
c023 * User/Password Authentication Protocol
* Reserved for future use; not described in this document.
Information Field
The Information field is zero or more octets. The Information
field contains the datagram for the protocol specified in the
Protocol field. The end of the Information field is found by
locating the closing Flag Sequence and allowing two octets for the
Frame Check Sequence field. The default maximum length of the
Information field is 1500 octets. By prior agreement, consenting
PPP implementations may use other values for the maximum
Information field length.
On transmission, the Information field may be padded with an
arbitrary number of octets up to the maximum length. It is the
responsibility of each protocol to disambiguate padding octets
from real information.
Frame Check Sequence (FCS) Field
The Frame Check Sequence field is normally 16 bits (two octets).
By prior agreement, consenting PPP implementations may use a 32-
Perkins [Page 7]
RFC 1171 Point-to-Point Protocol July 1990
bit (four-octet) FCS for improved error detection.
The FCS field is calculated over all bits of the Address, Control,
Protocol and Information fields not including any start and stop
bits (asynchronous) and any bits (synchronous) or octets
(asynchronous) inserted for transparency. This does not include
the Flag Sequences or FCS field. The FCS is transmitted with the
coefficient of the highest term first.
For more information on the specification of the FCS, see ISO 3309
or CCITT X.25.
Note: A fast, table-driven implementation of the 16-bit FCS
algorithm is shown in Appendix B. This implementation is based
on [7], [8], and [9].
Modifications to the Basic Frame Format
The Link Control Protocol can negotiate modifications to the
standard PPP frame structure. However, modified frames will
always be clearly distinguishable from standard frames.
Perkins [Page 8]
RFC 1171 Point-to-Point Protocol July 1990
4. The PPP Link Control Protocol (LCP)
The Link Control Protocol (LCP) provides a method of establishing,
configuring, maintaining and terminating the point-to-point
connection. LCP goes through four distinct phases:
Phase 1: Link Establishment and Configuration Negotiation
Before any network-layer datagrams (e.g., IP) may be exchanged,
LCP must first open the connection through an exchange of
Configure packets. This exchange is complete, and the Open state
entered, once a Configure-Ack packet (described below) has been
both sent and received. Any non-LCP packets received before this
exchange is complete are silently discarded.
It is important to note that LCP handles configuration only of the
link; LCP does not handle configuration of individual network-
layer protocols. In particular, all Configuration Parameters
which are independent of particular network-layer protocols are
configured by LCP. All Configuration Options are assumed to be at
default values unless altered by the configuration exchange.
Phase 2: Link Quality Determination
LCP allows an optional Link Quality Determination phase following
transition to the LCP Open state. In this phase, the link is
tested to determine if the link quality is sufficient to bring up
network-layer protocols. This phase is completely optional. LCP
may delay transmission of network-layer protocol information until
this phase is completed.
The procedure for Link Quality Determination is unspecified and
may vary from implementation to implementation, or because of
user-configured parameters, but only so long as the procedure
doesn't violate other aspects of LCP. One suggested method is to
use LCP Echo-Request and Echo-Reply packets.
What is important is that this phase may persist for any length of
time. Therefore, implementations should avoid fixed timeouts when
waiting for their peers to advance to phase 3.
Phase 3: Network-Layer Protocol Configuration Negotiation
Once LCP has finished the Link Quality Determination phase,
network-layer protocols may be separately configured by the
appropriate Network Control Protocols (NCP), and may be brought up
and taken down at any time. If LCP closes the link, it informs
the network-layer protocols so that they may take appropriate
Perkins [Page 9]
RFC 1171 Point-to-Point Protocol July 1990
action.
Phase 4: Link Termination
LCP may terminate the link at any time. This will usually be done
at the request of a human user, but may happen because of a
physical event such as the loss of carrier, or the expiration of
an idle-period timer.
Perkins [Page 10]
RFC 1171 Point-to-Point Protocol July 1990
4.1. The LCP Automaton
4.1.1. Overview
LCP is specified by a number of packet formats and a finite-state
automaton. This section presents an overview of the LCP automaton,
followed by a representation of it as both a state diagram and a
state transition table.
There are three classes of LCP packets:
1. Link Establishment packets used to establish and configure a
link, (e.g., Configure-Request, Configure-Ack, Configure-Nak
and Configure-Reject)
2. Link Termination packets used to terminate a link, (e.g.,
Terminate-Request and Terminate-Ack)
3. Link Maintenance packets used to manage and debug a link,
(e.g., Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply
and Discard-Request)
The finite-state automaton is defined by events, state transitions
and actions. Events include receipt of external commands such as
Open and Close, expiration of the Restart timer, and receipt of
packets from a LCP peer. Actions include the starting of the Restart
timer and transmission of packets.
4.1.2. State Diagram
The state diagram which follows describes the sequence of events for
reaching agreement on Configuration Options (opening the PPP
connection) and for later closing of the connection. The state
machine is initially in the Closed state (1). Once the Open state
(6) has been reached, both ends of the link have met the requirement
of having both sent and received a Configure-Ack packet.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -