an SDN controller
Think of an air-traffic control tower. Individual planes do not negotiate with each other about who lands when; the tower has the whole airspace on its screen and issues instructions. An SDN controller plays that role for a network. It is a piece of software, running on ordinary servers, that holds a network-wide view of every switch and link, decides how traffic should flow, and pushes the forwarding rules down to the switches. The switches stop being independent decision-makers and become arms the controller directs.
Concretely, a controller sits in the middle of the SDN stack and exposes two kinds of interface. Looking down, it speaks the southbound API (commonly OpenFlow) to install, modify, and delete flow rules in the switches, and to learn about events (a new packet with no matching rule, a port going down). Looking up, it offers a northbound API to control applications — routing, load balancing, firewalling, monitoring — which express what they want and let the controller translate that into concrete rules. Because it owns a global, consistent picture, the controller is often called a network operating system: applications run on it the way programs run on an OS, and it abstracts away the messy hardware underneath.
Why it matters: the controller is what makes a network programmable from one place — the whole appeal of SDN. It is also the central risk. A single, unreplicated controller is a single point of failure and a potential bottleneck; if it dies or is cut off, switches keep forwarding on their last rules but cannot adapt. Real deployments therefore run a cluster of controllers that is logically centralized (presents one consistent view) but physically distributed, with consensus protocols keeping the replicas in agreement. Centralization buys you a clean global view; distribution buys you survival.
A switch receives a packet for a destination it has no rule for. It cannot decide alone, so it forwards the packet up to the controller and asks what to do. The controller, seeing the whole topology, computes a path, then installs a flow rule in that switch (and the others along the path) so future packets of the same flow are forwarded directly at line rate without asking again.
Ask the controller once; then forward the rest of the flow at full speed on the installed rule.
Calling the controller a network operating system is an analogy, not a claim that it is literally one. And logical centralization does not require one physical machine — production controllers are usually replicated clusters, precisely to avoid being a single point of failure.