Category Archives: Networking

The OSI network stack: An analogy

Since I moved into writing networking software a couple of years ago, I’ve read quite a few books to try and get myself up to speed with it. Most of them seem compelled to start off with a description of the 7-layer OSI network stack, but in my experience the quality of the explanation is rarely very good. I think there are two things that you need to get across: how the OSI layers are defined, but first and more importantly why you would want to build a layered conceptual model in the first place. It’s the latter that I mostly feel needs improvement.

By no means do all books need to cover the motivation for a layered model. Certainly the books that are targeted at software engineers (rather than network engineers) can probably assume that the reader is familiar with the benefits of modularisation. However, if you’re going to attempt an explanation, it may as well be a cogent one.

Here’s my attempt at an analogy: suppose you want to send a package to your friend in another country. You write the address on it and call up UPS. Someone arrives and takes the package off you, and a few days later the package arrives with your friend.

Now suppose you are a UPS delivery driver. You arrive for work in the morning, and your computer tells you where to go and which packages to pick up and drop off. You don’t know where the packages are ultimately going to or from, you just need to shuttle them to or from the local hub. But there isĀ  bunch of stuff you do care about. You care if your van breaks down. You care whether traffic on the road is going to prevent you from getting round all your deliveries in time. You care about cases where the recipient isn’t available and the package will have to be delivered again the next day.

Suppose now you run a regional office of UPS. Every day you get thousands of requests to collect packages. You route the packets to your sorting office, and decide what to do with them. Some of them are targeted at people within your region, so you send them out on the next delivery. The rest of them are targeted at people in different regions. These you simply send in bulk to the regional hub for the appropriate region. Note that the truck you send out only has instructions to go to the next regional hub. They have no idea where the packages in their truck are actually addressed to, and they don’t need to care.

Suppose now you are operational manager for the whole of UPS. You have a bunch of regions, with packages flowing between them. Your daily reports tell you how many packages come out of each region, and how many go in. Maybe a particular region starts to get more and more packages, and you have to arrange for more trucks. Maybe some routes between regions are done by truck and some by aircraft. But what you don’t need to worry about is what goes on within each region. Other people take care of that.

Each of these layers could be replaced without the others needing to care too much. The global manager could introduce hovercrafts on some inter-region routes. The regional manager could outsource his delivery to a different company (or to several companies). The delivery driver could take on tasks from UPS and moonlight for another delivery company. The sender could choose to use FedEx or DHL and get much the same experience.

Another complication is what happens when one delivery company has to interface with another. Suppose UPS doesn’t have any operations in Elbonia, and has to deliver a package there. No problem, they just deal with the local package delivery company and agree on how and where the packages are to be handed over, and what information needs to be on them. Quite how the packages reach their destination (perhaps by pig cart) doesn’t concern them. They don’t even need to know how Elbonian street addresses work, provided they trust the sender to have written it correctly, and provided the package has enough readable information on it that they can route it to Elbonia.

Now, this analogy isn’t perfect (side note: it’s not the job of analogies to be perfect. It’s the job of analogies to convey critical ideas with the minimum of irrelevant detail). And I’m sure I’m not the first person to attempt this analogy. However, I do think this analogy covers the critical points, and that the cognitive friction of it is low.

What this analogy doesn’t do is try hard to map directly to the actual layers of the OSI model, but I don’t think that is necessary. The details of the OSI model are driven by the needs of networking equipment, and analogies only get you so far here. Anyone with some affinity for software and hardware design should grasp the details quickly.

I believe there are two points that need further explanation. The first is what role the OSI model actually plays: it’s not a strict specification, and routing protocols aren’t written to “comply” with it. The mapping of actual technologies into OSI layers is often imperfect (e.g. Ethernet crosses layers). The other point that deserves some more explanation is the difference between layer 3 addresses and layer 2 addresses. There is no direct real-world analogy to this in package delivery, but the distinction is important. The risk of the “UPS” analogy is that it implies that layer 3 is just layer 2 “scaled up” to larger distances, and such an idea would be completely wrong.