LCP data packets of PPP protocol

We have introduced the basic content of the PPP protocol, the PPP data frame and the PPP mode. Here we will explain the content of the LCP data packets of the PPP protocol. Through the previous article, we know that LCP data packets are exchanged during the link establishment phase and are encapsulated in the PPP data frame information domain as the net load of PPP. The content of the information domain is changing throughout the process of link establishment. It includes many types of packets. Therefore, these packets must be differentiated by corresponding fields.

The Protocol domain of the PPP data frame is fixed with 0xC021.

The length of the code domain is one byte, which is mainly used to identify the type of LCP data packets. When the Code domain of the LCP data packet received by the receiver cannot be identified during the link establishment phase, an LCP Code rejection message Code-Reject packet will be sent to the peer end ).

The Identifier Field is also a byte, which is used to match request and response packets. Generally, when the link is established, both parties send several configuration Request packets (Config-Request packets) consecutively, and the data domains of these Request packets may be identical, they only have different identification domains. Generally, the ID of a configured request packet is gradually increased by 1 from 0x01. When the peer receives the configured request packet, no matter which type of message is used, one of the three messages may be Config-Ack, Config-Nak, and Config-Reject) to be consistent with the ID in the received message, when the communication device receives the response, it can compare the response with the sent response to determine the next operation.

Length field content = total byte data code field + sign field + length field + data field ). Bytes other than the number of characters indicated by the length field are ignored as filling bytes, and the content of this field cannot exceed the value of MRU.

The content of the data domain varies with the content of the LCP data packets.

The following describes several types of packets in LCP. Different packets have different content in the ID domain.

LCP packets are divided into 1. Link Configuration packets; 2. Link termination packets; 3. Link maintenance packets.

Link Configuration packets mainly include Config-Request, Config-Ack, Config-Nak, and Config-Reject.

When both parties need to establish a link, either party needs to send the Config-Request message and carry the Configuration Parameter options that each end wants to negotiate.

When the receiver receives the Config-Request message, it selects one of the three types of messages to respond to the other's Request message, the following two conditions must be met for the selected Response Message:

The Type field of the Configuration Parameter options cannot be fully recognized. We know that a Config-Request message will contain multiple Configuration Parameter options at the same time, for a communication device that supports the PPP protocol, it does not necessarily support all the configuration options listed in the table above. Even if it is supported, some options may be disabled in actual applications. For example, when the PPP protocol is used to communicate with one end, some useless configuration options may be disabled, but only the 0x01 and 0x03 Configuration Parameter options are supported, therefore, when the Config-Request message sent by the recipient contains the 0x04 configuration option, this configuration parameter option cannot be identified for the local end, that is, negotiation of this configuration parameter option is not supported ).

If you can fully identify the Configuration Parameter options, the acceptor may not accept the Configuration Parameter options in the Config-Request message, for example: when the magic word in the parameter option of sending the magic word to one end is all 0, and the opposite end is considered to be another value, this situation is not supported in the Configuration Parameter options ).

Therefore, based on the preceding two conditions, we can determine what type of message is used to respond to the request packets configured by the other party.

When one end of the received Config-Request message identifies all Configuration Parameter options sent and recognizes the content of all Configuration Parameter options data fields, the receiving end will return a Config-Ack packet to the peer end and place the Configuration Parameter options in the configuration request packet intact in the data domain of the Config-Ack packet. According to the protocol, the configuration cannot be changed. parameter options ). After receiving the Config-Ack packet, the sender of the configuration request enters the next stage from the current stage.

When one end of the received Config-Request message can identify all the Configuration Parameter options sent by the sender, but it does not recognize the content in the data field of some Configuration Parameter options, the acceptor will send a Config-Nak message to the peer. Note that it can be identified, but it does not recognize part of the parameter content, so it is not a Config-Reject message) only Unrecognized configuration parameter options are included in the message, and the data of these Configuration Parameter options is the expected value of this end. However, when the receiving end receives the Config-Nak message, it resends the Config-Request message, the difference between the Config-Request Message and the Config-Request Message sent last time is that the content of Configuration Parameter options that are not recognized by the peer is filled in the Config-Request Message sent again after the negotiation. -Configuration Parameter options sent from the Config-Nak packet in the Request message ).

