You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
The previous lesson showed the internet layer producing packets and handing them to the network. This lesson follows those packets out into the world: how data is chopped into them, what each one carries, how it is routed hop-by-hop across many independent networks, why packets can arrive out of order and how the destination puts them back together. We contrast packet switching with the older circuit switching of the traditional telephone network, and — most importantly for the exam — we explain why packet switching scales to a planet-sized network in a way circuit switching never could.
Packet switching is the foundational idea of the modern Internet. Rather than reserving a private wire between two parties for the duration of their conversation, the network treats every packet as an independent, self-addressed parcel that finds its own way through a shared web of links. The pay-offs — efficiency, resilience and scalability — and the costs — variable delay, possible loss and the need for reassembly — all flow directly from that one decision to make packets independent. Keep that cause-and-effect in view and the whole topic hangs together.
This lesson covers the OCR H446 1.3.3 / 1.3.4 material on packet switching, specifically:
Examiners reward candidates who can describe the journey of a message end to end (split, address, route, reorder, recover) and who can justify why packet switching suits data networks while circuit switching suited voice — not merely tabulate differences.
Packet switching is a method of transmitting data in which the data is divided into small, independently addressed units called packets. Each packet is sent separately across the network, routed hop-by-hop by routers that read its destination address, and the packets are reassembled into the original data at the destination. Crucially, no dedicated path is reserved — packets share the network's links with everyone else's traffic, and different packets of the same message may travel by different routes.
The guiding analogy is the postal system. To send a long document you could split it across several envelopes, write the full destination address on each, and drop them in the post. The postal service routes each envelope independently — they may travel by different vans and sorting offices, and may even arrive on different days and out of order — but because each is fully addressed they all reach the destination, where the recipient reassembles the document by reading the page numbers. You did not have to hire a private courier van reserved solely for your document (that would be circuit switching); you shared the existing postal network with millions of others. Packet switching is exactly this idea applied to data: fully-addressed parcels sharing a common network.
Sending a message from computer A to computer B by packet switching follows a clear sequence. This is the single most examined description in the topic, so learn it as a narrative:
graph LR
A["Computer A<br/>splits data into packets,<br/>adds headers"] --> R1["Router 1"]
R1 --> R2["Router 2"]
R1 --> R3["Router 3 (alt. route)"]
R2 --> R4["Router 4"]
R3 --> R4
R4 --> B["Computer B<br/>reorders by sequence number,<br/>requests any missing packets,<br/>reassembles data"]
The phrase to internalise is each packet is independent and fully addressed — that one property is the source of every later behaviour, good and bad.
A packet is built from three parts: a header, the payload and a trailer.
graph LR
H["HEADER<br/>source & destination IP,<br/>sequence number, TTL,<br/>protocol, length, checksum"] --- P["PAYLOAD<br/>a slice of the<br/>original data"] --- T["TRAILER<br/>error-check value (CRC),<br/>end-of-packet marker"]
The header holds everything the network needs to deliver and order the packet:
| Field | Purpose |
|---|---|
| Source IP address | Identifies the sender, so a reply can be returned |
| Destination IP address | Identifies the intended recipient — routers forward on this |
| Sequence number | The packet's position in the original data, used for reassembly |
| Time To Live (TTL) | A hop counter that bounds the packet's lifetime (see below) |
| Protocol | Names the transport protocol the payload belongs to (TCP or UDP) |
| Packet length | Total size of the packet |
| Header checksum | An error-detection value over the header fields |
The payload is the actual content being carried — one slice of the original message. Its maximum size is bounded by the MTU; larger data is simply spread across more packets. The proportion of each packet taken up by header rather than payload is the overhead of packet switching — small per packet, but real in aggregate.
This gives rise to a genuine engineering trade-off in the choice of packet size. If packets are made large, the fixed-size header is amortised over more payload, so a greater fraction of the network's capacity carries useful data and overhead falls — but a single corrupted bit forces the whole large packet to be retransmitted, wasting more, and large packets queue for longer behind one another, raising latency for everyone. If packets are made small, retransmissions are cheap and traffic interleaves more smoothly (good for responsiveness), but the header now forms a larger share of every packet, so overhead rises and throughput falls. The MTU of around 1500 bytes on Ethernet is a long-standing compromise between these pressures. You are not expected to calculate optimal sizes, but recognising why there is a trade-off — overhead versus retransmission cost versus latency — is exactly the kind of insight that lifts an answer above rote recall.
The trailer (or footer) typically carries an error-check value — commonly a Cyclic Redundancy Check (CRC) computed over the whole frame — and an end-of-packet marker so the receiver knows where the packet stops. If the CRC the receiver computes does not match the one in the trailer, the packet has been corrupted and is discarded (and, under TCP, retransmitted). This error-checking machinery is conceptually the same family as the parity and checksum methods studied in data representation — a redundancy added so corruption can be detected.
Routing is the process of choosing the path a packet takes from source to destination. No single device knows the whole path; instead, each router makes a local decision about the next hop, and the cumulative effect of these local decisions carries the packet across the network. (Routers were introduced in the hardware lesson; here we focus on the decision they make.)
graph TD
P["Packet arrives at router"] --> Read["Read DESTINATION IP from header"]
Read --> Look["Look up best matching route<br/>in the routing table"]
Look --> Dec["Decrement TTL by 1"]
Dec --> Check{"TTL = 0?"}
Check -->|Yes| Drop["Discard packet,<br/>send ICMP 'Time Exceeded' to source"]
Check -->|No| Fwd["Forward packet out of the<br/>chosen interface to the next hop"]
A routing table maps destinations to next hops. Each entry typically holds:
| Field | Purpose |
|---|---|
| Destination network | The network the route leads toward |
| Next hop | The address of the next router on the way |
| Metric / cost | How "expensive" the route is (e.g. hop count or latency) — used to pick the best |
| Interface | Which physical port to send the packet out of |
Routers keep these tables up to date by exchanging information using routing protocols such as RIP, OSPF and BGP, which propagate knowledge of the network's topology so each router can compute good next hops. The detail of those protocols is beyond H446; what matters is that routing tables are dynamic — they change as the network changes.
Because each packet is routed independently at the moment it arrives, and conditions change continually, the packets of a single message can scatter across several paths:
This is the very feature that gives packet switching its resilience — but it is also exactly why packets can arrive out of order, which the destination must then fix.
A network of independently routing devices has a danger: a misconfiguration or a transient loop could send a packet round and round forever, wasting bandwidth. The TTL (Time To Live) field in the header prevents this:
TTL therefore guarantees that no packet can circulate indefinitely: a routing loop will burn through the TTL within a bounded number of hops and the packet will be dropped. (As an aside, this is the mechanism the tracert/traceroute tool exploits — by sending packets with deliberately tiny, increasing TTLs it provokes each router along the path to reveal itself with a Time-Exceeded reply.)
Because packets travel independently and may take different routes with different delays, they often arrive at the destination out of order, and some may be missing. Reassembly is the destination's job of recovering the original data despite this disorder:
The whole scheme works because sequence numbers make order recoverable: the network need not deliver packets in order, or even reliably, as long as each packet is labelled. This is a beautiful separation of concerns — the network does the cheap, best-effort job of moving labelled parcels, and the endpoints do the work of ordering and recovery. (Note the synoptic link: it is TCP, at the transport layer, that provides this reordering and retransmission; UDP does not, which is why UDP applications must tolerate loss and disorder themselves.)
Circuit switching is the older approach, exemplified by the traditional telephone network (the PSTN). Here a dedicated communication path is set up between the two parties before any data flows and reserved for the entire duration of the communication.
graph LR
A["Caller"] --- E1["Exchange"]
E1 --- E2["Exchange"]
E2 --- E3["Exchange"]
E3 --- B["Callee"]
classDef res fill:#e8f0ff,stroke:#3366cc;
class A,E1,E2,E3,B res;
The strength of circuit switching is a guaranteed, steady channel — once the circuit exists, bandwidth and delay are predictable, which historically suited real-time voice. Its great weakness is waste: the reserved path sits idle during every pause, yet remains unavailable to anyone else, and the network can support only as many simultaneous conversations as it has circuits.
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.