1. Introduction
2. Physical
3. Data Link
4. Network
5. Transport
6. Session
7. Presentation
8. Application
9. Conclusion

1 Introduction

One day over lunch, some fellow SysAdmins and I were discussing the merits of various interview questions. An uninitiated friend of ours seemed interested in the fact that we wanted to know how well an applicant understood the underlying network protocols. They seemed awfully arcane, and the sort of thing that programmers and router developers knew as Deep Magic.

The three of us cured him of this impression by the time the first course was served. We used examples that exist in common office environments, and explained it all using the OSI seven layer model. So let's go over the OSI model from the bottom up. The diagram looks like this:

The layers are layers of abstraction, and do not represent anything other than a way of thinking about the roles of various bits of code and wire. People may refer to performing a task "at the Transport layer", but in reality tasks tend to blur over several of these roles.

Many complain that the OSI model is unrealistic and useless. Some argue that it is overly baroque for most tasks, and was obviously the tragic result of design-by-committee. These arguments typically come from people who have seen the model held up as design criteria for a particular project. For the purposes of education about network protocols, it is well-suited.

One final quibble with the OSI model that you may hear is that "TCP/IP uses a four-layer model". While it is true that the designers and implementors of TCP/IP thought of their work in terms of fewer layers, that has partly to do with the fact that their task was a much narrower one than ours. It is possible (and even easier) to explain the role that TCP/IP play in Internet applications using the 7-layer model.

2 Physical

The physical layer describes the standards of wiring and connection that a local network may use. If the network is wirelss, then the pysical layer will describe signal frequencies and strengths. If the network uses cables, the type and length of cables will be specified.

Category V Cable

Most networks nowadays (including those used in most offices) use Category V (often pronounced "cat five") twisted pair cabling with RJ-45 connectors. Category V cabling just means that there are eight strands of copper wire twisted into four distinct pairs. The "five" refers to the number of twists per length of the pair; Category III cable looked much the same as Category V, but had fewer twists per given length of cable.

RJ-45 Connectors

Cables are useless if you cannot plug them into useful devices. There are many sorts of connectors, plugs, and antennas, but the one commonly used on Category V cable is the RJ-45.

RJ-45 connectors look a lot like the connectors you see on your telephone cables, only they are wider and have more contact grooves. Have a look at the cable that plugs your telephone into the wall sometime. You'll see that there are six grooves in the connector, of which two have copper contacts. That type of plug is referred to as an RJ-11 connector.

3 Data Link

The link layer describes what types of signals are sent over the physical interface. The most common of these is called Ethernet. Ethernet was originally designed for wireless communication (hence the name). The ethernet protocol assumes that all machines on an ethernet network are sharing the same communication medium, and that only one node may transmit data at a time.

Ethernet

The physical layer of most ethernet networks involves a shared piece of wire that the nodes communicate on, or a single wireless frequency that the nodes broadcast to and listen on. Often we express this concept by saying that a particular network is "flat".

The problems that ethernet solves are:

1. How do you know that the information on the wire is from a particular machine?
2. How do you know that the information on the wire is intended to be received by a particular machine?
3. What do you do if two machines transmit at the same time? How do you prevent or recover from that?

Ethernet Packets

Ethernet is a packet-driven network. That is, it uses discrete chunks of information known as "packets" or "datagrams". In order to send a long stream of data from machine A to machine B, machine A must send it in chunks of a certain fixed maximum size.

Ethernet solves problems 1 and 2 by creating a sort of "packet envelope" that it puts around the chunk of data. This envelope is referred to as the packet header, since it mostly appears at the beginning of the packet.

A standard Ethernet packet, complete with headers, looks something like this:

The addresses are typically hard-coded into the ethernet hardware itself. This means that each ethernet card, hub, or router has its own ethernet hardware address (often called the MAC address). MAC addresses are 48-bit numbers (6 bytes long) that uniquely identify the hardware in question.

The type field is a simple number that simply indicates whether the packet is meant to send data to a machine, or if it is supposed to perform some ethernet housekeeping function.

Then we have the data to be sent. An ethernet packet has a minimum payload of 46 bytes of data, and a maximum of 1500. In order to send more data than 1500 bytes, a system would have to send more than one packet.

Finally, we have a Cyclic Redundancy Check. This is a simple checksum used to verify that the packet reached its destination without any damage. If the recipient machine sees a packet with a CRC that doesn't match the data, it will simply ignore the packet.

A Sample Transmission

So when machine A sends an ethernet packet to machine B, it first transmits machine B's MAC address. Machine B is listening on the wire (or radio frequency) for its own address. Once it sees this, it recognizes that the message to follow is for it, and begins to save the rest of the packet as it comes in.

Machine B notes that the packet is from machine A, that it is a normal data packet, and that the CRC matches up with the data it received. The packet successfully received, it goes back to listening for other packets addressed to it.

Collision Detection

But what if machine A and machine B try to transmit at the same time? Surely that would result in garbled packets being sent out. Well, ethernet devices do what normal people do in conversation: they listen as they speak; and if they realize that they're talking over someone else, they wait a little while and try again.

But human beings often notice the collision at the same time and try again at the same time. Too often one ends up saying "No, you go ahead" at the same time as the other speaker. It would do us no good if ethernet devices all waited exactly five milliseconds before retransmitting: we would just experience an identical collision five milliseconds later, and then ten after that!

