Chapter 4 Review

Network layer ★ Chapter review Kurose & Ross p. 364 · ~16 min read

  • data plane
  • control plane
  • forwarding
  • middlebox

Where you are

  • Application layer
  • Transport layer
  • Network layer you are here
  • Link layer
  • Physical layer

Everything in this chapter was one router deciding, in nanoseconds, which way a packet leaves — and everything that decision turned out to depend on.

What this page is

  • The chapter in one picture — every idea, linked to the section that taught it.
  • The argument in six steps, which is how the chapter actually hangs together.
  • Every number worth remembering, sortable.
  • The book’s misprints, collected, so you are not caught by them.
  • A closing quiz on the chapter as a whole.

Where you are

Chapters 2 and 3 were the network edge: application and transport, both running only in end systems. Chapter 4 was the first that runs inside the network — there is a piece of the network layer in every host and every router.

It covered only half of the network layer. The data plane is what one router does to one packet. The control plane — how the tables that drive it get filled in — is chapter 5. After that, chapter 6 is the link layer, and the journey down the stack is finished.

The chapter in one picture

Chapter 4, in one picture

Hover an idea to see what it connects to. Click one to go back to the section that taught it.

Hover a node to dim everything it does not touch. Click one to go back to the section that taught it. Five groups: the frame, the machine, the protocol, the generalisation, and what else is in the path.

Read this map as a list
  • data plane (4.1) — connects to forwarding, best-effort service
  • control plane (4.1 · ch 5) — connects to routing
  • forwarding (nanoseconds) — connects to data plane, input port
  • routing (seconds) — connects to control plane, remote controller
  • best-effort service (4.1) — connects to data plane, the narrow waist
  • input port (4.2.1) — connects to forwarding, longest prefix match, switching fabric, match plus action
  • switching fabric (4.2.2) — connects to input port, head-of-line blocking
  • longest prefix match (4.2.1) — connects to input port, CIDR a.b.c.d/x, route aggregation
  • head-of-line blocking (4.2.4 · 58 %) — connects to switching fabric, buffer sizing
  • buffer sizing (4.2.4 · RTT·C/√N) — connects to head-of-line blocking, bufferbloat, packet scheduling
  • bufferbloat (4.2.4) — connects to buffer sizing
  • packet scheduling (4.2.5 · WFQ) — connects to buffer sizing
  • IPv4 datagram (4.3.1 · 20 bytes) — connects to time-to-live, fragmentation, IPv6
  • time-to-live (4.3.1) — connects to IPv4 datagram
  • fragmentation (4.3.1 · 8-byte units) — connects to IPv4 datagram, IPv6
  • interface (4.3.2) — connects to subnet
  • subnet (4.3.2) — connects to interface, CIDR a.b.c.d/x
  • CIDR a.b.c.d/x (4.3.2) — connects to longest prefix match, subnet, route aggregation, DHCP
  • route aggregation (4.3.2) — connects to longest prefix match, CIDR a.b.c.d/x
  • DHCP (4.3.2-dhcp) — connects to CIDR a.b.c.d/x, NAT
  • NAT (4.3.3) — connects to DHCP, middlebox
  • IPv6 (4.3.4 · 128 bits) — connects to IPv4 datagram, fragmentation, tunnelling
  • tunnelling (4.3.4 · protocol 41) — connects to IPv6
  • match plus action (4.2.1 → 4.4) — connects to input port, flow table
  • flow table (4.4 · 12 values) — connects to match plus action, SDN, firewall / IDS
  • SDN (4.4 · ch 5) — connects to flow table, remote controller, NFV
  • remote controller (4.1 · 4.4) — connects to routing, SDN
  • middlebox (4.5 · RFC 3234) — connects to NAT, firewall / IDS, NFV, web cache, TCP splitter, the narrow waist
  • firewall / IDS (4.3.3 · 4.5) — connects to flow table, middlebox
  • NFV (4.5) — connects to middlebox, SDN
  • the narrow waist (4.5) — connects to middlebox, best-effort service, end-to-end argument
  • end-to-end argument (4.5 · Saltzer 1984) — connects to the narrow waist
  • web cache (ch 2.2.5) — connects to middlebox
  • TCP splitter (ch 3.7) — connects to middlebox

The argument, in six steps

1 — Split the problem in two

Before any mechanism, section 4.1 separated forwarding — one router, one packet, nanoseconds, hardware — from routing, which is the whole network, seconds, software.

Everything else follows. The chapter is the first half; chapter 5 is the second.

The two planes, and everything that follows from the split
Data planechapter 4Control planechapter 5
The job
Scope
Timescale
Implemented in
Which part of a router
What it produces or consumes

Cells marked ⓘ have a reason behind them — click to read it.

Section 4.1 drew this distinction before any mechanism. Every row below is a consequence of it.

2 — Discover what the network layer actually promises

Best-effort service. No guarantee of delivery, order, delay or bandwidth. The book presses the point: a network delivering no packets would satisfy the definition.

This answers the question chapter 3.1 left open. TCP (Transmission Control Protocol) had to build reliability itself precisely because nothing underneath supplies it.

And section 4.5 reveals it as a strength rather than poverty. A promise that small can be constructed from a wide range of underlying technologies. That is what let Ethernet, WiFi (IEEE 802.11 wireless LAN) , cellular and optical networks all join one Internet.

