5.8 PPP: the point-to-point 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]:

• Packet framing.  The PPP protocol data link layer sender must be able to take a network-level packet and frame (a.k.a  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 can not forbid the use of certain bit patterns in the network layer packet.  We'll return this issue shortly in our discussion of byte stuffing below.
• Multiple network layer protocols. The PPP protocol must be able to support multiple network layer protocols (e.g., 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 (e.g., 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 (e.g., the inability to transfer data from the sending side of the link to the receiving side of this link) and signal this error condition to the network layer.
• Network Layer Address Negotiation.  PPP must provide a mechanism for the communicating network layers (e.g., IP) to learn or configure each other's network layer address.
• Simplicity. PPP was required to meet a number of additional requirements beyond the seven 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 RFC's 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 can not 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 which 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 (e.g., HDLC) can accommodate multiple receivers (e.g., an Ethernet-like scenario) on a link.

5.8.1 PPP Data Framing

Figure 5.8-1: PPP data frame format

The PPP frame contains the following fields:
 

• Flag field. Every PPP frame begins and ends with a 1 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 firstplace.  The PPP specification [RFC 1622] 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 (i.e., 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 are the IP protocol (i.e., 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) which is called by PPP when a link is first activated in order to configure the IP-level connection between the two  routers on each end of the link (see below).
• Information.  This field contains the encapsulate packet (data)  that is being sent by an upper layer protocol (e.g., IP) over the PPP link.  The default maximum length of the information field is 1500 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.

Byte Stuffing

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).

Figure 5.8-2: byte stuffing

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 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:

• 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.

References

Copyright Keith W. Ross and Jim Kurose 1996-1999