Point-to-Point Protocol

Point-to-Point Protocol

1. Introduction
The Point-to-Point Protocol is designed to establish a simple connection between data packets transmitted between two peer entities. This connection provides the same
And assume that the data packets are delivered in order. PPP connections provide a wide range
The solution is to conveniently use a variety of values that are not forgotten as the value of the maximum receiving unit.

Fill domain
During transmission, the information field may be filled by any number of additional bytes to the maximum length of the receiving unit. This
Each protocol is responsible for Separating information domains and fill domains.

3. PPP connection operation

3.1 Overview
To establish communication in a point-to-point connection, each end of the PPP connection must first send LCP data
Package to configure and test data connections. After a connection is established, the peer entity may need to be authenticated.
Then, PPP must send NCP data packets to select one or more network layer protocols for configuration. Once
After the selected network layer protocol is configured, the network layer datagram can be transmitted on the link.
The link remains configurable until LCP packets and NCP packets terminate the connection, or
When other external events occur (for example, when the time of the inactive clock is full or the interference of network administrators ).

3.2 status chart
During the configuration of maintaining and terminating the point-to-point connection, the PPP connection goes through several different stages.
The following simplified state chart describes the phases:

+ ------ ++ ----------- ++ -------------- +
| Connection | enabled | successful/None
| Death | -------> | establish | ----------> | authenticate | -- +
|
+ ------ ++ ----------- ++ -------------- + |
^ |
| Failed |
+ <-------------- ++ ---------- + |
|
| + ----------- + | + --------- + |
| Disconnected | closing |
+ ------------ | Terminated | <--- + <---------- | Network | <-+
|
+ ----------- ++ --------- +

3.3 connection death stage (physical layer not ready)
The start and end of a connection must go through this phase. When an external event (such as detecting a carrier or network
Management Personnel configuration) indicates that when the physical layer is ready and available for use, PPP will enter the connection establishment phase.
At this stage, the LCP protocol automation (as mentioned later) is in the initial or starting state. When you enter
After the connection is established, an UP Event Notification LCP is triggered.

Application notes:
Typically, a connection will automatically return to this phase after the modem connection is disconnected. Telephone lines in use
In the case of connection, this phase will be quite short, so little time can be used to detect its existence with the instrument.

3.4 connection establishment phase
The Link Control Protocol (LCP) establishes a connection by exchanging configuration packets. When the LCP
The switching process for establishing a connection is completed only when the connection is enabled and the configuration validation packet is sent and received.
All configuration options are assumed to be the default value, unless they are changed during configuration interaction. About LCP
For more information about configuration options, see the following section.
One thing is very important, that is, those options that are not related to the specific network layer protocol can be
Configuration. Configuring a separate network layer protocol is configured by the corresponding network control protocol in the network layer protocol phase.
Any non-LCP packets received in this phase will be silently discarded.
Receiving the LCP configuration request packet will cause the PPP connection to return from the network layer protocol phase or authentication phase
Return to the connection establishment stage.

3.5 Certification phase
In some connections, you want to authenticate peer entities before allowing network-layer protocol Packet Exchange.
Lack of time-saving authentication is not necessary. If you want peer entities to use certain authentication protocols for authentication during the application
This requirement must be put forward in the connection establishment phase.

The authentication phase should be immediately after the connection phase is established. However, there may be parallel connection quality decisions.
The application must not allow the exchange of data packets determined by the connection quality to cause an uncertain delay in authentication.
The Network Layer Protocol phase after the authentication phase can only begin after the authentication is complete. If the authentication fails
Terminate the connection.
Only data packets of Connection Control Protocol, authentication protocol, and connection quality monitoring can appear in this phase. All
Other packets received in this phase will be silently discarded.

Application notes:
Authentication fails because of timeout or lack of response. Re-transmission should be allowed, only for trial
When the number of graph authentications exceeds a certain limit, the connection is terminated.
If the other party refuses to authenticate, the other party has the right to terminate the connection.

