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]:
-
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.
5.8.1 PPP Data Framing
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.
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).
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:
-
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
[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