Parity is a one-bit checksum. Modems may or may not use
parity.
Add up all the bits in a word (including one "parity bit"); if the
total is even, the word had even parity. Equivalently: if there were an
even number of 1's, the word had even parity. We set the parity bit to
make this true, then check it on receipt.
Odd parity (actually more often used) sets the parity bit so that the total number of on-bits in the word is odd. The advantage of this is that all zeroes (for even parity) may in some systems not even be visible; odd parity puts at least one 1-bit ("set") in each word.
Start and Stop bits. Asynchronous transmissions mean that every character can come at any time; so a "start bit" was originally used in Teletype machines to get the equipment moving. The line was resting at 0, and the first 1 means "here goes". Thus the first 1 contains no data except the fact of startup.
Stop bit=0 is less necessary, if the system counted the bits of a byte as they came in; but they are used. Sometimes they even use two of 'em for ancient and obscure reasons.
8-N-1 is a code meaning "8 data bits, no parity bit, and 1 stop bit. With the start bit, this requires ten bits per byte of transmitted data.
Baud Rates. Since it takes 10 bits (or 11 or 12) to get 8 useful data bits to the other end. Modems with advanced protocols play cunning tricks like providing faster service in one direction than the other, by trying to guess which end is occupied by a human. (Humans need to receive much more than they usually send.)
There are two "virtual wires" in a modem, each consisting of a pair of frequencies for 0 and 1. Modems often "steal" one channel (pair of frequencies) from its intended direction to bolster the bandwidth in the opposite direction. Obviously this requires a negotiation between the modems. No wonder the clatter and whir of modems negotiating, sounds complex. It is.
Using a 2400 baud modem you can only support remote terminal applications. At 14.4k, SLIP and PPP become practical. We'll see why in a moment.
SLIP uses two characters as markers: END (ASCII 192, hex C0) and ESC (ASCII 219, hex DB). END is used to end each packet (and also to begin them as we will see.) But how can you deal with the possibility that an END might occur in the natural run of your data?
SLIP's transmitter looks for END characters and translates them into a two character sequence - ESC END. Its receiver in turn looks for ESC END and translates them into ASCII 192, passes the data onward. If it sees a naked END without ESC, that's the end of a packet.
Now of course ESC has become "special" and cannot simply be transmitted either. SLIP's transmitter replaces ESC with ESC ESC; its receiver performs the opposite translation.
Most SLIP implementations start a packet with END, which "flushes" any previous noise. In effect it declares any previous noise to be an IP packet, which the receiving system immediately rejects because it is meaningless. If there is no noise, the receiving SLIP will see two back to-back END characters and know to stasrt a new packet.
Error Detection is up to TCP/IP. SLIP just delivers the packets. Since UDP doesn't do error correction, don't use it with SLIP.
SLIP Deficiencies. Your computer will have an IP address which is usually dynamically assigned whenever you log in (i. e. different each time.) You could purchase a dedicated line and IP address for more money. Unfortunately there is no way for your application to ask SLIP what your IP address is. Some "kluges" (non-standard tricks) are occasionally used to get around this problem but they are not uniform between implementations.
SLIP packets contain no typing information, and so cannot be mixed with any other type packets over the same serial line. Also, SLIP incorporates no data compression. Compressed Slip (CSLIP) improves on this.
CSLIP compresses TCP/IP header information only. This is more useful than it sounds, particularly for interactive operations such as Telnet. With bulk transfers such as FTP, large packets are the norm and header overhead costs are relatively small. But interactive keystroke-by-stroke interactions generate a packet per keystroke - which would be 40 bytes of TCP/IP overhead per one byte of keystroke information!
Line Efficiency is the ratio of data to header-plus-data in a TCP/IP datagram. Thus for one-keystroke transmission, LE=1/41 = .0244.
Interactive Response refers to how quickly something happens when the user presses a key. People really need interactive response within 100 milliseconds or their personal feedback loops don't work well.
CSLIP header compression. About half the TCP/IP header info remains constant over the life of a connection. CSLIP saves a copy of the last header, and substitutes a small connection identifier which means "pick up header #34 and make these changes to it:", followed by the changes. This key technique is called differential coding. It accounts for most of the efficiency of CSLIP.
CSLIP then uses a variety of ad-hoc tricks to nibble away the changed information in the TCP/IP header to an average of 3 bytes per packet. For instance, CSLIP depends on the link level framing protocol (i. e. SLIP, or (later) PPP) to tell the receiver the length of the received message, and thus can eliminate the Total Length field in the IP header.
* An encapsulation method that lets the network software use a single serial link for multiple protocols;
* a Link Control Protocol (LCP) with which the two ends of a PPP connection use to negotiate the connection; and
* a family of Network Control Protocols (NCPs) that let PPP connections use different network-layer protocols.
PPP will use CSLIP's compression strategy, while wrapping it in a more robust encapsulation system. To wit, a PPP frame looks like this:
| starter flag byte | 7E |
| Address byte | FF |
| Control byte | 03 |
| PPP Data: up to 1500 bytes | up to 1500 bytes |
| CRC: two bytes | two butes |
| end flag byte | 7E |
Within the data, hex 7D serves as an escape character to mark data of value hex 7E or 7D. Also, the sixth bit of any escaped data is toggled. This has the objective of making it possible to escape ASCII chars < hex 20 (e. g. 1B) yielding 3B, since "non printing" chars <20 are often used by modems as escape chars of their own.
The PPP data consists of a 2 byte protocol header and any number of bytes of enclosed information. The protocol header has three possible values, with these basic meanings:
| hex 0021 | IP datagram follows |
| hex C021 | Link control data follows |
| hex 8021 | Network control data follows |
Frequently the Link Control Protocol is used to negotiate a Protocol field of one rather than two bytes. They can also negotiate the elimination of the flag, address and control fields. The author says this boils down to an overhead of 3 bytes (one protocol, two CRC) by trusting the IP packet's length information.
As stated above, PPP link control negotiates the use of CSLIP compression on the contents. Other alternatives can be negotiated as technology improves.
What's all this Negotiation? Sender can ask receiver for a particular option by mentioning its Link description name, and the receiver can say "OK" or "never heard of it." But there has to be a standard assignment of code numbers. Indeed, there is. Internet standards are stored in "RFC" documents ("request for comments") even though the commenting process is already over. The RFC entitled "Assigned Numbers" has PPP Link Control Protocol (LCP) codes.
2. Explain the concept of line efficiency and why it is particularly critical for interactive applications such as Telnet.
3. Explain how CSLIP's compression technique manages to reduce the size of IP packet headers so drastically. (You don't have to provide all the gory details; the flavor is what we want.)
4. Summarize the differences between SLIP and PPP.