4 Encapsulation and PDUs

4.2 Overview: Wrappers Give Each Layer a Job

Encapsulation is the way a network layer turns the data it receives into the unit it can carry. The application creates a message. The transport layer adds delivery context and creates a segment or datagram. The network layer adds network addressing and creates a packet. The link layer adds local delivery and error-check context and creates a frame. The physical layer sends bits.

Decapsulation is the reverse path at the receiver. Each layer checks and removes its own wrapper, then passes the remaining payload upward. The important habit is to name the unit by the outermost wrapper you are inspecting.

For example, a temperature value may begin as a small application reading, but by the time it reaches the radio it is no longer just that value. It may be inside a CoAP message, a UDP datagram, an IP packet, and a Wi-Fi or IEEE 802.15.4 frame. A gateway capture that sees the link wrapper should call the captured unit a frame, even though the frame contains a packet and the packet contains a datagram. That naming discipline prevents a review from mixing application meaning with transport delivery, routing scope, and local-link behavior.

Before overview: wrappers give each layer a job, inspect Figure 4.1: PDU Encapsulation: One Sensor Reading Becomes a Frame must be considered with Application data. That visual pairing grounds each layer adds the information needed for its own scope, while treating the higher-layer result as payload in named evidence.

Use Application data to test PDU Encapsulation: One Sensor Reading Becomes a Frame in the diagram at Figure 4.1. Then inspect temperature = 23.5 C as the final qualifier on each layer adds the information needed for its own scope, while treating the higher-layer result as payload. That sequence keeps overview: wrappers give each layer a job tied to what is visibly labelled.

4.3 Practitioner: Build a Packet Trace Record

A useful encapsulation review does not stop at naming layers. It records what each wrapper proves, what field or observation supports the claim, and what would make the trace suspicious.

For an IoT message, trace the application payload down the stack at the sender, across the local medium, and back up at the receiver or gateway. Focus on evidence that a reviewer can inspect: capture location, outer PDU, addressing scope, payload owner, and failure clue.

The trace record should also state what changed since the last good capture. A new security wrapper, a different transport, a gateway move, or a larger diagnostic payload can change the outer PDU size without changing the application value. That is why a useful review keeps the raw capture, the decoded layer names, and the release decision together.

Before labelling a capture, inspect Figure 4.2 to see how the unit’s name follows its current outer wrapper. The diagram gives a reviewer a consistent vocabulary for comparing evidence captured at different boundaries.

Read Figure 4.2 from application data into the transport segment or datagram, then follow the network packet into the link frame and physical bits. Each step wraps the higher-layer result without changing which layer owns the inner meaning. In the reverse direction, the receiver validates and removes those wrappers. This sequence connects precise PDU naming to the capture point and failure clue kept in the trace record.

4.4 Under the Hood: Overhead, MTU, and Compression

Every wrapper has a cost. Headers and trailers carry useful control information, but they also consume airtime, link budget, queue space, and processing effort. This matters most when the payload is small, the link frame budget is tight, or the radio sleeps between messages.

MTU pressure appears when the network packet plus lower-layer wrapper does not fit cleanly into the link frame. Fragmentation can be valid, but it increases failure exposure because losing one fragment can invalidate the whole higher-layer packet. Compression techniques and smaller application payloads are ways to reduce that pressure when they fit the protocol and deployment.

A reviewer should compare wrapper cost with the control value it buys. A few bytes of port, sequence, integrity, or security context may be essential for a command path, while the same overhead may be excessive for a tiny periodic reading. The boundary is not "fewest headers wins"; it is whether the flow can meet its latency, energy, reliability, and observability requirements after all wrappers are counted. When the budget is tight, the options are to compress repeated fields, batch readings, reduce payload verbosity, change the link, or move the work to a gateway that can afford the wrapper stack.

Before reducing overhead, inspect Figure 4.3 to see why each header exists on the sending path and what the receiver must validate before removing it. The diagram makes wrapper cost inseparable from the delivery contract it provides.

Read Figure 4.3 down the sender stack as each layer adds its own addressing, delivery, or integrity context. Then follow the receiver upward as those wrappers are checked and removed to recover the application payload. A missing fragment or invalid wrapper interrupts that reverse path. This connects the byte budget to the chapter’s design rule: optimise only after identifying which layer creates the cost and which contract would be weakened.

To see why evidence must be measured at the correct layer, inspect Figure 4.4 before treating all non-payload bytes as waste. The byte layout shows which wrapper owns addressing, delivery, integrity, and link-local handling.

Read Figure 4.4 from the application payload outward through transport, network, and link wrappers. Note which fields are added at each boundary, then compare their combined size with the useful sensor value. The result connects packet capture evidence to the design decision: compression, batching, fragmentation avoidance, or payload redesign should target the layer that actually creates the cost.

Header Fields That Carry the Contract

The wrapper is not one anonymous block of overhead. Each layer's header carries specific fields, and a reviewer who can name a few of them can read a packet trace instead of just weighing its size. Three commonly captured headers illustrate the pattern.

Two device names come directly from this table. Because a switch normally inspects only the Ethernet header and a router normally inspects only the IP header, network teams describe devices by the highest header they act on: a Layer-3 switch makes forwarding decisions using the IP header instead of only the MAC address, while a Layer-4 or Layer-7 load balancer reads the TCP port or the application payload to decide where a connection goes. The label names the layer the device is willing to open, not a claim about the rest of the stack.

4.5.1 Predict Where Decapsulation Stops

Packet capture points change which wrappers are visible. A capture before a tunnel begins can show the original transport ports, while a capture outside may show only the tunnel’s network conversation. Name the interface and layer beside every encapsulation trace so two valid captures are not mistaken for conflicting evidence.

Use the byte view in Figure 4.4 to locate the same boundary numerically. A 12-byte application reading might gain an 8-byte transport header and a 20-byte network header before the link wrapper is added. The network packet is then 12 + 8 + 20 = 40 bytes. Only 12 / 40 = 30% is the original reading at that point. The wrappers are overhead for payload efficiency, but they are required information for process and host delivery.

The ownership view in Figure 4.5 links each wrapper to the component that acts on it. The application owns the reading format. The operating system commonly builds transport and network state. The network interface and local link handle the frame. This ownership map helps place a capture: an application log cannot prove which link frame crossed the cable, while a link capture may not explain the decoded boiler value.

On receipt, each layer checks and removes only its own wrapper before passing the enclosed unit upward. That symmetry is why a protocol data unit changes names by layer without becoming a different original reading. The data is nested, not copied into unrelated messages at every step.

• Predict: A frame checksum fails on the first hop. Will the receiver decode the application data? Check: No. The damaged link frame is rejected before its higher-layer payload can be trusted.
• Predict: A router changes the link wrapper for the next hop. Must it also rewrite the boiler reading? Check: No. The application payload remains inside while a new local frame carries the packet onward.