Serial Line Internet Protocol (SLIP)

SLIP was an early attempt at directly integrating modem protocols with TCP/IP. SLIP began with 3COM's UNET TCP/IP. It was later implemented on Berkeley Unix systems, and since then has become widely available, both within the Unix world and in the world of PC compatibles.

SLIP's technology is now considered somewhat obsolete. There is no question, however, that it works, and in some situations SLIP's simplicity is a benefit.

What SLIP Does

The purpose of SLIP is to transmit IP datagrams across a modem line. SLIP provides no physical addressing or error control and depends on upper-layer protocols for error control functions. SLIP simply sends the data and then sends a signal marking the end of the data.

The SLIP data format is shown in Figure 8.4. A special END character (equivalent to decimal 192) marks the end of the data. If an END character occurs naturally in the data, SLIP includes a special ESC character before the END character so that the receiving computer doesn't prematurely stop receiving the packet.

The RFCs do not specify a standard maximum size for a packet of SLIP data, but RFC 1055 recommends a maximum size of 1006 bytes, excluding the characters that mark the end of the frame, when using a Berkeley Unix SLIP driver.

SLIP implementation developers can set a maximum size and define other configuration settings. Unlike PPP, SLIP does not enable the communicating computers to negotiate connection configuration settings dynamically. Therefore, SLIP configurations are not always compatible.

Characteristics

SLIP has survived beyond its years and, although it was an innovation in its time, in the context of today's technology a list of SLIP's characteristics looks similar to a list of its shortcomings.

RFC 1055 identifies the following SLIP characteristics and deficiencies:

• Addressing— Both computers have to know each other's IP address. SLIP is incapable of supporting dynamic IP address assignment. This makes SLIP impractical for dial-up accounts with Internet service providers (ISPs), which typically lease IP addresses to dial-up users (using DHCP) for the duration of the session. SLIP is incapable of receiving this leased address.

• Type identification— As RFC 1055 puts it, "SLIP has no Type field." Because SLIP offers no means of specifying a protocol type, it is incapable of supporting multiple protocols simultaneously. Unlike PPP, SLIP cannot multiplex/demultiplex other protocol systems with TCP/IP.

• Error correction/detection— SLIP does not provide error correction. As you learned in previous hours, various forms of error checking occur at upper layers, so error checking through the modem protocols is not absolutely essential. However, some services are designed with the assumption that network access protocols will check for transmission errors on the physical network. Depending solely on an upper-layer error recovery scheme such as TCP's (refer to Hour 6, "The Transport Layer") can result in a significant amount of retransmission, reducing efficiency over the already slow modem link.

• Compression— Because transmission over a phone line is so slow, any means of reducing the quantity of data is beneficial. Successive TCP and IP headers often contain redundant information, and there are several strategies for compressing header information. SLIP does not support header compression.

The networking industry addressed some of the shortcomings of SLIP through the development of PPP, which you'll learn more about in the following sections.