The Point-to-Point Protocol (PPP) is a data link layer protocol which encapsulates other network layer protocols for transmission on synchronous and asynchronous communication lines.

Two precise definitions of "point-to-point" in the context of data communications follow:

1. A network configuration in which a connection is established between two, and only two points. The connection may include switching facilities.

2. A circuit connecting two points without the use of any intermediate terminal or computer.1Technical Aspects of Data Communication (3rd ed. Digital Press, 1988) p. 355.

This definition explains the point-to-point aspect of PPP. The protocol aspect lies in the fact that PPP is the intermediate packet structure which facilitates transmission of higher level protocols, such as TCP/IP, across diverse communication links.

PPP was first proposed as an Internet standard in the early 1990's by a working group of the Internet Activities Board's Internet Engineering Task Force (IETF).2Network World April 2, 1990: 2. The original purpose was to allow one uniform, standardized way to encapsulate the IP Protocol for point-to-point communications in a mixed environment of varying vendors and devices.

Many of the original proponents of the PPP protocol were router vendors who found that the many existing data link protocols used to envelop transport protocols were proprietary in nature. Hence, internetwork connectivity was difficult and limited. In particular, router vendors could not interoperate over serial dial-up or leased lines because no standard for high-speed synchronous communications had yet been defined.3

Today the PPP protocol standard finds wide use in asynchronous and synchronous connections between computers, bridges, routers, and other intermediate devices. PPP is gaining acceptance as a standard for Integrated Services Digital Network (ISDN), and many implementations of X.25 also support PPP connections.

DESIGN GOALS

(Improvements over SLIP)

RFC 1171, "The Point-to Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links," was the original RFC in response to the IETF working group proposal for PPP. This RFC defined PPP in terms of three major components:

1. A method for encapsulating datagrams over serial links.

2. An extensible Link Control Protocol(LCP).

3. A family of Network Control Protocols(NCPs) for establishing and configuring different network layer protocols.4

Encapsulating datagrams was not new to the networking world, but establishing a standard to do so was new and was needed. Up to this point Serial Line IP (SLIP) had established itself as a defacto standard of sorts. Many users were able to connect their home computer to the Internet using SLIP through an RS-232 serial port and connected modem. SLIP was originally implemented in 1984.

But SLIP is a very simple implementation of encapsulation for IP datagrams. Some of the drawbacks of SLIP include:

1. Operator intervention is required during connection, since SLIP cannot automatically communicate IP addresses during link initialization.

2. SLIP uses only one protocol at a time over a serial link.

3. SLIP does not perform any error checking for frames corrupted in transmission. Error checking is normally implemented as a check sum in PPP, but SLIP has no checksum.5TCP/IP Illustrated, Volume 1, The Protocols (Reading, MA: Addison-Wesley, 1994) 24.

PPP addresses these shortcomings of SLIP and more. PPP can assign and manage IP addresses. PPP is much better suited for high speed synchronous links6, and it is more adaptable to circuit switched networks.7 PPP can encapsulate more than one protocol in a given session, and it can keep active links over each of the multiple protocols.

PPP adds the Link Control Protocol to perform other functions missing in SLIP. Using the LCP, PPP has the ability to verify whether the line has a good enough quality to reliably support the connection. After the LCP component of PPP establishes the link, then the NCP component will negotiate the network layer protocol that PPP actually encapsulates and transports. For example, if the PPP link is configured to connect with IP, then the Internet Protocol Control Protocol (IPCP) will negotiate and configure the link to carry IP.8Data Link Protocols (Englewood Cliffs, NJ: PTR Prentice Hall, 1993) 243-244. An NCP, such as IPCP, may close the link over the network layer protocol, and yet the PPP connection can remain open. But if LCP closes the link, then all communication layers terminate, including the network layer, NCP fraffic, and the PPP connection itself.

Using LCP, "PPP can termintate the link at anytime. This might happen because of the loss of carrier, authentication failure, link quality failure, the expiration of an idle-period timer, or the admintrative closing of the link."9