3.6 Network Layer Protocol phase
Once PPP completes the above phase, each network layer protocol (such as IP, IPX,
AppleTalk must be configured separately by the corresponding Network Control Protocol (NCP.
Each network control protocol can be enabled or disabled at any time.

Application notes:
Because it may take a lot of time to determine the connection quality at the beginning, when you wait for the peer
Fixed timeout restrictions should be avoided when configuring the row network control protocol.
When a network control protocol automation reaches the enabled status, the corresponding information can be transmitted over the PPP connection.
Network Layer Protocol packet. When any network-layer protocol data packets supported are received
When the status automation of the Protocol does not enter the enabled status, it will be discarded silently.

Application notes:
As long as the LCP Protocol Status automation is in the enabled status, any unsupported protocol data is received
All packages will return the Protocol rejection package (as mentioned later ). All supported Protocol packets are silently discarded.
In this phase, the LCP data packets, NCP data packets, and network-layer protocol data packets are circulated over the connection.

3.7 terminate connection
The PPP connection can be terminated at any time. The possible causes are carrier loss, authentication failure, connection quality failure, and excessive
When the counter overflows, or the network administrator closes the connection.
LCP terminates the connection by switching the connection termination package. When the connection is being terminated, PPP will pass
The network layer so that it can take corresponding actions.

After a termination request packet is exchanged, the physical layer will be notified to be disconnected so that the connection can be terminated, especially when authentication fails.
Hou. The Party sending the connection termination request package should wait until the connection termination confirmation package is received or the timeout counter is filled
And then disconnected. The party receiving the connection termination confirmation package should wait for the other party to disconnect first and never disconnect until at least
There is a timeout timer that overflows after the terminated connection validation packet is sent. Then PPP should enter the connection death stage
.
All received non-LCP packets in this phase will be silently discarded.

Application notes:
It is enough to use LCP when it is disabled. Each NCP does not need to send a termination packet. Phase
In contrast, an NCP-based automatic mechanism cannot close the entire PPP connection, even if the NCP-based automatic
The host is currently only in the enabled status.

4. Option Negotiation Automation
Finite State Automation is defined by event, action, and State migration. Events include receiving external commands, such as opening or disabling
Timeout timer overflow and receive packets sent by the other party. Actions include opening the timeout counter and sending messages to the other party
Send data packets.
Some types of data packets, such as configuring a denial package and a denial package, serial number rejection package and Protocol rejection package, or
The response packet, response packet, and discard request packet are not differentiated in the description of the automatic mechanism. As we will
As mentioned, although these different types of data packets may cause the same State migration, they do have different operations.
.

Event action
Up = low-layer connected tlu = this layer is connected
Down = the underlying layer is disconnected. tld = the underlying layer is disconnected.
Open = Open connection tls = connection started at this layer
Close = Close connection tlf = Connection closed for this layer

TO + = timeout timer overflow and timeout counter value greater than zero irc = initialization timeout counter
TO-= timeout timer overflow and timeout counter value less than zero zrc = Time-out counter cleared

RCR + = received correct configuration request package scr = sent configuration request package
RCR-= incorrect configuration request packet received
RCA = received configuration confirmation package sca = sent configuration confirmation package
RCN = received configuration rejection package/rejection package scn = sent configuration rejection package/rejection package

RTR = received termination request packet str = sent termination Request Packet
RTA = received termination confirmation package sta = sent termination confirmation package

RUC = received unknown encoding package scj = sent encoding rejection package
RXJ + = receive the encoding rejection packet (allowed)
Or be rejected by agreement
RXJ-= received encoding rejection packet (bad)
Or be rejected by agreement
RXR = received response packet ser = sent response packet
Or receive a response packet.
Or receive the discard request packet.
4.1 Status transfer table
The following is the complete status transition table. Status. The lower layer is still not ready. Timeout
The timer is not running in this status.
When the lower layer becomes available, the configuration request package is sent.

Closed status
In this status, the connection is valid, but no Open event occurs. The timeout timer is not running either.
In this status.
After receiving the configuration request package, the termination request package is sent. The acceptance confirmation package will be silently discarded
To avoid loops.

Stopped status
This status is migrated after an Open event occurs in the Closed status. When an automatic machine enters
After a tlf action is performed or a termination request packet is sent, it enters this status while waiting for the Down event. Timeout
Is not running in this status.
After receiving the configuration request package, you will make a proper response. When other types of packets are received, they are sent.
Terminate the Validation Package. The acceptance confirmation package will be silently discarded to avoid loops.

Basic Principles:
The Stopped status is the connection termination phase, connection configuration failure, and other error modes of the automatic mechanism.
Intersection.
There is also competition between the Down event (triggered by the tlf Action) and the RCR event. When R
Or reject requests from other users. Since the connection is confirmed as available, a Down event and a tight
Then the Open event is used to notify LCP to simulate the implementation. It should be noted that the Close event cannot be caused
Other causes.
At this time, a Down event is triggered, followed by an Up event. In this way, the connection has
The order starts to re-negotiate, the automatic machine is changed from the Closing status to the Stopping status, and
Tlf will be disconnected. The automatic machine will wait in the Stopped or Starting Status
Next connection.

Timeout (TO +, TO-) event
The Timeout event indicates that the Timeout timer overflows. After sending the configuration request package and terminating the request package
The timeout timer starts timing.
The TO + event indicates that the timeout counter value is still greater than zero. Each time the timeout counter is subtracted, it indicates
Configure a request packet or terminate the request packet and re-upload it once.
The TO-event indicates that the timeout counter value is smaller than zero and no data packets need TO be re-transmitted.

Receive-Configure-Request (RCR +, RCR-) event
The RCR event indicates that the configuration request packet sent from the other party is received. Configure the request package arrival table
The other party wants to open the connection and specify the connection option. The configuration request package will be described in more detail later.
The RCR + event indicates that the configuration request of the other party is acceptable and will be sent to the configuration Validation Package.
RCR-event indicates that the configuration request of the other party is unacceptable, and the corresponding configuration negative package or
Configure the reject package.

Application notes:
These events can occur when the automatic machine is already in the Opened State. Prepare now
The option for re-negotiation.

Receive-Configure-Ack (RCA) event
When the RCA event appears, it indicates that the recipient has received the information from the system? The results of this action are highly dependent on application needs.

This-Layer-Finished (tlf) Action
The tlf action indicates that the low-layer protocol automation enters the Intial state and the Closed state.
, Or Stopped status, and the lower layer is no longer used for connection. Use Down when low-level termination
.
Typically, this action may be used by LCP to enter the connection death stage in advance or by NCP
Notifies LCP that the connection may terminate if no NCP is enabled.
The results of this action are highly dependent on application needs.

Initialize-Restart-Count (irc) Action
The irc action initialization timeout counter is a suitable value (Max-Terminate or
Max-Configure ). Each time a packet is sent, the counter is subtracted by one and includes the first time.

Application notes:
In addition to setting the timeout counter, you must also set the timeout event length for the timeout timer.

Zero-Restart-Count (zrc) Action
The zrc action clears the timeout counter.

Application notes:
This action enables the finite automatic state machine to stop before entering the final desired state, allowing
Manage network traffic. In addition to setting the timeout counter, you must also set the timeout event length for the timeout timer.

Send-Configure-Request (scr) Action
The scr action will send the configuration request package. This indicates that the connection is expected to be opened with the specified configuration options. When configuring
When the option package is sent, the timeout timer starts timing to prevent it from being lost. When a configuration request packet is sent
The counter is reduced by one.

Send-Configure-Ack (sca) Action
The sca action sends the configuration Validation Package. It indicates that all the configurations in the received configuration request package are checked.
.

Send-Configure-Nak (scn) Action
The scn action sends a configuration rejection package or a configuration rejection package. It indicates that the received configuration request packet is denied.
Some configuration options.
The configuration denial package is used to reject a configuration option value, and a new acceptable configuration is recommended.
Set the option value. Configuration rejection packages are used to reject all configuration options, typically because these options are not recognized.
Or used. The Link Control Protocol packet format will be described later on how to use the configuration rejection package and the configuration rejection package
.

Send-Terminate-Request (str) Action
The str action sends a termination request packet. It indicates that the connection is expected to be closed. When the request packet is sent
The timer starts timing to prevent it from being lost. Each time a configuration request packet is sent, the timeout counter is reduced by one.

Send-Terminate-Ack (sta) Action
The sta action sends a termination confirmation packet. It indicates that the received termination request package or the agreement with both parties has been confirmed.
Discuss the role of automatic machines for synchronization.

Send-Code-Reject (scj) Action
The scj action sends an encoding rejection packet. It indicates that an unidentifiable data packet is received.

Send-Echo-Reply (ser) Action
The ser action sends a response packet. It indicates that the response packet is received.

4.6 avoid Loops

The protocol effectively avoids the loop during configuration negotiation. However, the Protocol does not guarantee that such a loop will no longer appear.
When negotiating any options, the two Parties may adopt conflicting and incompatible configuration policies. However, both parties may
A compatible configuration policy is adopted, but it may take a lot of time. The application should keep this in mind and
Application cycle monitoring mechanism and higher-level timeout mechanism.

4.7 counters and timers

Timeout Timer
The automatic machine does not use a special timer. The timeout timer is used to monitor configuration request packets and terminate requests.
Transfer of packets. When the timer is full, a Timeout event is triggered and the corresponding configuration request is resent.
Package or terminate request package. The timeout Timer must be configured and the default value is three seconds.

Application notes:
The timeout timer is set based on the connection speed. The default value is low-speed connection (2400-
9600bps), high-speed switching connections (such as telephone lines) are designed. High-speed connection or low switching
Speed connections should increase the number of retransmission times accordingly.

Instead of a fixed timeout value, the timeout timer should be initially set to a small value and then be increased to reach the final configuration value. Each
A successful value smaller than the final value should be twice the previous value. The initial value should be sufficient to process a data packet,
It is usually set to twice as long as the time for making a round-trip between transmissions at the connection speed plus one hundred milliseconds to allow the other party
Data packets can be processed before a response is initiated.

Maximum number of termination times
It is a value required to terminate the timeout counter of the Request Packet Count. It indicates that the other party cannot
The maximum number of times that a termination request packet is sent before the response is answered and the termination confirmation package is not received. The maximum number of termination times is required.
It must be configured and the default value should be retransmitted twice.

Maximum number of configurations
Similar requests are recommended to configuration request packages. It indicates that the recipient has not received the answer before assuming that the other party cannot make the answer.
The maximum number of requests sent to the configuration confirmation package, configuration rejection package, or configuration rejection package. Maximum configuration times
The number must be configured, and the default value should be 10 retransmissions.

Maximum number of failures

Similar quantities are recommended to configuration negative packages. It indicates whether or not the configuration Validation Package is configured before it is assumed that no agreement is reached.
Set the maximum number of packets sent. Any suggestions in the configuration rejection package recommended by the other party and then added to the configuration rejection package
The options and the expected options are not appended during the negotiation. The maximum number of configurations must be configured, and
The default value should be five times.

5. Link Control Protocol data packet format
There are three types of Link Control Protocol Data Packets:
1. Connection configuration data packets are used to establish and configure connections. (Configure the request package, configure the Validation Package, and configure the negative package.
And configure a deny packet ).
2. The connection termination package is used to terminate the connection (terminate the request package and terminate the confirmation package ).
3. Connection maintenance data packets are used to manage and debug connections (encoding rejection packets, protocol rejection packets, and response to request packets,
Response packet and discard request packet ).
For simplicity, the data link control protocol data packet format does not have a version number field. For unidentifiable protocols and
The encoding can respond in a simple and identifiable format of link control protocol data packets.
A deterministic but inefficient operating mechanism.
No matter what configuration options are determined to be enabled, all connection configuration packages, connection termination packages, and encoding rejection packages (encoding numbers
1-7) it is assumed that no configuration options are negotiated. In fact, a default value is specified for each configuration option.
In this way, data packets such as Link Control protocols can always be identified, even if the connection is over but it is still incorrectly recognized
Indicates that the connection is enabled.

The link control protocol data packet is encapsulated in the data domain of the PPP frame format, and the value of the Protocol domain of the PPP frame is 0x.
C021.
The data packet format of the Link Control Protocol is summarized as follows. 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 4 5 6 7 8 9 0 1
+- +-+
| Encoding | identifier | length |
+- +-+
| Data...
+-+

Encoding domain
The encoding field occupies eight bytes. It identifies the type of link control protocol data packets. When
When the encoding domain cannot recognize the data packet, it sends the encoding rejection data packet.
The value of the latest encoding field is determined by the recently published "Assigned Numbers" RFC.
File description. This document has the following values:
1. Configure the Request (Configure-Request)
2. Confirm configuration (Configure-Ack)
3. Configure-Nak)
4. Configuration rejection (Configure-Reject)
5. Terminate a Request (Terminate-Request)
6. Terminate-Ack)
7. Code-Reject)
Protocol-Reject)
9. Response Request)
10 response (Echo-Reply)
11. Discard-Request)

