EC-11.1 Why Networks Are Built in Layers

en

What this is and why it exists

Networking is the subject where a reader most often learns a list of names without ever being told why the list exists.

The layering is not a taxonomy someone invented to organise a textbook. It is an engineering answer to a specific problem, and the problem is worth stating before the answer.

Meet that argument once and every later topic becomes a case of one general idea rather than six unrelated ones.

The vocabulary

  • Layer — one level of the design, offering a service to the level above it.
  • Service — what a layer promises to do, stated without saying how.
  • Protocol — the rules two machines follow at the same layer to talk to each other.
  • Interface — how a layer is used by the one above it on the same machine.
  • Encapsulation — wrapping data from above with a header of your own.
  • Header — the fields a layer adds in front of the data it was given.
  • Reference model — a named division into layers, used to talk about designs.

The mental model

Start with the problem. Suppose there are ten kinds of application and ten kinds of link. Without layers, each application needs code for each link, and that is a hundred pieces of software to write and maintain.

With a layer in between, each application is written once and each link is written once. Ten plus ten instead of ten times ten. Adding an eleventh link then costs one piece of work rather than ten.

That is the whole argument. Every layer in the design exists because someone made it for a pair of things that would otherwise have been multiplied together.

Now the layers themselves, described by what each is responsible for rather than by name. The physical layer carries bits over something. The link layer carries a frame between two machines that share a medium. The network layer carries a packet between any two machines anywhere. The transport layer carries a conversation between two programs. The application layer decides what the conversation means.

Read that list again as a sequence of scopes. Neighbours, then anywhere, then programs, then meaning. Each layer widens the scope of the one below it, and that is a better way to remember the order than any mnemonic.

An interface is the promise a layer makes to the one above, and the promise is deliberately narrower than the mechanism. The network layer promises to try to deliver a packet. It does not promise to succeed, to keep order, or to deliver it once.

Everything above has to be written to that promise and nothing stronger. That restraint is precisely what allows the mechanism underneath to be replaced. Radio, fibre, or something not yet invented, with nothing above it changing.

Encapsulation is what actually happens to a message. On the way down each layer wraps what it was given with its own header. On the way up each layer removes its own header and passes the rest along.

The two stacks mirror each other exactly, and a header written by one layer is read only by the same layer at the other end. A layer never reads another layer's header, at least in the design, which is why breaking that rule is worth noticing when it happens.

Two reference models are in circulation and they do not match. The seven-layer teaching model is more detailed than what was actually built, and the four-layer model describes the internet as deployed. Neither is wrong; they are used for different purposes, and a document that switches between them without saying so is the source of much confusion.

Finally, the cost. Layering adds a header at every level, adds a copy at every boundary in a naive implementation, and hides information a lower layer knew.

Real systems break it deliberately in places. A transport protocol that knows the link is radio can behave better than one that does not. Being able to name where layering is broken, and why, is part of understanding it. Treating the model as sacred is a sign of having learned the names rather than the argument.

What you should now be able to explain or do

  • State the problem layering solves, in terms of how much software must be written.
  • Place a function at the right layer by asking what scope it operates over.
  • Explain what an interface promises and why the promise is deliberately weak.
  • Describe what happens to a message travelling down one stack and up another.
  • Say which reference model a document is using and translate between the two.
  • Name a place where layering is deliberately broken and give the reason.

Check yourself

It turns a multiplication into an addition. Ten applications and ten link types need ten plus ten pieces of software rather than a hundred. Adding an eleventh link then costs one piece of work.

Because a promise it cannot always keep would have to be built into every link technology. Keeping the promise weak lets reliability be added once, at the ends, by whoever needs it.

Nothing, in the design. Each layer reads only its own header and passes the rest on, which is what allows the other layers to change independently.

Headers on every message, copies at every boundary, and hidden information. A transport protocol that cannot see that the link is radio makes worse decisions than one that can.

Go deeper

Back to Why Networks Are Built in Layers: work through the checklist