📄 rfc1331.txt
字号:
the data link. After the link has been established, the peer may be
authenticated. Then, PPP must send NCP packets to choose and
configure one or more network-layer protocols. Once each of the
chosen network-layer protocols has been configured, datagrams from
each network-layer protocol can be sent over the link.
The link will remain configured for communications until explicit LCP
or NCP packets close the link down, or until some external event
occurs (an inactivity timer expires or network administrator
intervention).
4.2. Phase Diagram
In the process of configuring, maintaining and terminating the
point-to-point link, the PPP link goes through several distinct
phases:
+------+ +-----------+ +--------------+
| | UP | | OPENED | | SUCCESS/NONE
| Dead |------->| Establish |---------->| Authenticate |--+
| | | | | | |
+------+ +-----------+ +--------------+ |
^ FAIL | FAIL | |
+<--------------+ +----------+ |
| | |
| +-----------+ | +---------+ |
| DOWN | | | CLOSING | | |
+------------| Terminate |<---+<----------| Network |<-+
| | | |
+-----------+ +---------+
4.3. Link Dead (physical-layer not ready)
The link necessarily begins and ends with this phase. When an
external event (such as carrier detection or network administrator
configuration) indicates that the physical-layer is ready to be used,
PPP will proceed to the Link Establishment phase.
During this phase, the LCP automaton (described below) will be in the
Initial or Starting states. The transition to the Link Establishment
phase will signal an Up event to the automaton.
Simpson [Page 10]
RFC 1331 Point-to-Point Protocol May 1992
Implementation Note:
Typically, a link will return to this phase automatically after
the disconnection of a modem. In the case of a hard-wired line,
this phase may be extremely short -- merely long enough to detect
the presence of the device.
4.4. Link Establishment Phase
The Link Control Protocol (LCP) is used to establish the connection
through an exchange of Configure packets. This exchange is complete,
and the LCP Opened state entered, once a Configure-Ack packet
(described below) has been both sent and received. Any non-LCP
packets received during this phase MUST be silently discarded.
All Configuration Options are assumed to be at default values unless
altered by the configuration exchange. See the section on LCP
Configuration Options for further discussion.
It is important to note that only Configuration Options which are
independent of particular network-layer protocols are configured by
LCP. Configuration of individual network-layer protocols is handled
by separate Network Control Protocols (NCPs) during the Network-Layer
Protocol phase.
4.5. Authentication Phase
On some links it may be desirable to require a peer to authenticate
itself before allowing network-layer protocol packets to be
exchanged.
By default, authentication is not necessary. If an implementation
requires that the peer authenticate with some specific authentication
protocol, then it MUST negotiate the use of that authentication
protocol during Link Establishment phase.
Authentication SHOULD take place as soon as possible after link
establishment. However, link quality determination MAY occur
concurrently. An implementation MUST NOT allow the exchange of link
quality determination packets to delay authentication indefinitely.
Advancement from the Authentication phase to the Network-Layer
Protocol phase MUST NOT occur until the peer is successfully
authenticated using the negotiated authentication protocol. In the
event of failure to authenticate, PPP SHOULD proceed instead to the
Link Termination phase.
Simpson [Page 11]
RFC 1331 Point-to-Point Protocol May 1992
4.6. Network-Layer Protocol Phase
Once PPP has finished the previous phases, each network-layer
protocol (such as IP) MUST be separately configured by the
appropriate Network Control Protocol (NCP).
Each NCP may be Opened and Closed at any time.
Implementation Note:
Because an implementation may initially use a significant amount
of time for link quality determination, implementations SHOULD
avoid fixed timeouts when waiting for their peers to configure a
NCP.
After a NCP has reached the Opened state, PPP will carry the
corresponding network-layer protocol packets. Any network-layer
protocol packets received when the corresponding NCP is not in the
Opened state SHOULD be silently discarded.
During this phase, link traffic consists of any possible combinations
of LCP, NCP, and network-layer protocol packets. Any NCP or
network-layer protocol packets received during any other phase SHOULD
be silently discarded.
Implementation Note:
There is an exception to the preceding paragraphs, due to the
availability of the LCP Protocol-Reject (described below). While
LCP is in the Opened state, any protocol packet which is
unsupported by the implementation MUST be returned in a Protocol-
Reject. Only supported protocols are silently discarded.
4.7. Link Termination Phase
PPP may terminate the link at any time. This will usually be done at
the request of a human user, but might happen because of a physical
event such as the loss of carrier, authentication failure, link
quality failure, or the expiration of an idle-period timer.
LCP is used to close the link through an exchange of Terminate
packets. When the link is closing, PPP informs the network-layer
protocols so that they may take appropriate action.
After the exchange of Terminate packets, the implementation SHOULD
signal the physical-layer to disconnect in order to enforce the
termination of the link, particularly in the case of an
authentication failure. The sender of the Terminate-Request SHOULD
Simpson [Page 12]
RFC 1331 Point-to-Point Protocol May 1992
disconnect after receiving a Terminate-Ack, or after the Restart
counter expires. The receiver of a Terminate-Request SHOULD wait for
the peer to disconnect, and MUST NOT disconnect until at least one
Restart time has passed after sending a Terminate-Ack. PPP SHOULD
proceed to the Link Dead phase.
Implementation Note:
The closing of the link by LCP is sufficient. There is no need
for each NCP to send a flurry of Terminate packets. Conversely,
the fact that a NCP has Closed is not sufficient reason to cause
the termination of the PPP link, even if that NCP was the only
currently NCP in the Opened state.
Simpson [Page 13]
RFC 1331 Point-to-Point Protocol May 1992
5. The Option Negotiation Automaton
The finite-state automaton is defined by events, actions and state
transitions. Events include reception of external commands such as
Open and Close, expiration of the Restart timer, and reception of
packets from a peer. Actions include the starting of the Restart
timer and transmission of packets to the peer.
Some types of packets -- Configure-Naks and Configure-Rejects, or
Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and
Discard-Requests -- are not differentiated in the automaton
descriptions. As will be described later, these packets do indeed
serve different functions. However, they always cause the same
transitions.
Events Actions
Up = lower layer is Up tlu = This-Layer-Up
Down = lower layer is Down tld = This-Layer-Down
Open = administrative Open tls = This-Layer-Start
Close= administrative Close tlf = This-Layer-Finished
TO+ = Timeout with counter > 0 irc = initialize restart
counter
TO- = Timeout with counter expired zrc = zero restart counter
RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request
RCR- = Receive-Configure-Request (Bad)
RCA = Receive-Configure-Ack sca = Send-Configure-Ack
RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej
RTR = Receive-Terminate-Request str = Send-Terminate-Request
RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack
RUC = Receive-Unknown-Code scj = Send-Code-Reject
RXJ+ = Receive-Code-Reject (permitted)
or Receive-Protocol-Reject
RXJ- = Receive-Code-Reject (catastrophic)
or Receive-Protocol-Reject
RXR = Receive-Echo-Request ser = Send-Echo-Reply
or Receive-Echo-Reply
or Receive-Discard-Request
- = illegal action
Simpson [Page 14]
RFC 1331 Point-to-Point Protocol May 1992
5.1. State Diagram
The simplified state diagram which follows describes the sequence of
events for reaching agreement on Configuration Options (opening the
PPP link) and for later termination of the link.
This diagram is not a complete representation of the automaton.
Implementation MUST be done by consulting the actual state
transition table.
Events are in upper case. Actions are in lower case. For these
purposes, the state machine is initially in the Closed state. Once
the Opened state has been reached, both ends of the link have met the
requirement of having both sent and received a Configure-Ack packet.
RCR TO+
+--sta-->+ +------->+
| | | |
+-------+ | RTA +-------+ | Close +-------+
| |<-----+<------| |<-str-+<------| |
|Closed | |Closing| |Opened |
| | Open | | | |
| |------+ | | | |
+-------+ | +-------+ +-------+
| ^
| |
| +-sca----------------->+
| | ^
RCN,TO+ V RCR+ | RCR- RCA | RCN,TO+
+------->+ | +------->+ | +--scr-->+
| | | | | | | |
+-------+ | TO+ +-------+ | +-------+ |
| |<-scr-+<------| |<-scn-+ | |<-----+
| Req- | | Ack- | | Ack- |
| Sent | RCA | Rcvd | | Sent |
+-scn->| |------------->| | +-sca->| |
| +-------+ +-------+ | +-------+
| RCR- | | RCR+ | RCR+ | | RCR-
| | +------------------------------->+<-------+ |
| | |
+<-------+<------------------------------------------------+
Simpson [Page 15]
RFC 1331 Point-to-Point Protocol May 1992
5.2. State Transition Table
The complete state transition table follows. States are indicated
horizontally, and events are read vertically. State transitions and
actions are represented in the form action/new-state. Multiple
actions are separated by commas, and may continue on succeeding lines
as space requires. The state may be followed by a letter, which
indicates an explanatory footnote.
Rationale:
In previous versions of this table, a simplified non-deterministic
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -