A look at the value of the Point-to-Point Protocol in creating wide-area networks
Ben Smith
The struggle to interconnect networks is intensifying. More and more, the networks in our offices carry two or more protocols. At the same time, these networks need to connect to other networks located across town or across the continent. The terms multiprotocol and wide-area network, or WAN, bring nods of affirmation during any discussion. The Point-to-Point Protocol, or PPP, can boast both terms and still shun the word proprietary. No wonder it has become popular.
PPP can be used to inexpensively extend a LAN out to a single remote device, to connect to distant segments of a LAN, or even (through the use of routers, such as the Telebit NetBlazer) to connect diff
erent LANs together. It was designed to create temporary physical links while using modems over phone lines, but it can be used for any serial-line links--even high-bandwidth connections, such as T1.
PPP was developed by the IETF (Internet Engineering Task Force) through the cooperative work of dozens of individuals and commercial enterprises and the Internet's RFC (Request for Comments) publication process (originally RFCs 1171 and 1172, which were replaced by RFC 1331 and others). The motivation was the advancement of the traditional serial links that still form the twigs of much of the Internet throughout the world.
In the Unix world, these links used to be maintained by a store-and-forward file transfer and command-execution method called UUCP, the complete opposite of the stream-like TCP/IP network protocol. The development of fast and inexpensive dial-up modems has provided the technology to make serial-line networking feasible over more than just leased lines and direct RS-232 serial link
s.
The first generation of IP-over-serial lines, SLIP (the Serial Line Internet Protocol, defined in RFC 1055), was satisfactory only in a simplistic way. It was not based on any widely accepted standards and provided only minimal functionality--and that only to the TCP/IP world. But SLIP (see the figure "The Full SLIP Packet Format") is simple both in design and implementation, and therefore its use spread quickly. Now PPP is rapidly replacing SLIP and is providing the basis of serial-line extensions for many other protocols as well.
The Data Link
PPP is primarily a data-link protocol, but it goes beyond that. The design goals of PPP were to provide a method for establishing, configuring, and evaluating serial links and then encapsulating network-layer datagrams (i.e., blocks of data) over these links. PPP also includes a growing set of protocols for establishing different network-layer protocols, such as IP, IPX, Banyan Vines, and any implementation of the OSI (Open Systems Interconnection)
network layer.
Unlike SLIP, PPP is based on a widely accepted structure, the HDLC (high-level data-link control) protocol (see the figure "The Full PPP Packet Format" on page 272). HDLC is an internationally adopted ISO standard. It is also the basis for the data-link layers of X.25, ISDN, V.42, Frame Relay, and even the SDLC (synchronous data-link control) protocol of IBM's SNA (Systems Network Architecture) networks.
One of the major uses of the HDLC structure is for identifying the various protocols that it can carry. Just like Ethernet, PPP can carry several different ones simultaneously.
As a general rule, PPP encapsulates the packets of the passenger (i.e., network-layer) protocol rather than fragmenting them, as does ATM (Asynchronous Transfer Mode) in its design for optimization of available bandwidth. The emphasis of PPP is on maintaining robustness over serial links of questionable integrity. Nonetheless--and despite its far more sophisticated packet structure and management pr
otocols--it's not as bad as many SLIP advocates predicted.
Protocols Within
PPP defines two types of internal protocols: the LCP (Link Control Protocol), which is used for establishing, configuring, and testing the data-link connection; and the NCPs (Network Control Protocols--not Novell NetWare Core Protocols), each of which is defined for its corresponding network-layer passenger type. An example of an NCP is IPCP (the Internet Protocol Control Protocol, which is described in RFC 1332).
In this short discussion about PPP, I'm focusing more on the facilities provided by LCP than on the various NCPs. The format of the LCP and NCPs is the same; only the content is different. The former is purely PPP administrative; the latter contains the passenger-network packets. The LCP and NCP packets have the same structure. The signal that a packet is being used for LCP is held in the protocol field. All LCP packets have a protocol identifier with a C0 (hexadecimal) in the first octet.
As with nea
rly all communications protocols, a successful PPP session consists of at least three stages: establishing the link, carrying on the conversations of the encapsulated protocols, and shutting down the link. It's important to note that each of these phases happens within the structure of the HDLC/PPP format, and, as such, they happen only over an already-established physical link. For example, assuming that the physical link consists of two modems and a phone line, the scheme works as follows.
Say that network segment A has business for segment B, so the PPP bridge (or router) software sees that it has to establish a connection to segment B via modem. The modems connect and establish the best physical link possible in the normal way that modems do. (We can hope that the link is at least 9600-bps V.32.) Once the physical link is established, the PPP packets start to flow.
The first PPP packets are purely LCP packets. This is the first active phase of a PPP session, establishing the link. During thi
s phase, the two PPP segment servers test the physical-link quality and negotiate the maximum size for PPP packets. There is nothing in this phase that is specific to the passenger (i.e., network-layer) protocol or its configuration.
Once the data link has been established, PPP may move into an authentication phase if the implementation requires it. This is an implementation-specific option. There are still no NCP packets at this stage.
Only after these preliminary steps have been successfully completed does PPP enter the second phase, and the NCP packets start to flow. Each of the NCP packet headers indicates what kind of passenger is riding in the information field of that packet. The first NCP packets for an encapsulated protocol are likely to be special negotiations for that protocol--for example, special IPCP packets are used to set up the IP link and possibly to negotiate a compression method. Like the NCP packets, these network-layer-control packets carry their own special values in the p
rotocol field; the first octet has an 80 (hexadecimal). At this point, the actual datagrams begin to flow.
This second phase is not limited to a single passenger link; several concurrent links, even those using different link-layer protocols, can be carried simultaneously. Nor is this phase of the PPP session limited to NCP packets. There may also be some LCP packets for regular testing of the link and for renegotiating the maximum packet size.
The final phase of a PPP session shuts down the PPP services at both ends. When you consider the types of media over which this network is established--phone lines, satellite links, and the like--you realize that this phase, known as the link-termination phase, can actually happen at any time. PPP is designed to cope with this unpredictability.
Catching On
Critics of PPP wag their fingers at the overhead of its extensive configuration phase. However, this is a trivial matter compared to the time it takes for modems to establish a physical link,
no matter what kind of transmission is going to take place over it. Another criticism of PPP is its complexity, particularly when compared to SLIP. PPP was not a trivial piece of work to design, and it is not a trivial task to implement it. But the complexity of PPP provides for greater flexibility and greater reliability over less-than-ideal physical connections. PPP's foundation on established protocols also means that engineers who have already worked on other HDLC-based protocols will be working with familiar structures when they work with PPP.
Because PPP can carry so many other protocols, there are already free implementations not only for Unix platforms (there are many), but also for Macs (MacPPP), PCs (WG7J), and the Amiga (AmigaNOS). PPP is also implemented in many commercial packages, such as Novell's LAN WorkPlace for DOS, FTP Software's PC/TCP, Distinct's and Frontier Technologies' Microsoft Windows DLLs for PPP, and Morning Star Technologies' PPP for Unix platforms. In addition, you can fi
nd PPP in terminal servers and routers, such as the aforementioned Telebit NetBlazer, as well as Livingston Enterprises' PortMaster PM-11, Xylogics' MicroAnnex XL and Annex Three, Datability's VCP 200/300, and 3Com's CS/2100, among many others.
All the work that has been put into developing and implementing PPP has been worth the effort. It is fast becoming the de facto standard for inexpensive long-distance network connections, it is network-layer-protocol-independent, and it's freely available.
Figure: The Full SLIP Packet Format
The SLIP protocol is very simple, but it doesn't provide error checking and is not based on any widely accepted standards.
Figure: The Full PPP Packet Format
The PPP protocol is far more complex than SLIP, but it offers error checking and is based on the HDLC standard. It can support a host of network protocols above it.
Ben Smith is a testing editor for the BYTE Lab. You can reach him on the Internet at
ben@bytepb.byte.com
or on BIX as "bensmith."
From Here to There