Ethernet devices wait a random amount of time before retransmitting, in the hopes that the other device's random number generator will come up with a different pause.

Collision Avoidance

Some older link-layer protocols, however, take a different tactic. They assume that collisions are costly to recover from, and instead try a strategy of collision avoidance.

Collisions are difficult, because they force the sender to wait an arbitrary amount of time without re-sending data. On a network with very few machines, one can assume that collisions will be rare. On larger networks, collisions are far more frequent, and can reduce the functional capacity of the network.

Token Ring

Token ring attempts to divide up the local network into fair allocations of bandwidth. A token is passed from machine to machine, and each host gets to transmit for a short time before handing the token on to the next host in the ring. It's much like the "talking stick" used in some storytelling rituals: the one holding the stick is the only one allowed to speak.

Circuit Switched Networks

Some network protocols work much like the telephone system: a computer may establish one of a finite number of network connections with another host, and disconnect when the transmission is over. This has the advantage that no collisions will occur once a connection is made, but the finite number of available connections mean that one can get a "busy signal" collision before any data are sent.

However, one use of a popular circuit switched network is that of a PPP connection using a modem. Modems are physical layer devices that translate information into sound waves so that it can be transmitted over a telephone connection. PPP is the link-layer datagram protocol most commonly used over modems.

4 Network

The wide variety of link-layer protocols, and the limitations of many physical-layer configurations make it impractical to connect every machine with these schemes. If we wish to connect an ethernet network in San Francisco to a token ring network in Seattle, we have a problem: Ethernet hardware expects to be able to recover from collisions, while token ring assumes a clear channel to broadcast on. The two protocols are completely incompatible.

So we need to define a common internetwork packet format, and come up with a way for packets to get "translated" to and from the local link-layer protocol.

IP Datagrams

The Internet Protocol is a datagram protocol, much like Ethernet. IP, however, does not broadcast, or specify any particular physical method of transmitting the data. These packets could be sent via Ethernet, Token Ring, a point-to-point frame relay, or even carrier pigeon (see RFC1149 for more information).

An IP Datagram is similar to a letter sent via the US postal service. One fills out an envelope with the destination and return address, and then sticks it in the mailbox. A mail carrier takes your envelope out of the mailbox, verifies that it is valid mail, and sticks it in a bag. The post office takes the letter out of the bag, looks at the destination, and sticks it in a crate destined for the appropriate destination post office. The destination post office takes the letter out of the crate, reads the address, and puts it in a bag for a letter carrier. The carrier then takes it out of the bag and puts it in the mail slot for the recipient.

At each leg of the journey, a postal employee takes the envelope out of the container it arrived in, looks at the destination address, and figures out how to send it on the next leg of its journey. At no point is the source or destination address re-written. The envelope is merely transported within larger containers. These containers can be nearly anything: wheelbarrows, backpacks, pneumatic tubes, or even bottles.

In the same way, an IP datagram is contained as the data of an Ethernet or Token Ring packet. A single IP datagram may be transmitted via any number of link-layer protocols along the way.

The packet that follows is by no means complete or correct. It is meant to give an idea of the sort of information that an IP packet works with in a typical transmission. I have left out the headers that deal with fragmentation (is this the second half of a packet that had to be broken in two to fit over a modem?), Type Of Service, etc.

• The length in bytes of the total packet, including the IP header.
• The Time To Live, or the amount of time to wait before giving up on delivering the packet.
• A checksum.
• The source address (a 32-bit integer).
• The destination address (a 32-bit integer).

An Example Message

IP works so well because it relies on the notion of a router. A router is a computer that performs the task of the postal employee in the story above. The router takes care of the details of a particular link-layer protocol so that the rest of the network won't have to.

Let's imagine that we have two networks: one in Seattle and one in San Francisco. San Francisco is using Ethernet, and Seattle is using Token Ring. The Seattle machines are named A, B, and C, and the San Francisco machines are named 1 through 4.

Let's begin by sending an IP datagram from machine 3 to machine 1. The Datagram begins by looking like this:

Note that the addresses are just numbers. For simplicity's sake, the last of the four numbers in each address corresponds to the name of the machine whose address it is.

So, in order to send the IP datagram out on the wire, machine 4 has to figure out how to send it. Fortunately, machine 3 has a routing table, which contains the following line:

Kernel IP routing table
Destination	Gateway	Netmask	Use Iface
10.0.0.0	0.0.0.0	255.0.0.0	eth0

Let's explain what this means for a moment. The routing table defines how certain types of IP addresses are handled. In our case, we are looking for how to send a message to 10.0.0.1, so we look at the Destination and Netmask fields.

The Netmask field is set to 255.0.0.0, which means "the last three numbers in the address are the machine's specific ID, and the first number is the one you use for figuring out where to send the packet." Thus, we pay attention to the first number in the Destination field, which is set to "10". Since the first number in our destination address is also 10, we know that this is the rule we want to use.

The Gateway field is empty, which means that we won't be handing this packet off to another router for relay. So, we look straight to the "Use Iface" field, which tells us to send our packet out of ethernet device number 0.

In doing this, our IP datagram gets wrapped in an ethernet packet. A protocol named ARP discovers 10.0.0.1's MAC address, and thus our packet now looks like this:

So, Machine 3 sends the packet out on the wire:

5 Transport

TCP

The Handshake

Retransmission

6 Session

HTTP

SMTP

7 Presentation

HTML

RFC822

8 Application

Common Applications

9 Conclusion