In a software-defined network ( SDN (Software-Defined Networking) Software-Defined Networking Separating the control plane from the data plane by computing forwarding tables in a remote controller. introduced in ch. 4 ) the switches keep only their flow tables. A remote controller, with applications above it, computes what those tables should contain.
Words you will meet
-
SDN controller sdn controller Simple The remote brain that works out every switch's flow table. Precise The software, running on servers distinct and remote from the network's switches, that maintains accurate network state information, provides that information to the network-control applications above it, and provides the means by which those applications monitor, program and control the underlying devices. Its functionality divides into three layers: communication with the controlled devices, network-wide state management, and the interface to the applications. It is also called a network operating system. introduced in ch. 5 — open in glossary — the remote software that holds the network’s state and programs the switches. Also called a network operating system.
-
Network-control application network-control application Simple A program that decides what the network should do. Precise A program running in the SDN control plane, above the controller, that uses the controller's APIs to specify and control the data plane. The book's examples are a routing application that computes end-to-end paths by running Dijkstra's algorithm over the controller's state, an access-control application that decides which packets a switch should block, and a load balancer. These are the brains of the SDN control plane. introduced in ch. 5 — open in glossary — a program above the controller that decides what the network should do.
-
Northbound interface northbound interface Simple The controller's doorway upward, to the applications. Precise The API through which an SDN controller interacts with network-control applications. It lets an application read and write network state and flow tables in the state-management layer, and lets it register to be notified when state-change events occur. Two popular controllers offer it as a RESTful request-response interface. introduced in ch. 5 — open in glossary — the controller’s API (Application Programming Interface) Application Programming Interface The published interface through which one program can use another program's services. introduced in ch. 1 upward, to those applications.
-
Southbound interface southbound interface Simple The controller's doorway downward, to the switches. Precise The interface across which an SDN controller communicates with the devices it controls. A protocol is needed in both directions: to send instructions down, and to carry locally observed events such as a link going up or down back to the controller. OpenFlow is one such protocol and is implemented in most, if not all, SDN controllers. introduced in ch. 5 — open in glossary — the controller’s interface downward, to the devices.
-
OpenFlow openflow Simple The standard that pioneered match-plus-action forwarding and remote controllers. Precise A packet-switch standard [McKeown 2008] whose flow tables pair a match over up to 12 header values — 11 fields plus the ingress port, in OpenFlow 1.0 — with a list of actions. It pioneered the match-plus-action abstraction and the notion of a remote controller, and with them software-defined networking. Later specifications raised the matchable values to 41. introduced in ch. 4 — open in glossary — one protocol that fills the southbound interface, and the earliest.
-
Unbundling unbundling Simple Splitting one product into parts that different companies can supply. Precise The separation of network functionality into data-plane switches, SDN controllers and network-control applications as distinct entities, each of which may be supplied by a different vendor. The book likens it to the move from mainframes, where one vendor supplied hardware, system software and applications, to personal computers, where the three became separate markets. introduced in ch. 5 — open in glossary — splitting one product into parts that different companies can supply.
Why this matters
Section 5.1 named two ways to build a control plane and then spent four sections on only the first. Per-router control gave us OSPF (Open Shortest Path First) Open Shortest Path First The Internet’s intra-AS link-state routing protocol. Each router builds a complete map of its autonomous system and runs Dijkstra locally. introduced in ch. 5 and BGP (Border Gateway Protocol) Border Gateway Protocol The protocol ISPs use to tell each other which destinations they can reach; its rules follow the customer-provider and peering relationships. introduced in ch. 5 .
This is the second way. The routing algorithm moves out of the routers entirely and becomes an ordinary program on an ordinary server.
Section 4.4 already built the half of this that lives in the switch: generalised forwarding, match plus action, and the OpenFlow abstraction. What it never said was who fills in those tables. This section is the answer.
Four things that make an architecture SDN
SDN is a set of four characteristics, and the book lists them before drawing anything.
Flow-based forwarding. Forwarding by SDN-controlled switches can be based on any number of header field values in the transport, network or link layer. The OpenFlow 1.0 abstraction of section 4.4 allows eleven different header fields. That contrasts sharply with sections 5.2 to 5.4, where forwarding used the destination IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 address alone.
Separation of the data plane and the control plane. The data plane is the switches: relatively simple but fast devices that execute match-plus-action rules in their flow tables match-plus-action table Simple The generalised version of a forwarding table. Precise The flow table in a packet switch, generalising destination-based forwarding: each entry pairs a match over header fields with a list of actions. It is typically computed, installed and updated by a remote controller. introduced in ch. 4 — open in glossary . The control plane is servers and software that determine and manage those tables.
Network control functions live outside the switches. The control plane is software, and it runs on servers that are distinct and remote from the network’s switches. That is what a traditional router does not do.
The network is programmable. It is programmed through network-control applications running in the control plane. They are the brains, and they use the controller’s APIs to specify and control the data plane.
| A traditional routerone box from one vendor | An SDN architecturethree separate things | |
|---|---|---|
| What forwarding is based on | ||
| Where the control plane lives | ||
| Who runs the control software | ||
| How behaviour is changed |
Cells marked ⓘ have a reason behind them — click to read it.
The book’s own four bullets, each set against the arrangement it replaces. Click any cell for the detail.
In plain words
The word the book uses for the result is unbundling.
Before, a router was one product. The hardware, the control-plane software and the protocol implementations arrived together, from one vendor, and could not be separated.
Now there are three kinds of thing: switches, controllers, and applications. Each may come from a different vendor or organisation, and each is a market of its own.
The book’s comparison is the move from mainframes to personal computers. Separating hardware, operating system and applications produced innovation in all three, and the hope for SDN is the same.
The architecture
Relatively simple but fast devices that execute the match-plus-action rules in their flow tables. They compute nothing. Section 4.4 built exactly this.
Drawn top-down, like the book. Read it bottom-up and it is a stack: dumb fast hardware, one program that knows the whole network, and applications that decide what the network should do.
Read all steps as text
- The data plane: switches that only match and act — Relatively simple but fast devices that execute the match-plus-action rules in their flow tables. They compute nothing. Section 4.4 built exactly this.
- The control plane: a controller, on separate machines — Servers and software that determine and manage the switches’ flow tables. Unlike a traditional router, this software does not run inside the switch. It runs on machines that are distinct and remote from it.
- And above it, the network-control applications — These are the brains. A routing application might compute end-to-end paths by running Dijkstra over the controller’s state. An access-control application decides which packets a switch should block. A load balancer spreads requests over servers. All three are section 4.4.3’s examples, now given a home.
- Two interfaces, and they have names — The controller talks upward to the applications across its northbound API, and downward to the devices across its southbound API. Almost everything in section 5.5 is about one of these two boundaries.
”Logically centralized” is not “one server”
Figure 5.14 draws the controller as a single central server, and that picture is convenient rather than true.
The controller is logically centralized. From outside — from a switch, or from an application — it looks like one monolithic service. Inside, it is implemented on several servers that give coordinated, scalable performance and high availability.
That is not a detail. It brings every hard problem distributed systems have: ordering events in time, consistency, consensus. Modern controllers such as ODL (OpenDaylight) OpenDaylight One of the two modern SDN controller platforms the book names, alongside ONOS. Both are logically centralized but physically distributed. introduced in ch. 5 and ONOS (Open Network Operating System) Open Network Operating System An open-source SDN controller platform. introduced in ch. 5 put considerable effort into being logically centralized and physically distributed at once.
Inside the controller
The control plane divides into two components: the controller and the network-control applications. The book examines the controller first, and organises its work into three layers.
It then does something unusual, and says so: it presents them bottom-up.
To control a remote switch you need a protocol. It must carry instructions down, and it must carry locally observed events back up — a link going up or down, a device joining, a heartbeat saying a device is alive. Those events are what keep the controller’s picture current. This is the southbound side, and OpenFlow lives here.
The book presents these three layers "in an uncharacteristically bottom-up fashion", and this diagram follows it. Each layer only exists because the one above needs something from it.
Read all steps as text
- Bottom: talking to the devices — To control a remote switch you need a protocol. It must carry instructions down, and it must carry locally observed events back up — a link going up or down, a device joining, a heartbeat saying a device is alive. Those events are what keep the controller’s picture current. This is the southbound side, and OpenFlow lives here.
- Middle: remembering what the network looks like — Every real decision needs up-to-date information about hosts, links, switches and other controlled devices. The layer holds link-state information, host and switch information, the counters read out of flow tables, and often a copy of the flow tables themselves. This is the network-wide state.
- Top: offering that state to the applications — The applications need to read and write network state and flow tables, and to register for notification when something changes. That is the northbound API. Two popular controllers offer it as a RESTful request-response interface; others offer a network graph or an intent abstraction.
- And it is only logically one machine — Every earlier picture drew the controller as a single central server. From outside — from a switch, or from an application — it does look like one monolithic service. Inside, it is a distributed set of servers, for fault tolerance, high availability and performance. That brings the usual distributed-systems problems: ordering events in time, consistency, consensus.
Everyday picture
A building manager for a large office block.
The bottom layer is the radio the manager uses to talk to the caretakers. It works both ways: instructions go down, and reports of a broken lift come back up. The middle layer is the manager’s own notes — which lifts work, which rooms are booked, what every caretaker last reported. The top layer is the office where tenants come to ask for things.
A tenant never speaks to a caretaker, and a caretaker never decides anything.
Where the picture stops. One manager is genuinely one person. An SDN controller only looks like one from outside; behind the desk there is a team keeping identical notes, and keeping them identical is the hard part.
The OpenFlow protocol
OpenFlow operates between an SDN controller and an SDN-controlled switch, or any other device implementing the OpenFlow API from section 4.4.
It runs over TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 , with a default port number of 6653. That detail is worth pausing on. The southbound interface is an ordinary transport connection, so the controller can be anywhere the network can reach — which is exactly what “distinct and remote” required.
Four message types travel down. Everything the controller wants a switch to do arrives as one of these.
Click any arrow to see what that message says and why it is sent.
OpenFlow runs over TCP, default port 6653. Every arrow here is control traffic, never user data — except the payloads inside Send-Packet and Packet-in, which carry one real packet each.
Read this diagram as text
- SDN controller sends Configuration to SDN-controlled switch. Lets the controller query and set a switch’s configuration parameters.
- SDN controller sends Modify-State to SDN-controlled switch. Adds, deletes or modifies entries in the switch’s flow table, and sets switch port properties. This is the message that actually programs the data plane.
- SDN controller sends Read-State to SDN-controlled switch. Collects statistics and counter values from the switch’s flow table and its ports. Those counters are the third column of the match-plus-action table from section 4.4.
- SDN controller sends Send-Packet to SDN-controlled switch. Tells the switch to send one specific packet out of one specified port. The packet itself travels in the message payload.
Lifelines, left to right: SDN controller (server), SDN-controlled switch (link-layer switch).
| Message | Direction | What it does |
|---|---|---|
Cells marked ⓘ have an explanation — click to read it.
Direction is the thing to remember: the controller programs and reads, and the switch reports. Click a cell marked ⓘ.
In plain words
Six messages, and the split between them is the whole protocol.
The controller programs and reads. Configuration and Modify-State write; Read-State reads; Send-Packet injects one packet.
The switch reports. Port-status says something changed. Packet-in says “I have a packet and no rule for it — you decide.”
Packet-in is the interesting one, because it is how a switch that computes nothing can still handle something it has never seen. It asks. Section 4.4 called sending unmatched packets to the controller the default behaviour; this is the message that does it.
Principles in practice: Google’s B4
Google runs a dedicated wide-area network, B4, connecting its data centres and server clusters, with a Google-designed SDN control plane built on OpenFlow. Section 2.6.4 met the same network from the content side.
The results are the reason it is famous. B4 drives its WAN (Wide Area Network) Wide Area Network The public side of a home or office router — the interface facing the ISP, as opposed to the LAN side facing the home. introduced in ch. 4 links at near 70 % utilization over the long run, two to three times typical link utilization. It also splits application flows over several paths, by application priority and current demand.
The book gives three reasons B4 suits SDN particularly well.
- Google controls every device, from edge servers in IXP (Internet Exchange Point) Internet Exchange Point A building where many ISPs peer with each other; there are over 600 today. introduced in ch. 1 s and ISP (Internet Service Provider) Internet Service Provider Connects hosts, and other ISPs, to the rest of the Internet. introduced in ch. 1 s to the routers in its core.
- Its most demanding applications are large data copies between sites, and those can wait when interactive traffic needs the link rate.
- Only a few dozen data centres are connected, so centralized control is feasible.
| In B4 | Corresponds to |
|---|---|
Cells marked ⓘ have an explanation — click to read it.
The sidebar on book page 417 is a real deployment described in the same vocabulary. Every piece corresponds to something in the diagram above.
Two more details are worth keeping. The agents reach their controllers over a separate out-of-band network, distinct from the one carrying data-centre traffic — so a data-plane problem cannot cut the control plane off. And Paxos is used to run hot replicas of the network control server components, which is the “logically centralized, physically distributed” idea again, in production.
Check yourself
Check yourself
0 of 7 answered1.What does an SDN-controlled switch compute?
2.The book says the SDN controller is "logically centralized". What does that mean in practice?
3.Which of the controller's three layers does OpenFlow belong to?
4.predictA packet arrives at an SDN-controlled switch and matches no entry in its flow table. What happens?
5.Which OpenFlow message actually installs forwarding behaviour in a switch?
6.OpenFlow runs over TCP with a default port of 6653. Why does that matter architecturally?
7.Google's B4 keeps running BGP and IS-IS. Does that contradict its being an SDN network?
What to remember
- Four characteristics define SDN: flow-based forwarding, data and control planes separated, control functions outside the switches, and a programmable network. The switches compute nothing — they run match plus action from a flow table somebody else wrote.
- Northbound goes up to the applications; southbound goes down to the devices. Almost every question in section 5.5 is about one of these two boundaries.
- Unbundling is the point. Switches, controllers and applications became three separate markets, as hardware, operating systems and applications did for computers.