Until recently, transmission of the Internet (TCP/IP) protocol suite over low bandwidth asynchronous serial lines was a problematic issue, and a major obstacle to the proliferation of this powerful wide area networking tool into end user environments. The advent of PPP in the last half decade has been one of the factors in the explosive growth rate of the Internet in recent years.

The Internet protocol suite, structured around the Internet Protocol (IP), Transmission Control Protocol (TCP) and a large number of ancillary protocols, evolved from US military and academic experience with the original ARPANET. The ARPANET was the forerunner of today's Internet. Based upon the NCP protocols, the installation of the ARPANET began in the late sixties and operational use commenced in 1971. The network was created to provide a wide area networking scheme to support the US military and key US research institutions.

Operational usage of the network revealed many shortcomings in the protocol suite, and a new suite of protocols, based upon IP and TCP, was devised. In 1982, the NCP based routers were decommissioned and the new TCP/IP network brought on line, with the civilian component designated the Internet (running over the NSFnet backbone) and the military component the Milnet.

The Internet protocol suite was capable of spanning both local and wide area networks transparently, and was soon integrated with the interprocess communications scheme in BSD 4 Unix, at that time the preferred operating system in US Universities. This set in place the technological foundation of what we recognise today as the networked open systems environment.

The emerging Unix workstation manufacturers quickly adopted the combination of Unix and TCP/IP and the rest is really recent history. It is worth noting that much of the success of Sun Microsystems derived from their adoption of this technology base in preference to the proprietary networking and OS schemes favoured by other vendors at that time. The much vaunted OSI protocol suite has withered into insignificance in the face of the TCP/IP onslaught, and it is fair to say that whatever shortcomings the Internet suite has, it is technologically more than adequate to its task. Because it has been extensively integrated into virtually all major operating systems, it is the medium of choice in contemporary networking. To choose any proprietary protocols is in this day and age a foolish move indeed.

A major weakness of the Internet suite in its early days was its orientation toward supporting fast channels such as local Ethernets and high bandwidth (eg US T1 or CCITT 2.048M) trunk channels. Routers would carry WAN traffic over fast interfaces and LAN traffic over Ethernet, providing connectivity for large sites, such as academic or military sites. There was initially no mechanism to carry traffic over slow lines, to support small sites or remote satellite sites. The absence of a suitable protocol to support dialup connections was a major obstacle to the proliferation of wide area Internet services to a grass roots level in the Unix community.

The first solution to this problem was the SLIP (Serial Line IP) non-protocol which evolved from 3-COM's early eighties UNET protocol. In 1984 SLIP was implemented for BSD 4.2 Unix, ported to SunOS, and very quickly proliferated into the wider Unix community.

Sadly, SLIP is an improvisation (or better said an ugly kludge) and is really no more than a scheme for framing IP packets. It is not a formally recognised Internet protocol and the RFC (Internet Engineering Task Force (IETF) Request For Comment) document which defines it (RFC1055) in fact describes SLIP as a defacto standard.

While SLIP can carry IP traffic over a serial line, it has some fundamental deficiencies which make it cumbersome to use. The principal of these is its lack of error control mechanisms. All modern link level packet protocols use a checksumming scheme of some variety to detect packets corrupted due noise on the link, and will resend packets which are damaged. This improves robustness significantly, as corrupted packets do not have to be detected by the IP and TCP code layers to be discovered. Unless one is using a reliable error correcting voiceband modem link, single and multiple bit errors in packets are a fact of life, moreso with increasing link speed, and error control is thus an important issue (eg consider the quality of current 64k ISDN links).

The second fundamental limitation of SLIP is its lack of maintenance and control protocols to manage link startup, and negotiate link parameters between hosts at either end of the link. The SLIP implementations at either end of a link must be hard configured to the appropriate settings and left that way.

Despite its fundamental shortcomings, SLIP is still very popular in the wider user community, and its successor, the PPP protocol, has yet to fully replace it in operational use.

PPP - A Technical Overview

The PPP protocol is the official IETF protocol for use on point to point serial links. As it was designed from the outset to support both dialup and hardwired links, it has a range of very effective design features which make it both a robust and versatile protocol. At this time PPP will support synchronous and asynchronous low speed serial lines, high speed serial links, X.25, ISDN and SONET/SDH framing schemes, thus spanning a range of bandwidths from hundreds of bits per second (bps) up to hundreds of Megabits per second (MBps). Because PPP was designed to be transparent to the network protocol supported, it can carry not only IP (Internet) protocol traffic, but also proprietary protocols such as OSI, DECnet, Appletalk and Novell IPX, if these are supported by the implementation in question.