Id domain
The ID Domain Encoding occupies an eight-byte value, which helps match requests and responses. When the mark in the received packet
The recognition domain is invalid and will be silently discarded without affecting the status of the automatic machine.

Length Field
The identifier Domain Encoding occupies two eight bytes. It identifies the length of the Link Control Protocol packet, including the encoding domain
, Id domain, data domain, etc. The length cannot exceed the maximum length of the connection.
The eight-byte exceeding the length field is considered to be filled in bytes and ignored during receiving. When the received length domain is invalid
When a data packet is sent, It is silently discarded without affecting the status of the automatic machine.

Data domain
The data field has zero or multiple eight-bit bytes, as indicated in the length field. The format in the data field is
The value in the encoding field is determined.

5.1 configuration request
Description
When you want to open a connection, you must send the configuration request package. In the option field, the default connection value is changed as expected.
Fill in the configuration options. The configuration option does not need to include the configuration option that uses the default value.
When a configuration request packet is received, the appropriate data packet must be sent as a response.
The configuration request package format is summarized as follows. 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 4 5 6 7 8 9 0 1
+- +-+
| Encoding | identifier | length |
+- +-+
| Option...
+-+

Encoding
1 indicates the configuration request.

Identifier
When the content in the option field changes or when an invalid response to the previous request is received, the ID field should be changed
. During re-transmission, the ID field should not be changed.

