Dial-Up Networking
In the recent past, one of the most common methods for connecting to a TCP/IP network such as the Internet was through a phone line. Over the last few years, broadband techniques such as cable modems and DSL have reduced the importance of dial-up networking, but many computers still support dial-up connections, and the telephone modem is still an important connectivity tool in many areas.
A modem provides network access through a phone line. The term is short for MOdulate/DEModulate. Engineers created modems because the industry saw the enormous benefit of providing a way for computers to communicate over the world’s most accessible transmission medium: the global telephone system. Telephone lines have grown more sophisticated in recent years. Some lines are now capable of transmitting digitized data; other lines are not. In any case, even digital telephone systems are not designed to automatically handle a network protocol like TCP/IP. The purpose of a modem is to transform the digital protocol transmissions from a computer into an analog signal that can pass through the interface with the phone system and to transform incoming analog signals from the phone line into a digital signal that the receiving computer understands.
Point-to-Point Connections
As you learned in Hour 3, “The Network Access Layer,” local networks such as ethernet employ elaborate access strategies for enabling the computers to share the network medium. By contrast, the two computers at either end of a phone line do not have to compete for the transmission medium with other computers—they have to share it only with each other. This type of connection is called a point-to-point connection (see Figure 9.1).
Figure 9.1. A point-to-point connection.
A point-to-point connection is simpler than a LAN-based configuration because it doesn’t have to provide a means for multiple computers to share the transmission medium. At the same time, a connection through a phone line has some limitations. One of the biggest limitations is that transmission rates over a phone connection are much slower than rates over a LAN-based network such as ethernet. This reduced transmission speed lends itself to a protocol that minimizes the data overhead of the protocol itself—less is better. As you learn in this hour, as modems have become faster, modem protocols have taken on additional responsibilities.
Another challenge of dial-up protocols is the great diversity of hardware and software configurations they must support. On a local network, a system administrator oversees and controls the configuration of each computer, and the protocol system depends on a high degree of uniformity among the communicating devices. A dial-up connection, on the other hand, can occur from almost anywhere in the world. Dial-up protocols must contend with a wider and more varied range of possibilities regarding the hardware and software of the communicating machines.
Modem Protocols
You might wonder why this point-to-point connection, with its two computers, even needs the complication of the TCP/IP stack to make a connection. The simple answer is that it doesn’t.
Early modem protocols were merely a method for passing information across the phone line, and in that situation, the logical addressing and internetwork error control of TCP/IP were not necessary or even desirable. Later, with the arrival of local networks and the Internet, engineers began to think about using a dial-up connection as a means of providing network access. The first implementations of this remote network access concept were an extension of earlier modem protocols. In these first host dial-up schemes, the computer attached to the network assumed all responsibility for preparing the data for the network. Either explicitly or implicitly, the remote computer acted more like a terminal (see Figure 9.2), directing the networked host to perform networking tasks and sending and receiving data across the modem line through an entirely separate process.
Figure 9.2. An early host-dial-up configuration.
However, these early host dial-up schemes had some limitations. They reflected an earlier, centralized model of computing that placed huge demands on the computer providing the network access. (Imagine the configuration in Figure 9.2 with several computers simultaneously connected to the dial-up server.) They also made inefficient use of the processing power of the remote computer.
As TCP/IP and other routable protocols began to emerge, designers began to imagine another solution in which the remote computer would take more responsibility for networking tasks, and the dial-up server would act more like a router. This solution (shown in Figure 9.3) was more consistent with the newer, less centralized paradigm of computer networks and also closer to the true nature of TCP/IP. In this arrangement, the remote computer operates its own protocol stack, with the modem protocol(s) acting at the Network Access layer. The dial-up server accepts the data and routes it to the greater network.
Figure 9.3. A true TCP/IP dial-up connection.
Dial-up protocols, therefore, began to work directly with TCP/IP and became an integral part of the stack. The two most common TCP/IP modem protocols are
Serial Line Internet Protocol (SLIP)— An early TCP/IP-based modem protocol, SLIP was simple and therefore had some limitations.
Point-to-Point Protocol (PPP)— Currently the most popular protocol for modem connections, PPP began as a refinement of SLIP. It offers many important features that weren’t available with its predecessor.
PPP has replaced SLIP as the method of choice for dial-up Internet connections. The following sections take a closer look at PPP.
By the Way
Both SLIP and PPP are built on lower-level serial communication protocols that see to the details of actually modulating and demodulating the signal. These serial communication protocols provide what would be considered OSI Physical layer functions.
Point-to-Point Protocol (PPP)
When industry experts began to design the PPP standard, they had a much better idea of what features would be useful for the emerging Internet. They also knew that modems and phone lines were getting faster and could support a greater amount of protocol overhead. PPP was an effort to address some of the shortcomings of SLIP.
The designers of PPP also wanted PPP to be capable of dynamically negotiating configuration settings at the beginning of a connection and to be capable of managing the link between the communicating computers throughout the session.
How PPP Works
PPP is actually a collection of protocols that interact to supply a full complement of modem-based networking features. The design of PPP evolved through a series of RFCs. The current PPP standard is RFC 1661; subsequent documents have clarified and extended PPP components. RFC 1661 divides the components of PPP into three general categories:
A method for encapsulating multiprotocol datagrams— SLIP and PPP both accept datagrams and prepare them for the Internet. But PPP, unlike SLIP, must be prepared to accept datagrams from more than one protocol system.
A Link Control Protocol (LCP) for establishing, configuring, and testing the connection— PPP negotiates configuration settings and thus eliminates compatibility problems encountered with SLIP connections.
A family of Network Control Protocols (NCPs) supporting upper-layer protocol systems— PPP can include separate sublayers that provide separate interfaces to TCP/IP and to alternative suites, such as IPX/SPX.
The following sections discuss these components of PPP.
PPP Data
The primary purpose of PPP (and also SLIP) is to forward datagrams. One challenge of PPP is that it must be capable of forwarding more than one type of datagram. In other words, the datagram could be an IP datagram, or it could be some OSI network-layer datagram.
By the Way
The PPP RFCs use the term packet to describe a bundle of data transmitted in a PPP frame. A packet can consist of an IP (or other upper-layer protocol) datagram, or it can consist of data formatted for one of the other protocols operating through PPP. The word “packet” is an often-imprecise term used throughout the networking industry for a package of data transmitted across the network; for the most part, this book has attempted to use a more precise term, such as “datagram.” Not all PPP data packages, however, are datagrams, so in keeping with the RFCs, this hour uses the term packet for data transmitted through PPP.
PPP must also forward data with information relating to its own protocols: the protocols that establish and manage the modem connection. Communicating devices exchange several types of messages and requests over the course of a PPP connection. The communicating computers must exchange LCP packets, used to establish, manage, and close the connection; authentication packets, which support PPP’s optional authentication protocols; and NCP packets, which interface PPP with various protocol suites. The LCP data exchanged at the beginning of the connection configures the connection parameters that are common to all protocols. NCP protocols then configure suite-specific parameters relating to the individual protocol suites supported by the PPP connection.
The data format for a PPP frame is shown in Figure 9.4. The fields are as follows:
Protocol— A one- or two-byte field providing an identification number for the protocol type of the enclosed packet. Possible types include an LCP packet, an NCP packet, an IP packet, or an OSI Network layer protocol packet. ICANN maintains a list of standard identification numbers for the various protocol types.
Enclosed data (zero or more bytes)— The control packet or upper-layer datagram being transmitted with the frame.
Padding (optional and variable length)— Additional bytes as required by the protocol designated in the protocol field. Each protocol is responsible for determining how it will distinguish padding from the enclosed datagram.
Figure 9.4. The PPP data format.
By the Way
If the enclosed data is a datagram of some other protocol suite, it isn’t related to TCP/IP, and you won’t find it discussed in this book.
PPP Connections
The life cycle of a PPP connection is as follows:
1. | The connection is established using the LCP negotiation process. |
2. | If the negotiation process in step 1 specifies a configuration option for authentication, the communicating computers enter an authentication phase. RFC 1661 offers the authentication options Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Additional authentication protocols are also supported. |
3. | PPP uses NCP packets to specify protocol-specific configuration information for each supported protocol suite (for example, TCP/IP or IPX/SPX). |
4. | PPP transmits datagrams received from upper-layer protocols. If the negotiation phase in step 1 includes a configuration option for link quality monitoring, then monitoring protocols will transmit monitoring information. NCP might transmit information regarding specific protocols. |
5. | PPP closes the connection through the exchange of LCP termination packets. |
Link Control Protocol (LCP)
Much of PPP’s power and versatility comes from the LCP functions that establish, manage, and terminate connections. RFC 1661 identifies three types of LCP packets:
Link configuration packets
Link termination packets
Link maintenance packets
Many PPP features that aren’t available with SLIP are a result of LCP. Figure 9.5 describes how LCP configuration packets enable the communicating computers to establish a connection. In Figure 9.5, Computer A sends an LCP Configure-Request packet to Computer B. The Configure-Request packet includes a proposal for any connection parameters Computer A would like to negotiate for the connection. These parameters include the Maximum Receive Unit (MRU), the maximum length for the data enclosed in a PPP frame; the authentication protocol; and the quality control protocol, which defines how the connection monitors for reliable delivery, compression protocol settings, and other configuration choices.
Figure 9.5. An LCP connection configuration.
If Computer B accepts all configuration options submitted in the Configure-Request packet, Computer B responds with a Configure-AcK packet (AcK stands for acknowledge). If all configuration options transmitted with the Configure-Request packet are recognizable but some are not acceptable to Computer B, then Computer B responds with a Configure-NaK packet (NaK stands for not acknowledged) and returns a list of unacceptable parameters with alternative values. Computer A then responds to the Configure-NaK with a new configuration request using adjusted values. This process continues until all values are accepted.
If the Configure-Request packet includes unrecognizable options, Computer B returns a Configure-Reject packet, which lists any unacceptable options.
Figure 9.6 shows the format for an LCP packet. Several other types of LCP packets assist with overseeing the modem connection. The Code field in Figure 9.6 identifies the LCP packet type. The Identifier field identifies the packet and helps to match up requests with acknowledgments. The Length field is the length of the packet. The data transmitted with the packet depends on the type of packet. A list of LCP packet type codes is shown in Table 9.1.
Figure 9.6. LCP packet format.
| Code | Description |
|---|---|
| 1 | Configure-Request |
| 2 | Configure-AcK |
| 3 | Configure-NaK |
| 4 | Configure-Reject |
| 5 | Terminate-Request |
| 6 | Terminate-AcK |
| 7 | Code-Reject |
| 8 | Protocol-Reject |
| 9 | Echo-Request |
| 10 | Echo-Reply |
| 11 | Discard-Request |
As mentioned earlier, LCP tends to maintenance and termination tasks as well as configuration tasks. The Terminate-Request and Terminate-AcK packets request and acknowledge termination of the connection. Code-Reject and Protocol-Reject reject requests for an unknown code or protocol. Echo-Request, Echo-Reply, and Discard-Request provide maintenance, quality assurance, and troubleshooting capabilities.