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]:
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.
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:
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.
Having now considered the design goals )and non-goals) for
PPP, let us see how the design of PPP met these goals.
Figure 5.8-1 shows a PPP data frame using HDLC-like framing [RFC 1662].
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.
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).
Figure 5.8-2: byte stuffing
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
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-reply packet can be exchanged
between the two PPP endpoints in order to check the status of the
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
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.
Copyright Keith W. Ross and Jim Kurose 1996–1999