As its name implies, the point-to-point protocol (PPP) [RFC 1661; RFC 2153] is a data-link layer protocol that operates over a point-to-point link--a link directly connecting two nodes, one on each end of the link. The point-to-point link over which PPP operates might be a serial dialup telephone line (for example, a 56K modem connection), a SONET/SDH link, an X.25 connection, or an ISDN circuit. As noted above, PPP has become the protocol of choice for connecting home users to their ISPs over a dialup connection. 

Before diving into the details of PPP, it is instructive to examine the original requirements that the IETF placed on the design of PPP [RFC 1547]: 

• Packet framing. The PPP protocol data-link layer sender must be able to take a network-level packet and encapsulate it within the PPP data-link layer frame such that the receiver will be able to identify the start and end of both the data link frame and the network-layer packet within the frame. 
• Transparency. The PPP protocol must not place any constraints on data appearing on the network-layer packet (headers or data). Thus, for example, the PPP protocol cannot forbid the use of certain bit patterns in the network-layer packet. We'll return to this issue shortly in our discussion of byte stuffing. 
• Multiple network-layer protocols. The PPP protocol must be able to support multiple network-layer protocols (for example, IP and DECnet) running over the same physical link at the same time. Just as the IP protocol is required to multiplex different transport level protocols (for example, TCP and UDP) over a single end-to-end connection, so too must PPP be able to multiplex different network layer protocols over a single point-to-point connection. This requirement means that at a minimum, PPP will likely require a "protocol type" field or some similar mechanism so the receiving-side PPP can demultiplex a received frame up to the appropriate network-layer protocol. 
• Multiple types of links. In addition to being able to carry multiple higher-level protocols, PPP must also be able to operate over a wide variety of link types, including links that are either serial (transmitting a bit at a time in a given direction) or parallel (transmitting bits in parallel), synchronous (transmitting a clock signal along with the data bits) or asynchronous, low-speed or high-speed, electrical or optical. 
• Error detection. A PPP receiver must be able to detect bit errors in the received frame. 
• Connection liveness. PPP must be able to detect a failure at the link level (for example, the inability to transfer data from the sending side of the link to the receiving side of the link) and signal this error condition to the network layer. 
• Network-layer address negotiation. PPP must provide a mechanism for the communicating network layers (for example, IP) to learn or configure each other's network layer address. 
• Simplicity. PPP was required to meet a number of additional requirements beyond those listed above. On top of all of these requirements, first and foremost among all of the PPP requirements is that of "simplicity." RFC 1547 states "the watchword for a point-to-point protocol should be simplicity." A tall order indeed given all of the other requirements placed on the design of PPP! More than 50 RFCs now define the various aspects of this "simple" protocol.

• Error correction. PPP is required to detect bit errors but is not required to correct them. 
• Flow control. A PPP receiver is expected to be able to receive frames at the full rate of the underlying physical layer. If a higher layer cannot receive packets at this full rate, it is then up to the higher layer to drop packets or throttle the sender at the higher layer. That is, rather than having the PPP sender throttle its own transmission rate, it is the responsibility of a higher-level protocol to throttle the rate at which packets are delivered to PPP for sending. 
• Sequencing. PPP is not required to deliver frames to the link receiver in the same order in which they were sent by the link sender. It is interesting to note that while this flexibility is compatible with the IP service model (which allows IP packets to be delivered end-to-end in any order), other network layer protocols that operate over PPP do require sequenced end-to-end packet delivery. 
• Multipoint links. PPP need only operate over links that have a single sender and a single receiver. Other link-layer protocols (for example, HDLC) can accommodate multiple receivers (for example, an Ethernet-like scenario) on a link.

5.8.1: PPP Data Framing

The PPP frame contains the following fields: 

