Data and Control Plane Interaction · SDN Past and Future

One link fails. Six numbered steps carry the news up to an application, and the answer back down to the switches. It is the same job section 5.2.1 did, arranged completely differently.

Words you will meet

Ethane — the 2007 research network that OpenFlow grew out of.
Service Abstraction Layer — written SAL (Service Abstraction Layer) : the nerve centre of the OpenDaylight controller.
Intent framework — ONOS (Open Network Operating System) ‘s way of letting an application ask for what it wants, not how.
OVSDB (Open vSwitch Database Management Protocol) — a southbound protocol for managing data centre switching.
NFV (Network Function Virtualization) — doing to middleboxes what SDN (Software-Defined Networking) did to routers.

Why this matters

Section 5.5.1 drew the controller as three static layers, and section 5.5.2 listed six messages. Neither showed the parts moving.

This section runs one event all the way through. A link fails, and the news travels up to an application. There it becomes a new set of least-cost paths, and comes back down as flow table entries.

It is worth watching closely, because the algorithm is the one you already know. Dijkstra has not changed. Only where it runs has changed, and this is where you can see exactly what that buys.

One link goes down

The example uses Dijkstra’s algorithm to determine shortest-path routes, and the book names two differences from the per-router scenario of sections 5.2.1 and 5.3.

Dijkstra’s algorithm is executed as a separate application, outside the packet switches.
Packet switches send link updates to the SDN controller and not to each other.

The link between switch s1 and s2 goes down. Shortest-path routing is in use, OpenFlow is the communication-layer protocol, and the control plane does nothing but link-state routing.

Figure 5.16 — one link goes down, and the whole control plane reacts

1 · the switch notices, and tells the controllerstep 1 of 7

Switch s1 experiences a link failure between itself and s2. It notifies the SDN controller of the link-state change with an OpenFlow port-status message. Note what it does NOT do: it does not tell s3 or s4, and it does not flood anything. Packet switches send link updates to the controller and not to each other.

The same controller diagram as Figure 5.15, with the book’s six numbered steps drawn one at a time. Only the OpenFlow box is used here: the book assumes the control plane does nothing but link-state routing.

Read all steps as text

1 · the switch notices, and tells the controller — Switch s1 experiences a link failure between itself and s2. It notifies the SDN controller of the link-state change with an OpenFlow port-status message. Note what it does NOT do: it does not tell s3 or s4, and it does not flood anything. Packet switches send link updates to the controller and not to each other.
2 · the communication layer hands it up — The controller receives the OpenFlow message indicating the link-state change and notifies the link-state manager, which updates a link-state database. This is the bottom layer of Figure 5.15 doing exactly the job it was given.
3 · the application is notified — The network-control application implementing Dijkstra’s link-state routing had previously registered to be notified when link state changes. It now receives that notification. Registering for events is what the northbound API of section 5.5.1 is for.
4 · the application reads the state and computes — The routing application interacts with the link-state manager to get the updated link state, and may consult other components in the state-management layer. Then it computes the new least-cost paths. This is Dijkstra’s algorithm from section 5.2.1 — unchanged, but running outside every switch.
5 · the answer goes back down to the flow table manager — The routing application interacts with the flow table manager, which determines which flow tables have to be updated. The application computed paths; something else turns paths into table entries.
6 · OpenFlow installs the new entries — The flow table manager uses OpenFlow to update flow table entries at the affected switches. This is a Modify-State message, the one from section 5.5.2 that actually programs the data plane.
And now compare it with a router — In sections 5.2.1 and 5.3, Dijkstra ran inside every router and link-state updates were flooded to all of them. Here the algorithm is one application outside the switches, and the switches speak only to the controller. To change how this network routes, you change one program. In a per-router control plane you would have to change software in every router, possibly from several vendors.

In plain words

Read the six steps as a single sentence: s1 tells the controller, the controller tells the application, the application thinks, and the controller tells the switches.

Every arrow crosses one of the two boundaries from section 5.5.1. Steps 1, 2 and 6 cross the southbound interface. Steps 3, 4 and 5 cross the northbound one. Nothing else happens, and no switch ever speaks to another switch.

The same link failure, under the two control planes

	Per-router controlOSPF, sections 5.2.1 and 5.3	Logically centralized controlSDN, section 5.5.3
