5.8 PPP: the point-to-point protocol

Most of our discussion of data link protocols thus far has focused on protocols for broadcast channels.  In this section we cover a data link protocol for point-to-point links - PPP, the Point-to-Point protocol.  Because PPP is typically the protocol of choice for a dialup link from residential hosts, it is undoubtedly one of the most widely-deployed data link protocols today.  The other important data link protocol in use today is the HDLC (High Level Data Link Control) protocol; see [Spragins 1991] for a discussion of HDLC. Our discussion here of the simpler PPP protocol will allow us to explore many of the most important features of point-to-point data link protocol.

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 connecting two communicating link-level peers, one on each end of the link   The point-to-point  link over which PPP operates might be a serial dialup telephone line (e.g., a 56K modem connection), a SONET/SDH link, an X.25 connection, or over an ISDN circuit. An noted above, PPP has become the protocol of choice for connecting home users to their ISP's 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]:

While it may appear that many requirements were placed on the design of PPP, the situation could actually have been much more difficult!  The design specifications for PPP also explicitly note protocol functionality that was PPP was not required to implement: Having now considered the design goals )and non-goals) for PPP, let us see how the design of  PPP met these goals.
 

5.8.1 PPP Data Framing

Figure 5.8-1 shows a PPP data frame using HDLC-like framing [RFC 1662].
PPP frame format
Figure 5.8-1: PPP data frame format

The PPP frame contains the following fields:
 

Byte Stuffing

Before closing our discussion of PPP framing, let us consider a problem that arises when any protocol uses a specific bit pattern (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 see 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.8-2 illustrates PPP byte stuffing. (Actually, PPP also XORs the data byte being escaped with 20 hexadecimal, a detail we omit here for simplicity).

Byte stuffing example
Figure 5.8-2: byte stuffing

5.8.2 PPP Link Control Protocol (LCP) and network control protocols

Thus far, we have seen how PPP frames the data being sent over the point-to-point link.  But how does the link get initialized when a host or router on one end of the PPP link is first turned on?  The initialization, maintenance, error reporting, and shutdown of a PPP link is accomplished using PPP's Link Control Protocol (LCP) and family of PPP 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 threeway handshake (see Section 3.4) to set the parameters of the TCP connection before TCP data segments are transmitted. Figure 5.8-3 illustrates the state transition diagram for the LCP protocol for configuring, maintaining and terminating the PPP link.


Figure 5.8-3: PPP Link Control Protocol

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 the 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 packets are carried within a PPP frame (with a protocol field value of  8021), just as LCP packets 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 packets will be set 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 packet and echo-reply packet 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 packet is sent by one end of the PPP link and replied to with a terminate-ack LCP packet, 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:

References

[RFC 1332] G. McGregor, " The PPP Internet Protocol Control Protocol (IPCP),"  RFC 1332, May 1992.
[RFC 1378]  B. Parker, "The PPP AppleTalk Control Protocol (ATCP)," RFC 1378,. November 1992.
[RFC 1547] D. Perkins, "Requirements for an Internet Standard Point-to-Point Protocol," RFC 1547, December 1993.
[RFC 1661] W. Simpson (ed.), "The Point-to-Point Protocol (PPP), " RFC 1661, July 1994.
[RFC 1662] W. Simpson (ed.), "PPP in HDLC-like framing," RFC 1662, July 1994.
[RFC 1700] J. Reynolds, J. Postel, "Assigned Numbers," RFC 1700, October 1994.
[RFC 1762] S. Senum, "The PPP DECnet Phase IV Control Protocol (DNCP)," RFC 1762, March 1995.
[RFC 2153] W. Simpson, "PPP Vendor Extensions," RFC 2153, May 1997.
[Spragins 1991]  J. D. Spragins, Telecommunications protocols and design , Addison-Wesley (1991).
 


Copyright Keith W. Ross and Jim Kurose 1996-1999