Point-to-Point Protocol (PPP)
When industry experts began to design the PPP standard, they had a much better idea of what features would be useful for the emerging Internet. They also knew that modems and phone lines were getting faster and could support a greater amount of protocol overhead. PPP was an effort to address some of the shortcomings of SLIP.
The designers of PPP also wanted PPP to be capable of dynamically negotiating configuration settings at the beginning of a connection and to be capable of managing the link between the communicating computers throughout the session.
How PPP Works
PPP is really a collection of protocols that interact to supply a full complement of modem-based networking features. The design of PPP evolved through a series of RFCs. The current PPP standard is RFC 1661; subsequent documents have clarified and extended PPP components. RFC 1661 divides the components of PPP into three general categories:
The primary purpose of PPP (and also SLIP) is to forward datagrams. One challenge of PPP is that it must be capable of forwarding more than one type of datagram. In other words, the datagram could be an IP datagram, or it could be some OSI network-layer datagram.
By the Way
The PPP RFCs use the term packet to describe a bundle of data transmitted in a PPP frame. A packet can consist of an IP (or other upper-layer protocol) datagram, or it can consist of data formatted for one of the other protocols operating through PPP. The word "packet" is an often-imprecise term used throughout the networking industry for a package of data transmitted across the network; for the most part, this book has attempted to use a more precise term, such as "datagram." Not all PPP data packages, however, are datagrams, so in keeping with the RFCs, this hour uses the term packet for data transmitted through PPP.
PPP must also forward data with information relating to its own protocols: the protocols that establish and manage the modem connection. Communicating devices exchange several types of messages and requests over the course of a PPP connection. The communicating computers must exchange LCP packets, used to establish, manage, and close the connection; authentication packets, which support PPP's optional authentication protocols; and NCP packets, which interface PPP with various protocol suites. The LCP data exchanged at the beginning of the connection configures the connection parameters that are common to all protocols. NCP protocols then configure suite-specific parameters relating to the individual protocol suites supported by the PPP connection.
The data format for a PPP frame is shown in Figure 8.5. The fields are as follows:
By the Way
Link Control Protocol (LCP)
Many PPP features that aren't available with SLIP are a result of LCP. Figure 8.6 describes how LCP configuration packets enable the communicating computers to establish a connection. In Figure 8.6, Computer A sends an LCP Configure-Request packet to Computer B. The Configure-Request packet includes a proposal for any connection parameters Computer A would like to negotiate for the connection. These parameters include the Maximum Receive Unit (MRU), the maximum length for the data enclosed in a PPP frame; the authentication protocol; and the quality control protocol, which defines how the connection monitors for reliable delivery, compression protocol settings, and other configuration choices.
РќР°Р±РѕСЂ РѕРЅР»Р°Р№РЅ РїРѕРёСЃРєРѕРІС‹С… СЃРµСЂРІРёСЃРѕРІ
If Computer B accepts all configuration options submitted in the Configure-Request packet, Computer B responds with a Configure-AcK packet (AcK stands for acknowledge). If all configuration options transmitted with the Configure-Request packet are recognizable but some are not acceptable to Computer B, then Computer B responds with a Configure-NaK packet (NaK stands for not acknowledged) and returns a list of unacceptable parameters with alternative values. Computer A then responds to the Configure-NaK with a new configuration request using adjusted values. This process continues until all values are accepted.
If the Configure-Request packet includes unrecognizable options, Computer B returns a Configure-Reject packet, which lists any unacceptable options.
Figure 8.7 shows the format for an LCP packet. Several other types of LCP packets assist with overseeing the modem connection. The Code field in Figure 8.7 identifies the LCP packet type. The Identifier field identifies the packet and helps to match up requests with acknowledgments. The Length field is the length of the packet. The data transmitted with the packet depends on the type of packet. A list of LCP packet type codes is shown in Table 8.1.
As mentioned earlier, LCP tends to maintenance and termination tasks as well as configuration tasks. The Terminate-Request and Terminate-AcK packets are used to request and acknowledge termination of the connection. Code-Reject and Protocol-Reject reject requests for an unknown code or protocol. Echo-Request, Echo-Reply, and Discard-Request provide maintenance, quality assurance, and troubleshooting capabilities.