With due acknowledgement to the free TCP/IP Guide from which this extract is taken
The TCP/IP protocol suite is structured around the Internet Protocol (IP). IP operates at layer three of the OSI Reference Model, and assumes that it will be layered on top of an existing layer two technology. However, certain types of connections exist that do not include a layer two protocol over which IP can run. To enable TCP/IP to operate on these kinds of links, two special TCP/IP data link layer protocols have been created.
In this section I describe the protocols used specifically to implement data link layer connectivity for TCP/IP internetworks. I begin with a brief overview of the two protocols used to connect devices at layer two and how they fit into the TCP/IP protocol suite as a whole. I then have a single topic that describes the operation of the rather simple Serial Line Internet Protocol (SLIP), and a comprehensive section on the much more capable Point-to-Point Protocol (PPP).
The TCP/IP protocol suite was generally designed to provide implementation of the networking stack from the network layer (layer three) and above. The core protocols of TCP/IP operate at layers three and four of the OSI model, corresponding to the Internet layer and Host-to-Host Transport layer of the TCP/IP architectural model. Other support protocols are defined at these two layers, and many application protocols run there too, as well as at the upper layers of the protocol stack.
However, the TCP/IP architectural model also defines the Network Interface layer, which corresponds to the data link layer (layer two) in the OSI scheme. In most classical networks, TCP/IP doesn't define any protocols operating at this layer. TCP/IP assumes that layer two functionality is provided by a WAN or LAN technology like Ethernet, Token Ring, or IEEE 802.11. These technologies are responsible for the classical layer two functions: physical layer addressing, media access control, and especially, layer two framing of datagrams received from layer three.
There's a problem with the assumption that IP can run on top of an existing layer two protocol: sometimes there isn't one. There are certain technologies that establish only a basic, low-level connection at the physical layer. The most common example of this is a simple serial connection established between two devices. Years ago, it was fairly common for two computers to just be connected using serial ports instead of a full-fledged LAN protocol. Today, we see this much less, but there's another type of serial connection that is very popular: serial dial-up networking. When you use a modem to connect to a modem at your Internet Service Provider, the modems negotiate a connection that architecturally exists only at the physical layer.
Since the Internet Protocol assumes certain services will be provided at layer two, there is no way to make it operate directly over a serial line or other physical layer connection. The most important layer two function that is required at a minimum is some mechanism for framing the IP datagram for transmission—that is, providing the necessary data packaging to let datagrams be transmitted over the physical layer network. Without this, IP datagrams cannot be sent over the link.
We need something to “fill the gap” between IP at layer three and the physical connection at layer one. To this end, a pair of special protocols have been defined that operate at layer two and provide the services that IP requires to function. These are:
Serial Line Internet Protocol (SLIP): A very simple layer two protocol that provides only basic framing for IP.
Point-to-Point Protocol (PPP): A more complex, full-featured data link layer protocol that provides framing as well as many additional features that improve security and performance.
Both SLIP and PPP are designed for connections that go between just two devices; thus the name “Point-to-Point” Protocol for PPP. They are used in port topology LAN or WAN connections, the simplest type. Since there are only two devices, A and B, communication is straight-forward: A sends to B and B sends to A. Since they only deal with simple two-device connections, they do not have to worry about complexities like media access control, or collisions, or unique addressing schemes, the way technologies like Ethernet must. As mentioned earlier, the primary focus of these protocols is providing framing services to layer three, as well as extra features as needed.
Why have two protocols? They both get the job done; the difference is in how they do it. SLIP is extremely simple and easy to implement but lacks the features of PPP, like authentication, compression, error detection and more. PPP is full-featured but much more complicated.
To draw an analogy, SLIP is a mostly-sturdy, ten-year old compact sedan, while PPP is a shiny new luxury SUV. Both will get you from here to Grandma's house, but the SUV is going to be safer, more comfortable and better able to deal with problems that might crop up on the road. If they cost the same to buy and operate, you'd probably choose the SUV. Both SLIP and PPP cost about the same, and unlike an SUV, PPP causes no air pollution and doesn't guzzle gas. For this reason, PPP is the choice of most serial line connections today, and has all but replaced SLIP.
Key Concept: SLIP and PPP provide layer two connectivity for TCP/IP implementations that run directly over a physical layer link without a layer two technology. SLIP is simple and was more commonly used years ago, but today PPP is favored due to its many features and capabilities.
Incidentally, I should mention that there are some people who don't even consider SLIP and PPP to be part of the “true” TCP/IP protocol suite. They argue that TCP/IP really is defined at layers three and up on the OSI model, and IP itself is the basis of TCP/IP at layer three. Thus, SLIP and PPP are just “extra” protocols that can be used under TCP/IP. To support their argument they point to the fact that PPP can be used for protocols other than IP (which is true). For its part, SLIP is so simple it could carry any layer-three protocol, but I don't believe it has been implemented for network layer protocols other than IP.
Frankly, I consider these to be “how many angels fit on the head of a pin” type arguments. As far as I am concerned, SLIP and PPP are part of TCP/IP because they were originally designed for the specific purpose of letting TCP/IP run on layer one links. They were defined using the normal Internet RFC process as well. Regardless, whether they are part of TCP/IP or not, they are used by millions of people every day to enable TCP/IP networks to operate, and thus are deserving of a place in this Guide.
The need for a data link layer protocol to let IP operate over serial links was identified very early on in the development of TCP/IP. Engineers working on the Internet Protocol needed a way to send IP datagrams over serial connections linking computers together. To solve the problem they created a very simple protocol that would frame IP datagrams for transmission across the serial line. This protocol is called the Serial Line Internet Protocol, or SLIP for short.
SLIP is different from most TCP/IP protocols in that it has never been defined as a formalized standard. It was created informally in the early 1980s and its use spread as a de facto standard before it was ever described in an RFC document. Even when it was eventually published, in 1988, the decision was specifically made that SLIP would not be designated an official Internet standard. The authors of the paper that describes it, RFC 1055, made sure nobody would miss this point, by naming it A Nonstandard For Transmission Of IP Datagrams Over Serial Lines: SLIP.
Why was SLIP designated as a “nonstandard” instead of a standard? Well, it was developed as a very rudimentary “stopgap” measure to provide layer two framing when needed. It's so simple that there really isn't much to standardize. Also, the protocol has so many deficiencies that the IETF apparently didn't want it given the status of a formalized standard. RFC 1055 makes specific mention of the problems with SLIP (which we'll see below) and the fact that work was already underway at that time to define a more capable successor to SLIP (PPP).
How simple is SLIP? So simple that it is one of the very few technologies in this Guide that I can describe almost completely without complaining that it's complicated, or resorting to telling you to “see the defining document for details”. SLIP performs only one function: framing of data for transmission. It does nothing else.
Here's how SLIP framing works. An IP datagram is passed down to SLIP, which breaks it into bytes and sends them one at a time over the link. After the last byte of the datagram, a special byte value is sent that tells the receiving device that the datagram has ended. This is called the SLIP END character, and has a byte value of 192 decimal (C0 hexadecimal, 11000000 binary). And that's basically it: take the whole datagram, send it one byte at a time, and then send the byte 192 to delimit the end of the datagram.
A minor enhancement to this basic operation is to precede the datagram by an END character as well. The benefit of this is that it clearly separates the start of the datagram from anything that preceded it. To see why this might be needed, suppose at a particular time we have only one datagram to send, datagram #1. So, we send #1, and then send the END character to delimit it. Now, suppose there is a pause before the next datagram shows up. During that time we aren't transmitting, but if there is line noise, the other device might pick up spurious bytes here and there. If we later receive datagram #2 and just start sending it, the receiving device might think the noise bytes were part of datagram #2.
Starting datagram #2 off with an END character tells the recipient that anything received between this END character and the previous one is a separate datagram. If that's just noise, then this “noise datagram” is just gibberish that will be rejected at the IP layer. Meanwhile, it doesn't corrupt the real datagram we wish to send. If no noise occurred on the line between datagrams then the recipient will just see the END at the start of datagram #2 right after the one at the end of #1, and will ignore the “null datagram” between the two.
There is only one other issue SLIP deals with. If the END character is 192 decimal, what happens if the byte value 192 appears in the datagram itself? Transmitting it “as is” would fool the recipient into thinking the datagram ended prematurely. To avoid this, a special Escape character (ESC) is defined, which has a decimal value of 219 (DB in hex, 11011011 in binary). The term “escape” means that this symbol conveys the meaning “this byte and the next one have a special meaning”. When a value of 192 appears in the datagram, the sending device replaces it by the ESC character (219 decimal) followed by the value 220 decimal. Thus, a single “192” becomes “219 220” (or “DB DC” in hexadecimal). The recipient translates back from “219 220” to “192”.
Note: The SLIP ESC character is not the same as the ASCII ESC character. They both perform an “escaping” operation but are otherwise unrelated.
This leaves one final problem: what happens if the escape character itself is in the original datagram? That is, what if there's a byte value of 219 in the IP datagram to be sent? This is handled by a similar substitution: instead of “219” we put “219 221”.
SLIP sounds great, right—nice and simple? Unfortunately, the cost of this simplicity is that SLIP just doesn't provide many of the features and capabilities we really need on modern serial links. Some of the most significant problems with SLIP include the fact that it is deficient in all of the following areas:
Standardized Datagram Size Specification: SLIP’s maximum datagram size supported is not standardized and depends on the implementation. The usual default is 1006 bytes, which becomes the maximum transmission unit (MTU) for the link. If a different size is used this must be programmed into the IP layer.
Error Detection/Correction Mechanism: SLIP doesn't provide any way of detecting or correcting errors in transmissions. While such protection is provided at higher layers through IP header checksums and other mechanisms, it is a job “traditionally” also done at layer two. The reason is that relying on those higher layers means that errors are only detected after an entire datagram has been sent and passed back up the stack at the recipient. Error correction can only come in the form of re-sending any datagrams that were corrupted. This is inefficient, especially considering that serial links are generally much slower than normal LAN links.
Control Messaging: SLIP provides no way for the two devices to communicate control information between them to manage the link.
Type Identification: Since SLIP includes no headers of its own, it is not possible to identify the protocol it is sending. While developed for IP, you can see that there is no reason other layer three protocols could not be sent using SLIP. However, without type identification there is no way to mix datagrams from two or more layer three protocols on the same link.
Address Discovery Method: Addressing isn't needed at layer two due to the point-to-point nature of the connection—there are only two devices so the intended recipient of each message is obvious. However, devices do need some way of learning each other's IP addresses for routing at layer three. SLIP provides no method for this.
Support For Compression: Compression would improve performance over serial lines that are, again, slow compared to other technologies. SLIP provides no compression features. Note, however, that modems usually do support compression at layer one, for serial connections that use them. There was also a variant on SLIP called Compressed SLIP or CSLIP that was created in the late 1980s, but it was not as widely deployed as regular SLIP.
Security Features: SLIP provides no methods for authentication of connections or encryption of data, which means even the basics of security are not provided.
Sounds pretty bad, doesn't it? The many shortcomings of SLIP have led most implementations to move from SLIP over to the newer Point-to-Point Protocol (PPP), which is a much richer data link protocol for direct connections that resolves the problems listed above. SLIP is now outdated, and some even consider it a historical protocol. Despite that, SLIP is still used in many places. Simplicity is attractive, and computer people are famous for their inertia: if something is implemented and is working well, many will refuse to change unless they are forced to do so.
Even as SLIP was being documented as a “nonstandard” in RFC 1055, work was underway for a newer protocol to provide full-featured IP transmission over direct links between pairs of devices. The result is the Point-to-Point Protocol (PPP), which defines a complete method for robust data link connectivity between units using serial lines or other physical layers. It includes numerous capabilities and features, including error detection, compression, authentication, encryption and much more.
Albert Einstein is credited with the following quote: “Everything should be made as simple as possible but no simpler”. The Serial Line Internet Protocol (SLIP) is a good example of this maxim. It provides basic layer two framing for IP, but it is just too simple for many uses. Since all it does is frame the end of each datagram, it doesn't provide many of the features that we really need for reliable, secure and high-performance operation over serial links. This is especially true today when most serial connections are not short LAN cables but dial-up WAN connections over relatively long distances.
SLIP was basically a “hack” to fill a specific need: bridging the gap between IP at layer three and a serial link at layer one. It “gets the job done” but doesn't provide any of the features we really want in a robust protocol for direct links between devices. PPP was developed to be a complete protocol suite that would enable fully-functional layer two connectivity to support not just IP but the transmission of other network layer protocols as well.
The history of PPP goes back to the late 1980s, when SLIP was the de facto standard for serial IP implementations. The first formal IETF document related to PPP was RFC 1134, published in 1989. This RFC is not the standard itself but a proposal for what would eventually be defined as the first main PPP standard, RFC 1171, in 1990. This early document has been revised several times and several other documents added that define the various protocols that comprise the entire PPP suite.
The IETF is always smart about not reinventing the wheel. Rather than try to develop PPP from scratch, the decision was made to base it on the ISO High-Level Data Link Control (HDLC) protocol, which was initially developed by IBM. HDLC is a derivative of the Synchronous Data Link Control (SDLC) protocol. PPP's developers adapted its framing structure and some of its general operation from the HDLC protocol.
PPP is a connection-oriented protocol that enables layer two links over a variety of different physical layer connections. It is supported on both synchronous and asynchronous lines, and can operate in half-duplex or full-duplex mode. It was designed to carry IP traffic but is general enough to allow any type of network layer datagram to be sent over a PPP connection. As its name implies, it is for point-to-point connections between exactly two devices, and assumes that frames are sent and received in the same order.
PPP fits into the Network Interface layer (Link Layer) in the TCP/IP model, as shown in Figure 23. The operation of PPP follows a specific sequence described in the general operation topic, including a multi-step link establishment phase that may include optional authentication.
A list of PPP's strengths reads very much like a list of SLIP's weaknesses, which I explained in detail in the topic on SLIP. Some of the specific benefits of PPP compared to SLIP include:
The proliferation of serial links, especially for dial-up Internet access, has led to widespread use of PPP. It is now one of the most popular layer two WAN technologies in the networking world, and has replaced SLIP as the standard for serial connections on all but legacy implementations. While most often associated with dial-up modem use, PPP can run across any similar type of physical layer link. For example, it is often used to provide layer two functionality on ISDN B channels.
Key Concept: PPP is a complete link layer protocol suite for devices using TCP/IP, which provides framing, encapsulation, authentication, quality monitoring and other features to enable robust operation of TCP/IP over a variety of physical layer connections.
PPP’s Extensibility
A key advantage of PPP is that it is an extensible protocol suite. Over the years new protocols have been added to the suite, to provide additional features or capabilities. For example, PPP is designed not to use just a single authentication protocol, but to allow a choice of which protocol is used for this purpose.
PPP's success has even led to the development of derivative protocols like PPP over Ethernet (PPPoE) and PPP over ATM (PPPoA). These actually layer PPP over existing data link layer technologies, which shows you how valued PPP's features are—even when a layer two technology is already in use, applying PPP on top provides authentication and management benefits for services like DSL.
** End of Extract