The slides describe today's network node architecture in three lines, and every line is a lock-in mechanism: specialized packet forwarding and processing, a dedicated operating system with its own programming interfaces (CLI), and proprietary applications. Multiply that by the number of boxes in a network and you have the ossification of chapter 1, in concrete form: each device is its own island with its own OS and its own apps.
The proposed architecture of tomorrow is built up in the slides in three successive steps, and it is worth following that order because each step depends on the previous one:
The reference picture of an OpenFlow switch draws a horizontal line through the system and labels the two halves control plane and data plane. Above the line sits the controller; below it, the switch's own operating system and the (specialized) packet forwarding hardware. The two are joined by the OpenFlow protocol over SSL/TCP.
The division of labour is stated crisply in the P4 introduction deck:
| Control plane | Data plane |
|---|---|
|
|
OpenFlow is precisely the interface drawn between those two columns.
The OpenFlow abstraction has exactly two halves.
| Match | Actions (if a match is found) |
|---|---|
|
|
The advantages claimed for OpenFlow are three, and they are worth separating because they are often conflated: OpenFlow is a standardized protocol to interact with a switch (download flow table entries, query statistics); OpenFlow is a standardized model, namely the match/action abstraction; and OpenFlow assumes the concept of logically centralized control via a single entity, the SDN controller, which simplifies the control plane.
The slides are candid about what happened next. OpenFlow was simple: a single rule table with priority, pattern, actions, counters and timeouts, matching on any of 12 fields — MAC addresses, IP addresses, transport protocol, transport port numbers. Then came the proliferation of header fields:
| Version | Date | # Headers |
|---|---|---|
| OF 1.0 | Dec 2009 | 12 |
| OF 1.1 | Feb 2011 | 15 |
| OF 1.2 | Dec 2011 | 36 |
| OF 1.3 | Jun 2012 | 40 |
| OF 1.4 | Oct 2013 | 41 |
Along with the field count came multiple stages of heterogeneous tables, and the honest conclusion in the slides: still not enough — VXLAN, NVGRE, STT and the next encapsulation all arrive after the specification is frozen.
The growth from 12 to 41 fields in four years is the argument for P4 in a single table. Every new protocol requires a new specification, a new firmware and a new controller release. A protocol-independent language moves that cost from the standards body to the compiler — which is exactly the claim developed in chapter 5.
Before that argument, however, it pays to be fluent in the mechanics of a flow table: priority, wildcards, first-match semantics. The widget below is a flow-table walker built on the OpenFlow model described in the slides.
This is the most usefully deflationary section of the introductory deck. Deploying an SDN controller is easy — there are plenty of open source projects. So what does a controller do once deployed?
And then the slides insert a deliberate BUT:
In other words: an unprogrammed controller is a correctly-speaking, completely useless device. To make it do anything the controller must be programmed in its native language, which requires knowledge of low-level, infrastructure-related information and a step-by-step implementation of the required function following the physical topology — the slides put it bluntly: N switches = N actions.
The conclusion in the slides is a warning to anyone expecting SDN to be a simplification out of the box: the implementation of SDN is not straightforward, and it requires new expertise with respect to conventional network management, where the skills were configuring routing protocols, VLANs and so on. Programmability replaces one kind of difficulty with another; it does not remove difficulty.
The answer to "N switches = N actions" is a logical abstraction to simplify the implementation: the Network Operating System. The slides list four things a NOS provides:
| Component | Why it matters |
|---|---|
| SDN controller | The base: the entity speaking to the devices. |
| Network management applications | Topology discovery and similar services, so the application does not have to learn the topology itself. |
| Implementation tools | An intent framework: you state what you want, the platform computes the per-device actions. |
| Multi-protocol support | OpenFlow is not the only southbound protocol, and a NOS must not assume it is. |
Two examples are named: OpenDaylight and ONOS (Open Network Operating System), each with its own catalogue of services and subsystems. ONOS returns in chapter 8, where its architecture, its FlowRule and FlowObjective APIs and its pipeconf mechanism are studied against P4Runtime.
The step from "controller" to "network operating system" is the same step as from a device driver to an operating system. A controller lets you talk to the hardware; a NOS gives you a global topology view, services and an intent abstraction, so that applications can be written against the network rather than against the devices.
Now the building blocks of the previous two chapters get assembled. The slides say it directly: let us put together the building blocks — VNFs, cloud computing and the VNI, the SDN controller — and implement a service. Implementing a service means two operations:
That is the definition of a Service Function Chain: a set of VNFs to be traversed over a VNI for specific service purposes.
The reference picture places a user on a LAN, a cloud VNI controlled via SDN, and VNFs running in VMs on compute nodes, with the chain finally reaching the Internet. When the deployment is spread over three compute nodes, two design problems appear together and the slides name them as a pair: VNF placement and traffic steering. Placement decides which compute node hosts which VNF; steering decides the order in which flows visit them.
The slides then plot chains over an actual topology of edge network data centers connected by a core network, and identify two independent degrees of freedom:
| Diversity | What varies |
|---|---|
| Space chaining diversity | Two different flows at the same instant — f1(t0) and f2(t0) — traverse VNFs hosted in different edge data centers. The chain is a property of the flow, not of the topology. |
| Time chaining diversity | The same flow at two instants — f2(t0) and f2(t1) — traverses a different set of VNFs. The chain can be re-decided while the flow is alive. |
Be ready to explain that a service function chain is per-flow and re-negotiable. Space diversity means two simultaneous flows can have different chains; time diversity means one flow can have different chains at different times. Both are impossible with a hard-wired middlebox chain, and both are what the SDN-controlled VNI buys you.
The proof-of-concept in the slides is deliberately mundane, which is what makes it convincing. Two classes of customer reach a core network: a Business User (BU) with a service level agreement, and a Residential User (RU) without one. Three VNFs are available:
| VNF | Role |
|---|---|
| DPI | Deep packet inspection — used for classification, to find out what the traffic actually is. |
| WANA | WAN traffic accelerator — used to honour an SLA when the network is congested. |
| TC | Traffic conditioner — used to shape traffic that has no SLA to protect. |
The controller design then walks through five phases, each phase being a different set of rules installed in switch SW1. Step through them below; note that the same physical topology produces five different behaviours purely because the controller changed the rules.
Phase 3 is the interesting one: when there is no congestion the SLA is simply not enforced, and traffic is forwarded directly. An SLA is a promise about the outcome, not an obligation to keep an accelerator in the path. This is the kind of conditional behaviour that is trivial to express in a controller and impossible to express in a cable.
The slides state the difficulty plainly: implementing an SFC is more than implementing a forwarding path. You need to know at which stage the packet is in the chain in order to forward it properly. A packet that has already visited the firewall and a packet that has not are the same packet as far as the IP header is concerned, and yet they must be treated differently.
The answer is the Network Service Header (NSH), described as a flexible, dynamic, transport-independent SFC solution in the data plane. Its mechanism has three parts:
The NSH itself contains an NSH base header, the Service Path ID / Service ID pair, and optional metadata. Encapsulated, the resulting stack looks like this:
The example in the slides follows a single chain, SPI = 200, across three data centers: a classifier at the ingress puts the packet on the path; at one hop the header reads SPI = 200, SI = 5, later SPI = 200, SI = 3, later still SPI = 200, SI = 1, and past the last service function the encapsulation is removed — No NSH — and the packet continues as an ordinary packet towards its destination host.
The transport-independence claim now makes sense: because the chain state lives in the packet, an SFC can cross data centers and transport technologies without every intermediate device having to remember where each flow is in each chain.
Above the controller the slides place an orchestrator, and above that a network application that represents the service. The orchestrator drives two systems at once: the SDN controller (physical routers and switches, plus the Open vSwitches) and OpenStack (DHCP, virtual routers, VMs hosting the VNFs). The same picture is then re-used three times to make three points: orchestration, monitoring, and the ability to adapt to network conditions — a closed loop of decide, observe, re-decide.
The interface upwards, towards whoever is asking for a service. In the first version of the picture the NBI sits between the network application and the orchestrator; in the second, between the orchestrator and the layer below it. The traffic on this interface is intent: "I want this service", not "install this rule on switch 7".
The interface downwards, towards the things that actually forward and host. This is where OpenFlow, P4Runtime (chapter 8) and NETCONF (chapter 12) live. ONOS calls the same idea "shared protocol libraries".
The interface sideways, between peers at the same level — in the slides, between the SDN controller and OpenStack. Two subsystems that each own part of the infrastructure must agree with each other, and neither is above the other.
The introductory deck closes with a self-criticism of NFV, and it is a sharp one. The NFV concept is very much focused on replacing existing network functions with VNFs: guarantee management, exploit virtual machines with proper software. The consequence:
If all you do is re-implement the firewall you already had, you get cheaper firewalls, not new services.
Multi-Access Edge Computing (MEC) is the answer: execute resources — compute and storage — for network applications close to the end users, typically within or at the boundary of operator networks. The slides go further and note that edge applications could also be placed inside the user environment: in house routers or access points, inside the factory building — a remark that connects directly to the industrial chapters of this course.
The problem statement is explicit: provide application developers and content providers with cloud-computing capabilities and an IT service environment at the edge of the network, with
And the innovation is named in one line: applications can leverage information from the network. That is the difference between hosting an application near the user and hosting an application that knows it is near the user.
| MEC use cases | ETSI MEC APIs |
|---|---|
|
|
The slides motivate the API list with one condition: the MEC concept will be most useful if application instances can be managed with standardized interfaces — the same argument used for ETSI NFV-MANO in chapter 2.
Specialized packet forwarding and processing; a dedicated operating system with its own programming interfaces (CLI); proprietary applications. The OpenFlow innovation replaces this with a unified operating system, general purpose open applications and a new programming channel (OpenFlow) down to the still-specialized hardware.
Control plane: calculates the forwarding table and determines the output port based on the destination address. Data plane: manages individual incoming packets, matches the destination address (switch on destination MAC, router on longest IP prefix), looks up the output port, sends the packet to that port; the switching fabric directs packets from input to output. OpenFlow is the interface between them, carried over SSL/TCP.
Match: a subset of header fields (IP, MAC, MPLS) and ports, supported by most TCAM implementations. Actions: drop, rewrite header fields, forward on port X, count packets, flood.
Because it shows the model breaking under its own success: 12 fields in OF 1.0 (Dec 2009), 15 in 1.1, 36 in 1.2, 40 in 1.3, 41 in 1.4 (Oct 2013), plus multiple stages of heterogeneous tables — and still not enough for VXLAN, NVGRE, STT. Every new header requires updating the specification and the switch runtime, which is precisely the cost P4 is designed to remove.
It has established a logical relationship with the nodes and can receive and generate well formed OpenFlow packets — and that is all. It has no built-in logic to reply to node enquiries and installs no flows by default. It must be programmed in its native language, with low-level infrastructure knowledge, following the physical topology: N switches = N actions.
It is a logical abstraction that simplifies implementation. It bundles the SDN controller with network management applications (topology discovery), implementation tools such as an intent framework, and multi-protocol support. Two examples: OpenDaylight and ONOS.
A Service Function Chain is a set of VNFs to be traversed over a VNI for specific service purposes. Implementing a service means (1) configuring the VNFs and the VNI, and (2) using the VNI to make traffic flows traverse the suitable VNFs. The two associated design problems are VNF placement and traffic steering.
Space: two different flows at the same instant traverse VNFs in different edge data centers — the chain depends on the flow. Time: the same flow at two different instants traverses a different chain — the chain can be re-decided while the flow is alive.
(1) Classification: BU traffic towards the destination is forwarded both to VR1 and to the DPI, and likewise for inbound packets. (2) SLA compliance: BU traffic is forwarded to VR1 via WANA1. (3) No congestion, SLA not enforced: BU traffic goes directly to VR1. (4) Classification again: BU direct to VR1, while RU traffic is forwarded both to VR1 and to the DPI. (5) SLA compliance and congestion, SLA enforced: BU via WANA1 and RU via the traffic conditioner TC.
Because you must know at which stage of the chain the packet currently is in order to forward it correctly. Two packets identical at IP level may need different treatment depending on which service functions they have already visited, and a plain forwarding table cannot express that.
The NSH carries an NSH base header, the Service Path ID / Service ID pair, and optional metadata; it is inserted with packet encapsulation (VxLAN/Ethernet). The SPI identifies the service function chain; the SI identifies the node within the chain. Because chain state travels in the packet, the solution is transport independent.
North Bound Interface towards the requester of the service, South Bound Interface towards the infrastructure, and East/West Bound Interface between peers, for example between the SDN controller and OpenStack. The slides deliberately draw the same architecture twice with the NBI at two different levels: north and south are positions relative to the layer you are standing on, not fixed product categories.
NFV is focused on replacing existing network functions with VNFs, so it leaves little room for a very innovative application environment and little room for user-enabled functions. MEC places compute and storage close to the end user — within or at the boundary of the operator network, or even in in-house routers, access points or the factory building — offering ultra-low latency, high bandwidth and real-time access to radio network information, so that applications can leverage information from the network.