Finally, PPP includes a method for error checking. Two trailing bytes of the PPP frame perform a cyclical redundacy check (CRC), or as it is also known: a frame check sequence (FCS).

In summary, the most important improvements of PPP in comparison to SLIP are:

1. The ability to dynamically negotiate IP addresses.

2. The ability to transport multiple protocols on a single serial connection.

3. The addition of a Link Control Protocol to establish link options.

4. The addition of network control protocols to negotiate the choices of network layer protocols.

5. The addition of error checking for each PPP frame.

TECHNICAL OVERVIEW

The correct understanding of PPP involves considering where it resides in the wider classification of data link protocols. Data link protocols may be grouped into three broad categories depending on the packet framing method associated with the given protocol. The three types are character-oriented, byte count-oriented, and bit-oriented. Character oriented protocols use special characters to delimit the packet frame structure. An example of this type of protocol is IBM's Binary Synchronous Communications Protocol, or BISYNC.

Byte count-oriented protocols identify the packet structure with a special character in the beginning followed by a count of the bytes for the data part of the packet. Kermit is an example of this type of protocol.

PPP uses the third type, the bit-orineted protocol. This protocol identifies the beginning and end of a packet with a specialized sequence of bits called a flag character. Suppose you specify that no bit pattern shall have more than six "1" bits in a row unless it is a flag character. So the bit pattern of 01111110 will always specify a flag, and this flag will always delimit the beginning and the end of a packet. The High (level) Data Link Control (HDLC) protocol as specified by the International Standards Organization (ISO) uses beginning and ending flags exactly as described above.10

PPP is one of many derivative protocols from HDLC. HDLC is defined by a number of ISO specifications: notably the documents ISO 3309, ISO 4335, and ISO 7809 among others. The following is a listing of some of the most important implementations of HDLC (with the technology they support in parentheses): LAPB(x.25), LAPD(ISDN), LAPX(TELETEX), PPP(many technologies), SDLC(SNA). Frame relay is also a derivative of HDLC, but frame relay does not support an overlying network layer.11

The consequence of PPP's relationship to HDLC is that the basic packet structure of PPP resembles very closely the structure of the HDLC packet.

In HDLC terms the data packet transmitted across the link is called a frame, and a frame will consist of the following elements:

1 Black, 104.

PPP adds one significant field to its frame, the protocol field that appears after the control field and before the information field. Hence, the PPP frame structure looks like this:

Notice that some of these values are fixed:

• The flag field always has the HDLC pattern of

  01111110 (Hex7e).

• The address field is all ones to signify all stations:

  11111111(Hex ff).

• The control field signifies the HDLC unnumbered information command with a fixed value of:

  00000011 (Hex 03).

The protocol field is two bytes long and identifies the protocol data unit (PDU) that the PPP frame has encapsulated. The following table shows some of the values that may be assigned to the protocol field. The values are sub-classified according to the hexadecimal values of 0, 8, and "C" appearing in the first octet. If the first octet begins with zero (0), then this octet identifies the protocol in the information field. If the first protocol octet begins with an eight (8), then the octet identifies a control protocol that will negotiate the actual network protocol to be used over the link. If the protocol octet begins with the hexadecimal number "C", then the protocol field indicates that a Link Control Protocol is encapsulated in the information field of this frame.12

Protocol Field Values (Hex)

On the packet level a PPP connection, or link operation, takes place through an exchange of requests and acknowledgments between the two end points of the connection. First the LCP sends requests and acknowledgments to open the link. The network control protocols (NCPs) negotiate which network layer protocol will be used over the link. When that negotiation is complete, the link carries the network layer session in which the two end points exchange high level protocol packets.

The diagram below shows a very simplified version of how such a link operation might take place. The exchange of information is depicted in time from the top so that first LCP sets up the link, and then the NCP negotiates the protocol. In this example, the NCP is the IP Control Protocol (IPCP). After the transfer of data at the network layer completes, LCP terminates the link.