In terms of design philosophy, PPP is much closer in concept to DEC's now obsolete proprietary DDCMP serial link protocol, than its Internet suite predecessor SLIP. PPP shares two central technical themes with the DDCMP protocol, these being the use of an error protected link level framing scheme and the use of a maintenance protocol suite. The implementations are understandably radically different.

The framing scheme used in PPP is simple and robust, and involves encapsulating the IP packet with a HDLC (ISO 3309-1979) frame. HDLC has had a long history, evolving from IBM's SNA standard and eventually becoming a central part of the widespread X.25 packet switch protocol.

The HDLC frame was designed primarily for use over synchronous links, which transparently clock data through bit by bit. To distinguish a frame from noise on the link, frames are delimited by a start and stop sequence of bits, and the contents of the packet inside the frame mangled to ensure that the data cannot contain the same pattern as a start and stop sequence. Each frame is error protected by a 16 or 32 bit Frame Check Sequence, which is a checksum computed with a Cyclic Redundancy Check (CRC) polynomial. When a frame is being sent, the FCS is computed and attached, when it is received, it is calculated again and checked against the received copy. If a discrepancy is found, the frame is trashed (and resent). Because the probability of a bad frame getting through is usually designed to be a million or more times smaller than the probability of any bit in the frame being corrupted, this method is very robust.

Because HDLC has been in use for a long time, many serial chips exist which support the protocol, and its idiosyncrasies are well understood. Therefore it was a sensible choice for use in the PPP protocol scheme.

Within the HDLC frame there is an address field, a control field, and the PPP protocol packet. The PPP protocol packet itself is comprised of two fields, a protocol identifier field and the transmitted data field.

The PPP protocol field is comprised of two bytes, and is the means of determining whether the data field is either an encapsulated IP packet, or one of a family of Link Control Protocol (LCP) or Network Control Protocol (NCP) fields.

When a PPP packet is received, the protocol field is decoded to determine what to do with the data field. If it is an IP packet, it is forwarded on to the IP protocol layer in the host's networking code, if it is an LCP or NCP packet, the PPP state machine itself must deal with it.

This is a very clever arrangement, as it allows a single packet structure to transparently support the transmission of a range of networking protocols as well as a range of maintenance protocols to manage the link. This arrangement provides for unprecedented flexibility, interoperability and transparency and is one of the greatest strengths of the PPP design.

PPP Link Control Protocol

The PPP Link Control Protocol (LCP) is the scheme used to control the state of the PPP protocol state machine at either end of a link. What LCP provides is a mechanism for the PPP software at either end of the link to converse on matters of configuration at link startup time.

This is of particular importance when a PPP dialup modem connection is opened, or when a faster synchronous channel such as an ISDN B-channel is opened. Once a connection is established, the PPP LCP software state machines at either end of the link start firing specific packets at each other to negotiate the link parameters, and reach agreement on how the link is to be configured.

This feature is one of the great strengths of PPP, and good implementations can fully automatically figure out for themselves how the link is to be run. If one end of the link can support only some of the protocol features which the other may use, negotiation ensures that both ends "speak the same language", and use facilities supported at both ends of the link. When mixing and matching various vendor's equipment and software at either end of a link, LCP takes the pain out of the process, which happens transparently to the user.

During an LCP negotiation the PPP state machines negotiate Maximum Receive Unit, Async Control Character Map, Authentication Type, Magic Number, Link Quality Monitoring, Protocol Field Compression and Address and Control Field Compression.

Needless to say at startup time PPP is very busy indeed, and the LCP phase will usually see a flurry of packets until link parameters are agreed upon. At that point PPP will move on to negotiate the network protocol parameters, using one of a family of Network Control Protocols. For our familiar IP protocol this involves running the IP Control Protocol (IPCP) which negotiates addresses and compression.

Once PPP has completed its LCP and NCP negotiations, it can transition to an "open" state and begin to carry network traffic. The PPP standard allows for multiple NCP negotiations to support concurrent traffic in more than one protocol, ie LCP negotiates non protocol specific link parameters, after which an NCP (IPCP) session negotiates IP parameters, and then if supported, other protocol NCPs would negotiate their protocol specific parameters.

