Register your product to gain access to bonus material or receive a coupon.
PPP Design and Debugging
- By James D. Carlson
- Published Dec 19, 1997 by Addison-Wesley Professional.
Book
- Sorry, this book is no longer in print.
Description
- Copyright 1998
- Dimensions: 7-3/8x9-1/4
- Pages: 240
- Edition: 1st
- Book
- ISBN-10: 0-201-18539-3
- ISBN-13: 978-0-201-18539-3
| Second Edition now available! |
This convenient volume follows PPP through its three main functions: connecting, authenticating, and sending data to the network. It provides an overview of PPP design and operation‹including link-level transmission and reception of data‹as well as a look at how PPP works with other networking protocols. Each PPP protocol is described in depth, including: LCP (Link Control Protocol); the network layer protocols that communicate with IP, AppleTalk, SNA, OSI, and others; CCP (Compression Control Protocol) and ECP (Encryption Control Protocol). In addition, the increasingly important topic of bandwidth management is discussed.
You will find thorough coverage of PPP debugging techniques that show you how to isolate and solve connection problems. In particular, the book examines a topic of critical concern: how to get packet traces out of common PPP implementations. Plenty of code, implementation strategies, and expert advice throughout make this book an invaluable resource for anyone who works with PPP.
0201185393B04062001
Sample Content
Table of Contents
1. Introduction.
2. PPP Communication Basics.
3. Negotiation, LCP, and Authentication.
4. The Network Layer Protocols.
5. The Transforming Layers.
6. Bandwidth Management.
7. Interpreting Traces.
8. Resources.
Appendix A: AHDLC Implementation.
Appendix B: MP Fragmentation.
Appendix C: PPP RFCs.
Appendix D: Decimal, Hexadecimal, Octal, and Standard Characters.
Index.
Acknowledgments.
Introduction
I hate quotations. Tell me what you know.
- Ralph Waldo Emerson
IN THIS CHAPTER
When most users today think of Point-to-Point Protocol (PPP), they probably think of personal computers
(PCs), modems, and surfing the Internet. PPP, though, is a much broader protocol that is used to transfer
data among diverse kinds of computers and computing systems, such as routers, satellites, and
mainframes. This one protocol has the ability to span from the lowest to the highest data rates in use and is
compatible with almost every networking technology ever developed.
This book covers PPP from the bits and bytes transmitted up through the connections to other networking software. Along the way, it gives guidance in the often confusing array of standards documents and tips for debugging PPP connections and implementations.
It does not give specific details on particular interfaces, such as modem drivers, since these are both quite numerous and also well covered in other books. Nor does it pretend to replace the "Request For Comments" documents (RFCs), as these are both easily available and very detailed. Instead, this book works as a companion alongside the operating system reference works of your choosing and the public documents.
There have been several waves of advancement in computing techniques, though these advances have hardly been linear. In fact, the pattern for most of these advances is quite regular, and repeats often. The first advancements are often made by the mainframe computer users. Then these are either rediscovered or borrowed by minicomputer users and, finally, by microcomputer users. Each generation leaves its own mark on the technology, but the pattern remains the same.
The history of machine-to-machine communication is similar to the development of computing in general. Mainframe communications (primarily the International Standards Organization's (ISO's) X.25 and International Business Machine's (IBM's) Systems Network Architecture (SNA)) developed many of the concepts important to networking in general, such as routing and layering, in the 1960s. This technology was reinvented by the minicomputer users in the 1970s as TCP/IP (Transmission Control Protocol/Internet Protocol) and XNS (Xerox Network Systems), and once more in the 1980s by the microcomputer users as IPX (Internet Packet Exchange; actually just a copy of XNS) and AppleTalk. Of course, not all of these developments are equal, and both X.25, which is limited to a few media types, and IPX, which is used with only a minority of operating systems, are falling from favor as TCP/IP and the global Internet gain ground. For most Unix computers, this communication began with a series of protocols called UUCP (Unix-to-Unix Copy), which eventually developed into a robust and widespread automatic file and electronic mail (email) transfer protocol. Much of what people now refer to as "the Internet," including the bulletin board-like news groups known as "usenet" and email, was actually developed using this automated file transfer protocol.
For small computers, communication began with file transfer protocols, like Ward Christiansen's X Modem. This simple protocol allowed two computers to exchange a single file at a time using a simplex protocol. Later innovations, like Chuck Forsberg's Z Modem, extended this idea for higher speed by omitting the positive acknowledgments used in a traditional simplex protocol and reporting only negative acknowledgments, at the expense of protocol resilience in the face of congestion and buffering.
At the same time, others were developing protocols for both the new PCs and larger computers, like Kermit and BLAST (Blocked Asynchronous Transmission), that borrowed the networking concept of windowing. Windowing permits a set number of acknowledgments to remain outstanding at a given time, thus mitigating the effects of transmission buffering, latency, and occasional data corruption. Notably among these, Columbia University's Kermit also permitted remote execution of commands via extensions to the file transfer protocol.
All of these file transfer protocols are asymmetric. One side, usually called a client, requests actions, such as the transferring of a file, and the other side, called a server, performs the requested actions. This design is therefore known as client/server.
Meanwhile, in the Unix world, TCP/IP began gaining ground against the file transfer protocols faster than the supporting telecommunications technologies developed. Although 3MB and then 10MB Ethernets were available for local networks, the primary means of communicating over distance was through the use of primitive modems. To make use of these, a simple protocol called SLIP (Serial Line Internet Protocol) was developed at the University of California at Berkeley. This protocol is easily described by saying that a raw IP datagram is first expanded by replacing any byte equal to hexadecimal C0 with the sequence DB DC and any byte equal to DB with DB DD; then it is transmitted with C0 at either end as framing. This process is easily reversed at the other end of the link, and if the data are ever corrupted, synchronization can always be achieved by looking for the next C0, since this will never occur in the user's data. RFC 1055, which documents SLIP, is only six pages long. Also note that this protocol requires a hardware link that can transmit arbitrary 8-bit bytes without modification.
SLIP's architecture is fundamentally different from the file transfer protocols developed on microcomputers and others in use on minicomputers running Unix. First, notice that it is not at all obvious from the description given how one would send email over it, or even transfer a file between two computers, even though the description given is complete. With SLIP, all that you are given is a means to transmit packets from one computer to another over a serial line.
In the networking world, this difference is called layering. In the old file transfer programs, the definitions of the protocols included such things as detecting the start of the data, detecting errors, and signaling the file name to the receiver all in the same protocol. With networking, there are instead application programs (such as file transfer) that use the services of transport protocols (such as TCP), which in turn run on network protocols (such as IP), and finally on top of link-level protocols (such as SLIP). Each of these protocols is separate and is described in a separate document.
There are many advantages to this technique, including the ability to use old applications on the latest network devices and the ability to develop and migrate between networking protocols and applications without disturbing the link layer. This means that the design and development of each part of the system can continue independently, unlike with more primitive file transfer protocols, which required a complete rewrite to support enhanced error-control algorithms or new media types.
Notice also that unlike the client/server file transfer protocols, SLIP is inherently symmetric. Neither side is defined to be the client or the server. Such protocols, are termed peer-to-peer, since both sides of the link are equal parties to the conversation and both may request and perform actions.
PPP owes much to SLIP, although it also uses transmission techniques developed for mainframes. The marketplace for dial-up Internet connectivity, which has driven much of the development work on PPP, would not exist if it were not for SLIP, and many of the important algorithms in use with PPP were first developed for SLIP.
Unlike many of the other so-called standards of the microcomputer and minicomputer world, including SLIP, PPP was developed by a standards body. The Internet Engineering Task Force (IETF), which has guided PPP development, is made up of representatives from industry, telecommunications, academia, and user groups. It is an open group; anyone with an interest in setting the standards is free to participate.
The rules of the IETF are a little different from other standards bodies, such as the International Telecommunications Union (ITU) and the International Standards Organization (ISO). The IETF has fostered a culture in which it is far more important to produce a working protocol than it is to produce documents with which all participants agree. Unlike the other standards bodies, IETF participants commonly discuss their prototype implementations and experimental results at the same time the protocols are being written.
This environment produces specifications that are usually rather brief but very dense in subject matter and documentation that is scattered among a large number of documents that do not necessarily refer to each other. It also occasionally produces experiments that turn out to be dead ends. One of the aims of this book is to tie all of these documents together for PPP and illustrate some of the important but unwritten concepts.
PPP, like all other network protocols, exists as a layer between two other layers of the protocol stack. Below it is the hardware interface, which must be some kind of bidirectional data stream, and above it are the network-layer protocols, such as IP and IPX. These are illustrated diagrammatically in Figure 1.1. PPP borrows part of high-level data link control (HDLC) from the telecommunications world for its low-level interface, though it restricts the feature set usable in a conforming implementation, and it extends the protocol to run over asynchronous serial lines. In running over serial lines, it borrows SLIP's "escape" mechanism, which is also common in the old file transfer programs like Z Modem and Kermit, and allows it to run on hardware that cannot properly deal with certain byte sequences. It does not, though, go so far as to define sequences that would allow it to be run on hardware that cannot transfer full 8-bit bytes, as do Kermit and Z Modem.
Thus, on the hardware interface, we have this set of features and limitations for synchronous lines:
- Can be used with standard HDLC controllers.
- Defined only for point-to-point links; any kind of multidrop usage is a proprietary extension due to
- address restrictions.
- Can coexist with other HDLC-based protocols on the same link only if the other protocols are
- restricted in address usage.
- Can be run on lines that use software flow control and are unable to transfer some binary values.
- Cannot be run on lines that do not support full 8-bit bytes without proprietary extensions.
- Defines error-detection mechanisms that are as strong as those used by HDLC.
For the network-layer protocols, PPP presents a packet-oriented interface, and it can provide sequencing and reliability if needed.
PPP also connects to the world through relationships with certain applications that provide services for PPP in an implementation-dependent manner. For instance, a dial-up communications server may need to use RADIUS (Remote Authentication Dial-In User Service), TACACS (Terminal Access Controller Access Control System), or ACP (Access Control Protocol) to verify the dial-up peer's identity or obtain network addresses for negotiation. It also may have relationships with logging devices, to track errors, and with encryption key servers, for secure communications.
Throughout this book, data values are given in hexadecimal unless otherwise noted. Equivalences for these values in decimal and octal are given in Appendix D.