NET-201 Week 9 -- SDN: OpenFlow, P4, and Intent-Based Networking

"The goal of SDN is not to replace the routing protocol. The goal is to decouple the decision from the forwarding -- to move the 'where does this packet go?' question out of the switch ASIC and into software that can be updated, reasoned about, and composed." -- Nick Feamster, Jennifer Rexford, & Ellen Zegura, The Road to SDN (Queue, 2013)

Lecture (100 min, two 50-min blocks)

9.1 The Problem with Traditional Networking

Every router and switch in a traditional network runs its own control plane -- its own instance of OSPF, BGP, or STP. The forwarding decisions are distributed: no single node has a complete picture of the network. Policy changes require touching every device.

This model has three pain points:

1. Configuration complexity: making a consistent policy change across 500 switches requires 500 CLI sessions. Human operators produce inconsistent configs. This is the #1 source of enterprise network outages.

2. Closed vendor ecosystem: switching ASICs implement proprietary forwarding pipelines. Adding a new protocol feature (say, segment routing) requires a vendor firmware update, which requires purchasing support contracts.

3. Limited visibility: each device knows its immediate neighbors' state, but no device has a real-time view of end-to-end flow statistics. Traffic engineering (routing specific flows to specific paths) is hard.

SDN (Software-Defined Networking) addresses all three by separating the control plane (decision logic) from the data plane (packet forwarding).

9.2 OpenFlow: The First SDN Standard

OpenFlow (ONF TR-2009 + IEEE 802.1AB-2014) was the first widely adopted SDN protocol. It defines a communication channel between an SDN controller and an OpenFlow-capable switch.

Architecture:

┌─────────────────────────────────────┐
│           SDN Controller            │
│  (NOX, POX, Ryu, OpenDaylight,     │
│   ONOS, Faucet, ...)                │
│                                     │
│  Network-wide view; flow decisions  │
└──────────────┬──────────────────────┘
               │ OpenFlow channel (TLS, port 6633/6653)
               │ (out-of-band or in-band management)
┌──────────────┴──────────────────────┐
│         OpenFlow Switch             │
│  Flow Table: [Match | Action]       │
│  match: src_IP, dst_IP, TCP_port,  │
│          VLAN, in_port ...          │
│  action: output(port), drop, flood, │
│           modify_field, controller  │
└─────────────────────────────────────┘

Flow table operation:

• Each entry: match fields + priority + actions + counters
• A packet arriving at the switch is matched against the flow table in priority order
• First match wins; if no match: "table-miss" entry (usually: send to controller or drop)
• Controller-directed: controller can install flow entries proactively or reactively (on first packet of new flow)

Reactive vs. proactive mode:

• Reactive: first packet of each new flow is sent to the controller (PACKET_IN); controller decides and installs a flow entry. Provides maximum visibility but introduces per-flow setup latency.
• Proactive: controller pre-installs flow entries based on static policy (ACLs, VLAN routing rules). Packets hit the flow table without controller involvement. High performance; less flexible.

Simple Ryu controller example (Python):

from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import MAIN_DISPATCHER, set_ev_cls
from ryu.ofproto import ofproto_v1_3

class SimpleSwitch(app_manager.RyuApp):
    OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        # Install: match any, action = output all ports (flood)
        match = parser.OFPMatch()
        actions = [parser.OFPActionOutput(ofproto.OFPP_FLOOD)]
        inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS, actions)]
        mod = parser.OFPFlowMod(datapath=datapath, match=match,
                                instructions=inst)
        datapath.send_msg(mod)

9.3 Mininet: SDN Lab Platform

Mininet emulates a network topology in software using Linux network namespaces and virtual interfaces. It runs entirely in a single Linux kernel -- no VMs, no containers. This allows complex SDN topologies to run on modest hardware.

# Start Mininet with a simple topology (2 hosts, 1 switch)
sudo mn --topo single,3 --controller remote,ip=127.0.0.1

# In Mininet CLI
mininet> pingall          # test connectivity between all hosts
mininet> h1 ping -c3 h2  # ping from h1 to h2
mininet> sh ovs-ofctl dump-flows s1  # dump flow table on switch s1
mininet> h1 iperf -s &; h2 iperf -c h1  # bandwidth test

# Exit
mininet> exit

Mininet uses Open vSwitch (OVS) as its virtual OpenFlow switch. OVS implements OpenFlow 1.3 and supports the full controller interface.

# Inspect OVS flow table
sudo ovs-ofctl dump-flows br0

# Add a flow rule manually (drop all traffic from 10.0.0.1)
sudo ovs-ofctl add-flow br0 "ip,nw_src=10.0.0.1,priority=200,actions=drop"

# View port statistics
sudo ovs-ofctl dump-ports br0

9.4 P4: Programming the Data Plane

OpenFlow's limitation: the match fields are fixed (defined by the protocol spec). Adding new header fields to match requires a new version of OpenFlow and vendor ASIC updates.

P4 (Programming Protocol-Independent Packet Processors, RFC 2015+) takes a different approach: the programmer defines the parsing and match-action pipeline entirely in the P4 language. The pipeline is compiled to a specific target (a software switch, a SmartNIC, an ASIC).

// P4 program excerpt: define a custom header and match
header my_protocol_t {
    bit<8>  type;
    bit<16> length;
}