At this time PPP NCPs and encapsulation are defined for the following proprietary protocols:

While the LCP and NCP schemes may appear to be overly complex, their operation is well hidden from users and is usually completed in several seconds at the most. Providing that a robust PPP implementation is used, LCP/NCP can be tremendous time savers for users.

PPP Network Protocol Transmission

Once a PPP link is open, traffic may flow. If the link is carrying IP traffic, there are a number of interesting options which PPP provides for.

Whatever the physical channel, be it asynchronous dialup, X.25, ISDN or high speed protocols like SONET, PPP will use what is termed HDLC-like framing (see above). PPP uses either the native HDLC framing of the link, if X.25, or creates its own HDLC frames (sync and async low speed serial) or embeds HDLC-like frames in the native framing structure of the protocol, eg in SONET.

One option available is the use of reliable HDLC transmission where the link (eg X.25) allows this. In default (non-reliable) operation, corrupted frames are simply discarded, the HDLC FCS checksum being used only to provide improved protection over the TCP/IP checksums, with retransmission of corrupted packets being handled by the TCP layer. With reliable transmission, the HDLC layer manages retransmission itself, and this can provide a significant performance improvement on noisy links as the TCP layer never sees the lost packets.

Another powerful option is the use of Van Jacobsen (VJ) TCP/IP header compression which can improve considerably interactive performance when running utilities such as _telnet_ and _rlogin_. One of the problems with running uncompressed TCP/IP over slow links is the overhead, ie should you hit a key to send a single character you are actually sending 41 bytes, of which 40 are TCP and IP packet headers and one alone is the keystroke you produced.

Van Jacobsen devised an ingenious scheme in the late 1980s for compressing combined TCP/IP headers from 40 bytes down to as little as 3 bytes per packet, and his excellent paper (RFC1144) is highly recommended to interested readers (ftp.nic.ddn.mil). What the VJ method relies upon is that in an established TCP connection, very few header bytes change between subsequent packets. The VJ compression technique exploits this by setting up appropriate state machines at either end of the link, which will keep track of packets in the connection and regenerate the TCP/IP headers from the compressed header data.

VJ compression is designed for use in interactive applications, and becomes less effective with increasing packet size. Applications running X will benefit somewhat from its use, but file transfers using FTP benefit little particularly if the link is running with a large MTU value set, as the ratio of header to data is much smaller. Remote login with _telnet_ or _rlogin_ benefit the most.

Implementation Issues

There are a number of ways in which PPP can be implemented. Most dialup applications use a combination of a daemon and a driver. The driver is linked into the kernel, or loaded at boot time, and provides a standard network interface to the IP layer, which will treat it in much the same fashion as it treats a conventional network device such as an Ethernet interface.

The daemon does all the clever work, and is usually tied in as the captive application run in the user environment. Instead of running say a csh when the PPP user account is logged into, the daemon is run. The daemon will then write/read PPP traffic to/from the serial port and IP traffic to/from the driver.

This arrangement is very easy to integrate, and allows the serial port to be used for ordinary logins should they be desired. Only when the PPP user account is logged into does the daemon become active, talking LCP, IPCP and IP/HDLC though the serial port to the remote PPP device. Should LCP and IPCP negotiation fail, the daemon hangs up the port and logs itself out.

At this time most good routers and terminal servers support PPP, quite a few Unix ports support it (including FreeBSD 1.1) and there are also a wide range of public domain (eg dp 2.x) and commercial implementations available (eg Morning Star's PPP which also includes SLIP).

In the author's experience most public domain implementations require a bit of tinkering to get going, but generally seem to be very robust once up and running. The commercial products are usually easier to get going, and have bigger features sets.

When choosing a PPP implementation it is a good idea to have a close look at what features are available, and when installing to check which features are default. VJ compression may not be supported, and when supported is not usually set to be a default. This is worth investigating before spending time and/or money on a specific product.

Summary

PPP is highly sophisticated and robust protocol which allows the use of IP on point-to-point links from low speed async serial phone lines up to very high speed synchronous links. As with any design of such complexity, PPP implementations can vary in capability and this should be carefully considered when deciding on a specific type for use.