Who is told about the failure
Where Dijkstra runs
Where the link-state database lives
Who writes the forwarding rules
To change how routing works, you change…

Cells marked ⓘ have a reason behind them — click to read it.

Section 5.2.1 and section 5.5.3 solve the same problem with the same algorithm. Everything else differs. Click any cell.

The last row of that table is the section’s real conclusion. Since the controller can tailor the flow tables as it pleases, it can implement any form of forwarding it pleases, simply by changing the application software. An SDN-enabled ISP (Internet Service Provider) could switch from least-cost path routing to a hand-tailored scheme that way. Under per-router control you would have to change software in every router, and those routers may come from several independent vendors.

A book inconsistency to know about

The book states twice which switches are affected, and the two lists disagree.

The paragraph introducing the example says that flow forwarding rules at s1, s3 and s4 are affected, “but that s2’s operation is unchanged”. Step 6 then says the flow table manager updates entries at s1, s2 and s4.

One list contains s3 and not s2; the other contains s2 and not s3.

The introduction is the one that fits the picture. After the s1–s2 link fails, s1 has exactly one remaining neighbour: s3. Any replacement path out of s1 must therefore start at s3, so s3 has to forward and its rules must change. Switch s2, by contrast, only starts receiving the same packets from a different neighbour. That changes no rule of its own.

Verified against the page images of book pages 418 and 419.

The link costs are never given

Figure 5.16 draws five links: s1–s2, s1–s3, s2–s3, s2–s4 and s3–s4. Only s1–s4 is missing.

If every link cost 1, then after the failure s1 would reach s2 by s1 → s3 → s2, two hops, and s4 would play no part at all. The book’s narrative instead routes s1 to s2 through s4, which needs the s3–s2 link to be expensive.

The book says “shortest path routing is implemented” and never states any costs, so both readings are available to the reader and only one matches the text. Follow the six steps, which are the point; do not try to recompute the paths.

Where SDN came from

Where SDN came from, and where it is going

1998 — controllers for ATM networksstep 1 of 5

A control framework for ATM networks with multiple controllers, each controlling a number of ATM switches. The separation of a control plane from the switches it controls is not a 2010s idea.

Every date and claim here is the book’s own, from section 5.5.4. The two research directions on the right are the ones it names.

Read all steps as text

1998 — controllers for ATM networks — A control framework for ATM networks with multiple controllers, each controlling a number of ATM switches. The separation of a control plane from the switches it controls is not a 2010s idea.
2004 — three papers argue for the split — Separating the data and control planes was argued for independently in three places in 2004, one of them an RFC. The idea had a research consensus behind it years before it had a product.
2007 — Ethane, and more than 300 switches running — Ethane pioneered a network of simple flow-based Ethernet switches with match-plus-action flow tables, a centralized controller that managed flow admission and routing, and forwarding of unmatched packets from the switch to the controller. That is the whole of section 5.5, three years early. More than 300 Ethane switches were operational in 2007.
And then it became OpenFlow — Ethane quickly evolved into the OpenFlow project. The book’s own sentence is "and the rest, as the saying goes, is history".
Where the research is going now — Two directions the book names. Network functions virtualization does to middleboxes what SDN did to routers: replace dedicated hardware and proprietary software with commodity servers, switching and storage. And a second effort seeks to extend SDN ideas from inside one autonomous system to routing between them — which is BGP’s territory.

Everyday picture

A shop where the till, the stock list and the pricing rules were once one machine bolted to the counter, sold by one company.

Now the till is a cheap terminal and the stock list is on a server in the back office. The pricing rules are a program that someone in head office can rewrite on a Tuesday.

Nothing the shop does changed. Who is allowed to change it did.

Where the picture stops. A shop can close for the afternoon while the system is swapped. A network cannot, which is why the controller has to be logically centralized and physically distributed at the same time.

Two controllers people actually run

In the earliest days of SDN there was a single protocol, OpenFlow, and a single controller, NOX (Network Operating System) . Since then the number of controllers has grown a great deal. Some are company-specific and proprietary, particularly for controlling internal networks such as those within or among a company’s data centres. Many more are open source.

Two have found considerable industry support: ODL (OpenDaylight) and ONOS (Open Network Operating System) . Both are open source, and both are developed in partnership with the Linux Foundation.