When one end of the received Config-Request message cannot identify all Configuration Parameter options sent by the sending end, the receiving end will return a Config-Reject message to the peer end, only Unrecognized configuration parameter options are included in the data fields in the message when the type fields of the Configuration Parameter options are not recognized ). After receiving the Config-Reject message, the peer will send a Config-Request message again, the difference between this configuration request message and the previous sending is that the Configuration Parameter options that cannot be identified are deleted.

Link termination packets are divided into two types: Terminate-Request and Terminate-Reply. The LCP message provides a mechanism to disable a point-to-point connection. The end of the link to be disconnected will continuously send the Terminate-Request message until it receives a Terminate-Reply message. Once the receiving end receives a Terminate-Request packet, it must respond to a Terminate-Reply packet and wait for the peer end to disconnect the link before completing all the operations on the local end.

The data domains of the LCP link termination packets are different from those of the Link Configuration packets. No Configuration Parameter options are required in the Link termination packets. The same ID is required for the link termination message. The link termination operation is performed only when the Terminate-Reply message is received.

Finally, let's talk about the magic word meaning. This is an important parameter in the Process of link establishment. This parameter is negotiated in Config-Request and is mainly used to prevent loops, if the two parties do not negotiate magic words, some LCP data packets must use magic words, then the magic word content can only be filled with 0; otherwise, the result is the result of parameter negotiation.

The magic word must be negotiated among all devices. It is sent in the Config-Request configuration option parameter and must be generated independently by the communication device, the Protocol requires devices to use random methods to generate a unique magic word to avoid unnecessary communication troubles. Generally, the magic word uses the serial number, network hardware address, or clock of the device. The two sides may not have the same magic word, but should avoid it as much as possible. Generally, this situation occurs when devices of the same manufacturer are interconnected, because the devices produced by a vendor generate magic words in the same way.

We know that magic words are used to detect whether a link has a loop. When the receiving end receives a Config-Request message, the packet is compared with the Config-Request received last time. If the two messages contain different magic words, the link does not have a loop. However, if they are consistent, the acceptor deems that the link may have a loop, but not necessarily, and further confirmation is required. At this time, the receiving end will send a Config-Nak packet, and carry a re-generated magic word in the packet, and before receiving any Config-Request or Config-Nak packets, the acceptor will not send any Config-Request messages. In this case, we assume there may be two situations:

1. The link actually does not have a loop, but because the other side produces the same magic word as the acceptor, the probability of such a situation is very small. When the Config-Nak is received by the peer, a magic word in the Config-Request message is sent in the Nak packet.) After receiving the message, the peer end compares it with the previous one, because the acceptor has generated a different magic word in the Nak message, the magic word in the Config-Request message received by the acceptor is different from the one in the previous configuration Request message, therefore, the receiver can conclude that the link does not have a loop.

2. The link actually has a loop. After a period of time, the Config-Nak packet will return to the same end that sent the packet. At this time, the receiving end compares the Config-Nak packet with the previous one, so the possibility of a loop in the link increases. We know that when one end receives a Config-Nak message, it will send a Config-Request message in which the magic word is consistent with that in Config-Nak ), in this way, the initial status is returned, and the Config-Request and Config-Nak messages will appear continuously on this link. Therefore, the cycle continues, the receiving end will think that there is a loop in the PPP link. When it reaches a certain order of magnitude, it can be considered that there is a loop in the link. Note: It is not the first time that the same magic word is used to determine that a loop exists)

However, in actual application, we can implement PPP protocol based on different devices. We can use two methods in link loop detection. The first mechanism is as described above. This process repeats constantly and may eventually send a Down event to the LCP state machine. In this case, the LCP state machine may return to the initialization phase, another round of negotiations began. Of course, some devices still adopt the second mechanism, that is, they do not generate any events to affect the current LCP state machine, but stay in the request sending status. However, one end of the device that thinks the link has a loop needs to continuously send an Echo-Request Message to the link to check whether the link loop is removed. When the receiving end receives the Echo-Reply message, it is deemed that the link loop is removed, and the subsequent PPP process may be carried out.

Okay. Basically, through three PPP chats, We can thoroughly understand the working mechanism and features of the PPP protocol. In fact, it is not difficult for people to come up with the protocol, only simple and easy-to-use protocols will be retained, just as TCP/IP beat OSI. So, as long as you calm down, there is nothing advanced. Some of the three articles may be incorrect. I hope you can give more comments and make progress together.