3 — Open the router

Four components: input ports, switching fabric, output ports, routing processor. The first three are hardware, because a 64-byte datagram on a 100 Gbps link leaves 5.12 nanoseconds.

The forwarding table stores prefixes, not addresses — four entries instead of four billion — and when several match, the longest wins.

Queues form at both ends. At the input they cause head-of-line blocking, capping throughput at 58 %. At the output they cause loss, and the buffer sizing that prevents it turns out to trade loss for delay — with bufferbloat as the pathological case. Then something must choose which queued packet goes next, and that choice is where net neutrality begins.

4 — Meet the actual protocol

The IPv4 (Internet Protocol version 4) datagram, 20 bytes, every field earning its place. Then addressing, which the book insists is the interesting part and is right:

  • an address belongs to an interface, not a device;
  • a subnet is an island left when you detach the interfaces;
  • CIDR (Classless Interdomain Routing) writes the prefix length after a slash, so blocks can be any size;
  • route aggregation lets one advertisement cover eight organisations;
  • and longest prefix matching — from step 3 — is what lets an organisation change provider without renumbering.

DHCP (Dynamic Host Configuration Protocol) hands out the addresses. NAT (Network Address Translation) lets a whole home share one. IPv6 (Internet Protocol version 6) gives up on 32 bits entirely, and removes fragmentation, the header checksum and the options field — every one of them to shrink the number from step 3.

5 — Notice that forwarding was a special case

Section 4.2.1 had already observed that the input port’s job has a shape: match on a header field, take an action.

Section 4.4 makes it general. Match on any of 12 values across three layers; act by forwarding, dropping, duplicating or rewriting. Now a router, a switch, a firewall, a NAT and a load balancer are one device with different table entries. And the table is an API (Application Programming Interface) that a remote controller programs.

6 — Ask whether any of it should be there

Section 4.5 collects the middleboxes that sit in the path doing something other than forwarding. Then it stages the argument: an architectural abomination, or things that exist for important and permanent reasons.

Then the two principles that frame it. The narrow waist — one network-layer protocol beneath many of everything else — which middleboxes may be widening. And the end-to-end argument: a function needing the endpoints’ knowledge cannot be completed in the network, though an incomplete version there may be a useful performance enhancement.

That last sentence retroactively justifies the whole of section 3.4.

Every number worth remembering

Every number in chapter 4 worth remembering
NumberWhat it is

Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.

Sort by section, or by what the number is. The three highlighted rows are the ones that explain a design decision rather than describe one.

What this chapter changed about earlier chapters

The book’s misprints in this chapter, collected

Each is recorded on the page where it appears. None of them changes an argument; all of them will confuse a reader checking the arithmetic.

  • §4.2.4, bufferbloat — three inconsistent numbers. Figure 4.10(a) labels the round trip 250 ms; the text says 200 ms. The text also says 20 ms to transmit a packet. But it then says the 21st packet is transmitting at t = 200 ms, and that the queue settles at five — both of which need 10 ms. At the printed 20 ms the queue settles at fifteen.
  • §4.3.2, class B capacity. Printed as 65,634 in one sentence and 65,534 two sentences later. The second is correct: 2¹⁶ − 2.
  • §4.3.2-dhcp, Figure 4.24. Uses transaction ID 654 for the first two messages and 655 for the last two. [RFC 2131] requires one identifier for all four — it is the only thing tying the exchange together.
  • §4.3.3 names only one of the three [RFC 1918] private blocks. The others are 172.16.0.0/12 — a /12, not a /16 — and 192.168.0.0/16.

And one thing the book skips that its own problems need

§4.3.1 does not cover IP fragmentation, saying readers can find it online among retired material. But three header fields exist for nothing else, and review question R20 plus several problems ask about it.

Section 4.3.1 covers it here, on the canonical example: a 4,000-byte datagram meeting a 1,500-byte link becomes fragments of 1,480, 1,480 and 1,020 bytes, at offsets 0, 185 and 370.

Check yourself

Check yourself — the whole chapter

0 of 7 answered
  1. 1.What single number explains why a router's data plane is hardware and its control plane is software?

  2. 2.predictSection 4.1 said the Internet's network layer guarantees nothing. Section 4.5 called that a strength. How can both be true?

  3. 3.Longest prefix matching was introduced in §4.2.1 as a lookup rule. Where does it do load-bearing work?

  4. 4.predictIPv6 removed fragmentation, the header checksum and the options field. What did those three removals have in common?

  5. 5.What makes load balancing expressible in generalized forwarding but not in destination-based forwarding?

  6. 6.predictThe end-to-end argument says a function needing the endpoints' knowledge cannot be completely implemented in the network. What does its parenthesis add?

  7. 7.Chapter 4 covered the network layer. What is left of it?

The chapter in three lines

  • The chapter is one generalisation. Section 4.2.1 matches a single field — the longest destination prefix — and section 4.4 matches any of eleven, across three layers. Same machine, wider question.
  • TCP’s whole reliability apparatus exists because the layer below offers best-effort service — and the end-to-end argument in section 4.5 says it could not have been finished anywhere else.
  • Changing the network layer is like replacing a foundation; changing the application layer is like painting. IPv6 is what the first costs, and QUIC (Quick UDP Internet Connections) is what the second buys.