Figures 5.17 and 5.18 — two real controllers, on one skeleton

The bottom band: talking to devicesstep 1 of 4

OpenDaylight offers OpenFlow, NETCONF, SNMP and OVSDB as protocol plugins. ONOS offers abstractions for device, link, host, flow and packet, over OpenFlow, NETCONF and OVSDB. OVSDB manages data centre switching, an important application area for SDN — chapter 6 introduces data centre networking.

Both are open source and both are developed in partnership with the Linux Foundation. Drawn side by side because the book says each one resembles the canonical controller of Figure 5.15.

Read all steps as text

The bottom band: talking to devices — OpenDaylight offers OpenFlow, NETCONF, SNMP and OVSDB as protocol plugins. ONOS offers abstractions for device, link, host, flow and packet, over OpenFlow, NETCONF and OVSDB. OVSDB manages data centre switching, an important application area for SDN — chapter 6 introduces data centre networking.
The middle band: holding the state — OpenDaylight’s Basic Network Functions correspond closely to Figure 5.15’s state-management layer, and beneath them sits the Service Abstraction Layer — the controller’s nerve centre. ONOS keeps the state of links, hosts and devices in its distributed core, deployed as one identical copy of the software per server.
The top band: what applications see — OpenDaylight exposes REST, RESTCONF and NETCONF APIs to its orchestrations and applications. ONOS exposes a REST API and, uniquely, an intent framework: an application asks for a connection between host A and host B, or asks that A and B not be able to communicate, without knowing how it is done.
And the three bands are Figure 5.15 — That is the point of drawing them together. Two independently built platforms, from different communities, land on the same three layers: devices at the bottom, state in the middle, applications on top. The book says the architecture of Figure 5.15 also closely resembles the original NOX controller of 2008.

The southbound protocols these controllers speak

Protocol	What it is for	Covered in

Cells marked ⓘ have an explanation — click to read it.

One controller, several protocols. The Service Abstraction Layer exists partly so that the layers above do not have to know which one is in use.

In plain words

Two things in that diagram deserve names.

OpenDaylight’s Service Abstraction Layer is the piece everything else goes through. It lets controller components and applications call each other’s services, reach configuration and operational data, and subscribe to each other’s events. It also hides which southbound protocol is in use, so the layers above do not have to care.

ONOS’s intent framework is the northbound idea. An application says “connect host A to host B”, or “do not let host A and host B communicate”, and does not say how. Compare section 5.3, where an operator who wanted a particular routing had to search for the OSPF (Open Shortest Path First) link weights that would produce it.

Two ways to write an OpenDaylight application

Driven by an API (Application Programming Interface) , written AD-SAL. Applications talk to controller modules with a REST (Representational State Transfer) request-response interface running over HTTP (HyperText Transfer Protocol) . Early OpenDaylight releases offered only this, and it is what Figure 5.17 shows.

Model-driven, written MD-SAL. As OpenDaylight came to be used more for network configuration and management, later releases added this. The YANG (Yet Another Next Generation) data modelling language defines models of device, protocol and network configuration and operational state data. Devices are then configured and managed by manipulating that data with the NETCONF (Network Configuration Protocol) protocol.

Both of those arrive properly in section 5.7.3. The point here is that the second approach appeared because people started using the controller for something the first approach was not shaped for.

Check yourself

0 of 7 answered

1.Switch s1 detects that its link to s2 has failed. Who does it tell?
2.In step 3, the routing application receives a notification of the link-state change. Why does it get one?
3.predictAn SDN-enabled ISP decides to stop using least-cost path routing and use a hand-tailored scheme instead. What has to change?
4.What did the Ethane project demonstrate in 2007?
5.What is network functions virtualization aiming to do?
6.What is distinctive about ONOS's intent framework?
7.OpenDaylight and ONOS were built by different communities. What do their architectures have in common?

What to remember

Six steps, and only two boundaries. Steps 1, 2 and 6 cross the southbound interface; steps 3, 4 and 5 cross the northbound one. The switch reports and never decides.
Dijkstra is unchanged from section 5.2.1. Only its location changed — one application instead of one copy per router.
To change how the network routes, you change one program. Under per-router control you would change software in every router, possibly from several vendors.