control MyIngress(inout headers h, ...) {
    action forward_to_port(bit<9> port) {
        standard_metadata.egress_spec = port;
    }
    table routing_table {
        key = { h.ipv4.dstAddr : lpm; }
        actions = { forward_to_port; drop; }
        default_action = drop();
    }
    apply {
        routing_table.apply();
    }
}

P4 is relevant because Tofino-based switches (Intel/Barefoot), SmartNICs (Netronome, Nvidia BlueField), and XDP programs in the Linux kernel are all P4-influenced or P4-compiled targets. Understanding P4 is increasingly necessary for network programmability at line rate.

9.5 Intent-Based Networking (IBN)

Intent-Based Networking takes SDN's control-plane centralization further: the operator expresses high-level intent ("servers in VLAN 10 can reach the internet; they cannot reach VLAN 20"), and the system translates intent into device-specific configurations automatically.

Commercial implementations: Cisco DNA Center (intent-to-configuration translator), Apstra (Juniper acquisition), and Akamai's Guardicore (microsegmentation with intent policies).

Key components:

• Intent specification: high-level policy (often REST API or DSL)
• Translation engine: converts intent to per-device configuration
• Verification: closed-loop checking that network state matches intent; alerts on drift

The academic precursor is Network Verification: formal methods applied to network configurations to prove (or find counterexamples to) reachability and security properties. Projects: Batfish (network configuration analysis), Minesweeper, and Plankton.

9.6 SDN vs. Traditional vs. IBN: Architecture Comparison

This table will appear as a structured Architecture Comparison Sidebar in the student-facing chapter notes. See handouts/cross-chapter-control-plane-architectures.md for the full D10 sidebar.

Lab Preview

Lab 7 and Lab 9 address SDN from two angles:

Lab 7 (OpenFlow Mininet):

• Deploy a 4-host, 2-switch Mininet topology
• Start a Ryu reactive learning switch controller
• Observe per-flow PACKET_IN events in the controller output
• Add a manual flow rule to block traffic between h1 and h2
• Measure how long flow setup latency adds to first-packet RTT (reactive mode)

Lab 9 (SDN vs. OSPF convergence comparison):

• Run the same 4-node topology on Containerlab with FRR OSPF
• Run it under OVS + Ryu SDN control
• Kill one link; measure convergence time in each case
• Document: what is the trade-off between OSPF's distributed reconvergence and SDN's centralized state?

Homework

Reading (45 min): Kurose-Ross 9e Ch 5.5 (The SDN Control Plane). Focus on the data-plane/control-plane separation concept, the flow table model, and the SDN controller architecture. Review handouts/cross-chapter-control-plane-architectures.md for the full architecture comparison sidebar.

Hands-on (60 min): Install Ryu and run the simple learning switch example against a Mininet topology:

pip install ryu
# Run Ryu with built-in learning switch app
ryu-manager ryu.app.simple_switch_13 &

# In separate terminal: start Mininet with remote controller
sudo mn --topo linear,4 --controller remote,ip=127.0.0.1 --switch ovsk,protocols=OpenFlow13

# Test connectivity
mininet> pingall

# Observe flow table after ping
mininet> sh ovs-ofctl -O OpenFlow13 dump-flows s1

Document: how many flow entries did the learning switch install? What match fields does it use? What would happen if you added a 5th host?

Toolchain Diary Entry

First-introduce this week: Mininet; Open vSwitch (ovs-ofctl); Ryu SDN controller

sudo mn --topo single,3 --controller remote: launch Mininet with 3 hosts connected to 1 switch; controller running at localhost.

mininet> pingall: test all-pairs connectivity in the Mininet topology.

sudo ovs-ofctl dump-flows BRIDGE: dump the OpenFlow flow table on an OVS bridge.

sudo ovs-ofctl add-flow BRIDGE "match_spec,actions=ACTION": install a flow entry manually.

sudo ovs-vsctl show: display OVS configuration (bridges, ports, controller).

ryu-manager APP: start the Ryu controller with a specified application.

sudo mn -c: clean up all Mininet state (network namespaces, OVS bridges); run after experiments.

Key Terms

• SDN: Software-Defined Networking; separates the control plane (forwarding decisions) from the data plane (packet forwarding); centralizes control in a software controller
• OpenFlow: SDN protocol standard; defines the communication between a controller and OpenFlow-capable switches; match-action flow tables; reactive or proactive flow installation
• Flow table: a table in an OpenFlow switch; entries specify (match_fields, priority, actions); first-match forwarding; controller manages entries via OpenFlow messages
• Ryu: open-source Python-based OpenFlow controller framework; used in academia and production SDN deployments
• Mininet: network emulator using Linux network namespaces; runs realistic topologies on a single host; pairs with Open vSwitch for OpenFlow experiments
• Open vSwitch (OVS): software OpenFlow-compatible virtual switch; used in Mininet, KVM/QEMU hypervisors, OpenStack; supports OpenFlow 1.3
• P4: domain-specific language for programming packet-processing pipelines; defines parsing, match-action tables, and header modifications; target-independent; compiled to specific ASICs, SmartNICs, or software switches
• Intent-Based Networking (IBN): high-level policy expression (intent) that is automatically translated to device configurations; closed-loop verification of network state against declared intent; commercial: Cisco DNA Center, Apstra