• Flag field. Every PPP frame begins and ends with a one byte flag field with a value of 01111110. 
• Address field. The only possible value for this field is 11111111. 
• Control field. The only possible value of this field is 00000011. Because both the address and control fields can currently take only a fixed value, one wonders why the fields are even defined in the first place. The PPP specification [RFC 1662] states that other values "may be defined at a later time," although none have been defined to date. Because these fields take fixed values, PPP allows the sender to simply not send the address and control bytes, thus saving two bytes of overhead in the PPP frame. 
• Protocol. The protocol field tells the PPP receiver the upper-layer protocol to which the received encapsulated data (that is, the contents of the PPP frame's info field) belongs. On receipt of a PPP frame, the PPP receiver will check the frame for correctness and then pass the encapsulated data on to the appropriate protocol. RFC 1700 defines the 16-bit protocol codes used by PPP. Of interest to us is the IP protocol (that is, the data encapsulated in the PPP frame is an IP datagram) which has a value of 21 hexadecimal, other network-layer protocols such as Appletalk (29) and DECnet (27), the PPP link control protocol (C021 hexadecimal) that we discuss in detail in the following section, and the IP Control Protocol (8021). This last protocol is called by PPP when a link is first activated in order to configure the IP-level connection between the IP-capable devices on each end of the link (see below). 
• Information. This field contains the encapsulated packet (data) that is being sent by an upper-layer protocol (for example, IP) over the PPP link. The default maximum length of the information field is 1,500 bytes, although this can be changed when the link is first configured, as discussed below. 
• Checksum. The checksum field is used to detect bit errors in a transmitted frame. It uses either a two or four byte HDLC-standard cyclic redundancy code.

Before closing our discussion of PPP framing, let us consider a problem that arises when any protocol uses a specific bit pattern in a flag field to delineate the beginning or end of the frame. What happens if the flag pattern itself occurs elsewhere in the packet? For example, what happens if the flag field value of 01111110 appears in the information field? Will the receiver incorrectly detect the end of the PPP frame? 

One way to solve this problem would be for PPP to forbid the upper-layer protocol from sending data containing the flag field bit pattern. The PPP requirement of transparency discussed above obviates this possibility. An alternate solution, and the one taken in PPP and many other protocols, is to use a technique known as byte stuffing.

PPP defines a special control escape byte, 01111101. If the flag sequence, 01111110 appears anywhere in the frame, except in the flag field, PPP precedes that instance of the flag pattern with the control escape byte. That is, it "stuffs" (adds) a control escape byte into the transmitted data stream, before the 01111110, to indicate that the following 011111110 is not a flag value but is, in fact, actual data. A receiver that sees a 01111110 preceded by a 01111101 will, of course, remove the stuffed control escape to reconstruct the original data. Similarly, if the control escape byte bit pattern itself appears as actual data, it too must be preceded by a stuffed control escape byte. Thus, when the receiver sees a single control escape byte by itself in the data stream, it knows that the byte was stuffed into the data stream. A pair of control escape bytes occurring back to back means that one instance of the control escape byte appears in the original data being sent. Figure 5.43 illustrates PPP byte stuffing. (Actually, PPP also XORs the data byte being escaped with 20 hexadecimal, a detail we omit here for simplicity.) 

5.8.2: PPP Link Control Protocol (LCP) and Network Control Protocols

Before any data is exchanged over a PPP link, the two peers (one at each end of the PPP link) must first perform a considerable amount of work to configure the link, in much the same way that a TCP sender and receiver must perform a three-way handshake (see Section 3.5) to set the parameters of the TCP connection before TCP data segments are transmitted. Figure 5.44 illustrates the state transition diagram for the LCP protocol for configuring, maintaining, and terminating the PPP link. 

The PPP link always begins and ends in the dead state. When an event such as a carrier detection or network administrator intervention indicates that a physical layer is present and ready to be used, PPP enters the link establishment state. In this state, one end of the link sends its desired link configuration options using an LCP configure-request frame (a PPP frame with the protocol field set to LCP and the PPP information field containing the specific configuration request). The other side then responds with a configure-ack frame (all options acceptable), a configure-nak frame (all options understood but not acceptable) or a configure-reject frame (options not recognizable or not acceptable for negotiation). LCP configuration options include a maximum frame size for the link, the specification of an authentication protocol (if any) to be used, and an option to skip the use of the address and control fields in PPP frames. 

Once the link has been established, link options negotiated, and the authentication (if any) performed, the two sides of the PPP link then exchange network-layer-specific network control packets with each other. If IP is running over the PPP link, the IP control protocol [RFC 1332] is used to configure the IP protocol modules at each end of the PPP link. IPCP data are carried within a PPP frame (with a protocol field value of 8021), just as LCP data are carried in a PPP frame. IPCP allows the two IP modules to exchange or configure their IP addresses and negotiate whether or not IP datagrams will be sent in compressed form. Similar network-control protocols are defined for other network-layer protocols, such as DECnet [RFC 1762] and AppleTalk [RFC 1378]. Once the network layer has been configured, PPP may then begin sending network-layer datagrams--the link is in the opened state and data has begun to flow across the PPP link. The LCP echo-request frame and echo-reply frame can be exchanged between the two PPP endpoints in order to check the status of the link. 

The PPP link remains configured for communication until an LCP terminate-request packet is sent. If a terminate-request LCP frame is sent by one end of the PPP link and replied to with a terminate-ack LCP frame, the link then enters the dead state. 

In summary, PPP is a data-link layer protocol by which two communicating link-level peers, one on each end of a point-to-point link, exchange PPP frames containing network layer datagrams. The principal components of PPP are: 

• Framing. A method for encapsulating data in a PPP frame, identifying the beginning and end of the frame, and detecting errors in the frame. 
• Link-control protocol. A protocol for initializing, maintaining, and taking down the PPP link. 
• Network-control protocols. A family of protocols, one for each upper layer network protocol, that allows the network-layer modules to configure themselves before network-level datagrams begin flowing across the PPP link.