Option
The option field is variable in length and contains a list of zero or more configuration options to be negotiated. Select All configurations
Items will be negotiated at the same time. The format of option fields will be discussed in detail in later sections.

5.2 confirm Configuration
Description
If the configuration options in the configuration request packet sent by the other Party are both identifiable and acceptable, you can send
Configure the Validation Package. The order of the confirmed options and the options themselves cannot be modified in any way.
The ID field in the received configuration Validation Package must match the same as the ID field in the configuration request package sent at the same time.
. In addition, the options in the configuration Validation Package must be exactly the same as those in the configuration request package sent at the same time.
The configuration request package format is summarized as follows. Transmitted from left to right.

0 1 2 is used to notify the recipient that the recipient can receive more
Or require the other party to send smaller data packets.
It defaults to 1500 bytes. If less data packets are required, the application will still
The information fields are received in 1500 bytes.

Application notes:

This option describes the application capabilities. The other party does not require the maximum capability. For example, when MRU is
2048 bytes, and the other party is not required to send a 2048-byte data packet. At this time, the recipient does not need to use
The configuration of the negative packet indicates that it only sends packets smaller than 2048 bytes, because the application always requires at least
1500 bytes of data packets.
The format of the maximum receiving unit configuration option is summarized as follows. 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 4 5 6 7 8 9 0 1
+- +-+
| Type | length | maximum receiving unit |
+- +-+

Type
1

Length
4

Maximum receiving unit
The maximum receiving unit field has two eight-bit bytes. It specifies the maximum bytes that can be accepted by the information field and the filling Field.
Number. It does not include frame protocol fields, cyclic verification codes, and any bit or byte required for transparent transmission.

6.2 Authentication Protocol
Description
When performing some connections, you may want to require the Peer to authenticate yourself before switching network-layer packets.
This configuration option provides a way to negotiate with the specified authentication protocol for authentication. Authentication by default
Yes.
The application cannot contain multiple authentication protocol configuration options in the configuration request package. Instead, configure
The most desired authentication protocol. If no package is configured, configure the second
The authentication protocol to be used.
The application sends a configuration request packet, indicating that it wants the other party to authenticate itself. If the recipient sends a message to confirm the configuration
Indicates that it agrees to use the specified protocol for erkins, D., "Requirements for an Internet
Standard Point-to-Point Protocol ", RFC 1547, Carnegie Mellon University,
December 1993.

[2] Renault, J., and Postel, J., "Assigned Numbers", STD 2, RFC
1340, USC/Information Sciences Institute, July 1992.