Notice that NCP only terminates the network layer and NCP link. In this case the PPP link remains up. If LCP had terminated the session, the PPP link would be terminated also.

The actual details of establishing and maintaining the link are a very much more complex interaction of some thirteen events whose effect may result in one of ten different states in the link. The list of

possible states follow:

1. Initial

2. Starting

3. Closed

4. Stopped

5. Closing

6. Stopping

7. Request-Sent

8. Ack-Received

9. Ack-Sent

10. Opened

To illustrate the interaction between an event and a state, suppose the event Active Open occurs, and this event occurs against the link state of Closed. The resultant state of the link will be Request-Sent. A complete table defining the interaction of the PPP link events and states may be found in RFC 1661.14

LPC DETAILS

LPC serves as a useful example of how a control protocol can be encapsulated in a PPP frame. To understand this encapsulation better, we need to take a closer look at the structure of LPC in relationship to the PPP frame as a whole

Link Control Protocol (LCP) Packet

Each LCP packet has a specific function in the exchange of configuration information depending on its packet type. The code field of the LCP packet identifies the packet type according to this table:

1 Perkins, 20.

The identifier byte keeps track of matching requests and replies.

This byte can be thought of as the packet sequence ID. The length byte indicates the total length of the LCP packet to include the code, identifier, length, and data/options fields.15

Interestingly the options field has a format of its own as shown below:

The one byte type field specifies the LCP configuration option according to this table:

1 Simpson RFC 1548, 40

The length field shows the length of this configuration option to include the type, length, and data fields. The data field may be variable in length.

A PRACTICAL ILLUSTRATION

To show the usefulness of our previous study, let's examine just a few lines from a Windows NT PPP log file. Such a log file will be generated during a Windows NT Remote Access Service (RAS) session if you configure the appropriate option in the Windows NT Registry. To enable PPP logging set the Logging parameter to 1 in the following Registry location:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RasMan \PPP

You can get more detailed and useful information if you set this parameter to verbose mode using the value of 2. The PPP log will then be recorded in the following location on your hard disk:

%SYSTEMROOT%\SYSTEM32\RAS\PPP.LOG

Consider these lines from such a log:

The log record plainly shows that a packet was sent, that the packet was an LCP packet, and that the packet type is a configuration request.16
Notice also the third line of cryptic hexadecimal numbers. This is where our knowledge of PPP and LPC packet structure will help.
Observe that each pair of characters represents one byte. So let's number off the bytes from left to right. As we analyze the bytes, let's group them according to the fields in the PPP frame and the LCP packet structure.
Bytes 1-2: C0 21

Notice this information begins with the protocol field of the PPP frame. From the previously listed table of protocol field values, we know that C0 21 designates an LPC packet.
Byte 3: 01

This is the code byte of the LPC packet. From the LPC code table above, 01 identifies a Configure-Request.
Byte 4: 00

This is the packet sequence number. In this case the number is zero since it is the first frame sent.
Byte 5-6: 00 0A

This is the length field of the LPC packet, and it shows ten bytes as the total length of the LPC packet. Notice this excludes the two bytes of the protocol field identifier. The "Length" value in the first line includes the protocol field so its value is twelve.
Byte 7: 02

This is the type field for the options section of the LCP packet. Type 2 designates an Async-Control-Character-Map. Please refer to RFC 1548, pages 41-42 to learn more about this option.
Byte 8: 06

This is the length for this option for a total of six bytes.
Bytes 9-12: 00 00 00 00

The values are all set to zero. This is the default signifying no mapping is needed for any control characters.
Naturally, complete PPP logs are much more extensive than these few lines, but the important point here is the method we used to decipher the PPP log. Our understanding of the PPP frame structure and the structure of encapsulated protocol data unit (PDU), helped us to read information from a very useful troubleshooting tool, the Windows NT RAS PPP log.