8 Packet Switching and Performance

8.4.1 Edge and Core: Two Different Forwarding Styles

Not every hop makes its local decision the same way. Real networks are usually built in two layers: an edge of Ethernet switches connecting cameras, sensors, gateways, and access points at each site, and a core of IP routers carrying traffic between sites over a backbone. The two layers forward packets by different rules.

An ordinary learning Ethernet switch records source MAC addresses and their ingress ports. For an unknown unicast destination, it floods the frame out every other port in its VLAN until it learns the destination, subject to configured policy. Known unicast traffic uses the learned table. An unmanaged switch needs no configuration, so it is plug-and-play, but flooding and broadcast domains limit scaling. IP routers instead forward from a route table populated by connected, static, or learned routes; they do not flood an unknown destination across the network. Routers require routing state and configuration, but scale better between networks.

For an IoT deployment, local sensors may share a bridged Ethernet or Wi-Fi network, while traffic to another subnet or the cloud needs routing. Local networks can also be divided into routed VLANs. A device that works on one local segment may still need the correct address, gateway, policy, and route to reach another building or cloud service.

8.4.2 Router Internals: Queues, Backplane, and Planes

A network router is more than one input port and one output port. Physical interfaces receive frames, line cards hold queues and forwarding hardware, and an internal backplane or switch fabric moves packets between those interfaces. A small router may share memory or a bus for this transfer. A high-capacity chassis uses switched fabrics and line cards so several ports can move traffic at once.

Provision that fabric against offered port load rather than naming it merely “fast.” Using the source notation, backplane speedup is the aggregate backplane capacity divided by port capacity; input and output speedup compare their respective backplane-side capacities with the port capacity. Output-only queueing exposes the extreme case: if every input sends to the same output at once, the output side would need speedup equal to the number of ports to absorb the whole burst. Combined input-output queueing reduces that demand and can improve utilisation, but requires harder scheduling and backpressure logic.

A switched backplane can carry several disjoint input-output transfers at once. Some designs divide packets into fixed-size internal cells; 64 bytes is an illustrative cell size, not a universal router standard. Uniform cells simplify scheduling but may need padding or reassembly. Commercial designs place forwarding in ASICs while a route-processor CPU runs control-plane routing; a PC router uses NICs on a PCI bus and a commodity CPU for both. In a slotted chassis, line cards and the route-processor card can be replaced, including hot-swap where the platform supports it.

Read Figure 8.5 from left to right to find where a packet inside a router can be made to wait.

+

Packets arrive on the input interfaces, and each line has its own input queue. The backplane in the middle moves them across, and the panel beneath it names the three ways that middle can be built: shared memory, a shared bus, or a switched bus. Capacity rises along that list. Output queues then hold packets until their interface can send. The note at the foot of Figure 8.5 is the failure this section cares about. A line card holding one busy output can block packets queued behind it that were bound for free outputs, so the queue, not the link, becomes the limit.

Queue placement changes the failure mode. An input-queued router can be simple, but a packet waiting for one busy output can hold packets behind it that were destined for free outputs. That is head-of-line blocking. Output queues avoid that particular block by collecting packets at the egress side, but they require enough fabric and buffer capacity to absorb bursts. Virtual output queues split each input into per-output queues, reducing head-of-line blocking at the cost of more buffer and scheduling complexity.

Use Figure 8.6 to see why one blocked packet can delay packets headed for free outputs.

+

Begin with one FIFO at each input. When the packet at the head wants a busy output, it cannot move, even if the next packet wants an idle output. That second packet is trapped behind the first: head-of-line blocking couples unrelated flows and wastes available output capacity. Virtual output queues separate an input’s packets by destination, allowing the scheduler to choose an unblocked queue. The new structure does not eliminate congestion; it moves the design question toward arbitration, buffer size, fairness, and backpressure. Queue telemetry should distinguish blocked heads from a truly saturated backplane or output.

Keep the control plane and data plane separate in incident notes. The control plane computes routes, learns topology, and updates forwarding tables. The data plane applies those tables at line rate: classify, queue, forward, mark, or drop. A route processor or controller can be healthy while one output queue is congested, and an output queue can be empty while the routing table is wrong. Good evidence names which plane made the decision and where the packet waited.

Figure 8.7 separates the two jobs by how often each one runs.

+

Start at the top box of Figure 8.7. It runs routing protocols and updates the forwarding table as topology or policy changes. The dashed arrow shows those updates being installed in the data plane. The fabric and line cards then apply the current installed table to packets at line rate; exceptional packets can still be sent to the control processor. A healthy control plane can sit above a congested output card, and a card can forward consistently using stale or incorrect state.