131  OpenFlow Protocol and Flow Tables

In 60 Seconds

OpenFlow flow tables use match-action rules with priorities to process packets: each entry matches on up to 15 header fields (MAC, IP, port, VLAN) and executes actions like forward, drop, or modify. Flow entries include idle and hard timeouts – idle timeout of 30s is typical for IoT sensor traffic patterns.

131.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain OpenFlow Protocol Operation: Describe how OpenFlow enables controller-switch communication and flow rule installation via PACKET_IN, FLOW_MOD, and STATS messages
  • Design Flow Table Entries: Create match-action rules with appropriate priorities, timeouts, and counters for IoT traffic classes
  • Implement Network Policies: Program OpenFlow switches with prioritized flow rules to enforce QoS, security, and forwarding behavior
  • Evaluate SDN Security Risks: Assess and mitigate scalability, security, and reliability issues in SDN-based IoT deployments
MVU: Minimum Viable Understanding

Core concept: OpenFlow is the standardized protocol enabling SDN controllers to program switches with flow rules - each rule specifies what packet headers to match and what action to take (forward, drop, modify). Why it matters: Flow tables enable wire-speed packet forwarding (nanoseconds) because switches make forwarding decisions locally using pre-installed rules, rather than asking the controller for every packet. Key takeaway: Design flow rules with appropriate timeouts - idle timeouts for dynamic traffic (rules expire when unused) and hard timeouts for security-sensitive flows (force periodic re-authorization from controller).

Software-Defined Networking (SDN) separates the brain of a network (the control plane) from the muscles (the data plane). Think of a traffic management center: instead of each traffic light making its own decisions, a central system monitors all intersections and coordinates them for optimal flow. SDN brings this same centralized intelligence to IoT networks.

131.2 Prerequisites

Key Concepts
  • SDN (Software-Defined Networking): An architectural approach separating the network control plane (routing decisions) from the data plane (packet forwarding), centralizing control in a software controller for programmable network management
  • Control Plane: The network intelligence layer making routing and forwarding decisions, centralized in an SDN controller rather than distributed across individual switches as in traditional networking
  • Data Plane: The network forwarding layer physically moving packets based on rules installed by the control plane — in SDN, this is the switch hardware executing OpenFlow flow table entries
  • OpenFlow: The foundational SDN protocol enabling communication between an SDN controller and network switches, allowing the controller to install, modify, and delete flow table entries that govern packet forwarding
  • OFPT_PACKET_IN: An OpenFlow message sent from switch to controller when a received packet does not match any flow table entry (table miss), triggering controller flow installation for the new flow
  • OFPT_FLOW_MOD: An OpenFlow message from controller to switch adding, modifying, or deleting a flow table entry — the primary mechanism for controller-directed packet forwarding policy
  • OFPT_PACKET_OUT: An OpenFlow message from controller to switch instructing it to transmit a packet on a specified port — used to inject packets into the data plane for topology discovery or initial flow handling
  • TLS for OpenFlow: Transport Layer Security encryption for the OpenFlow control channel between controller and switches, preventing eavesdropping and manipulation of flow installation commands on the management network

131.3 How It Works: OpenFlow Message Flow for Reactive Rule Installation

Step 1: New Flow Arrives at Switch

  • IoT sensor sends first packet (src=10.0.0.5, dst=192.168.1.10, port=1883)
  • Switch searches all flow tables in priority order (highest first)
  • No matching rule found → table miss

Step 2: PACKET_IN Message to Controller

  • Switch buffers the packet (stores in local memory)
  • Sends PACKET_IN message to controller with:
    • Buffered packet headers (src/dst MAC, IP, protocol, ports)
    • Ingress port number
    • Reason code (TABLE_MISS)
    • Buffer ID for later retrieval

Step 3: Controller Processes Request

  • Controller application analyzes packet headers
  • Checks network policies (QoS requirements, security ACLs, routing rules)
  • Decides on action: FORWARD (port 3), DROP, MODIFY, or SEND_TO_CONTROLLER
  • Typical processing time: 5-50ms (slow path)

Step 4: FLOW_MOD Message to Switch

  • Controller sends FLOW_MOD message to install rule:
    • Match: src=10.0.0.5, dst=192.168.1.10, protocol=TCP, dst_port=1883
    • Priority: 100 (sensor traffic)
    • Actions: output port 3
    • Idle timeout: 30s (remove if unused)
    • Hard timeout: 300s (force re-authorization)
  • Switch installs rule in flow table, acknowledges success

Step 5: Switch Forwards Buffered Packet

  • Switch retrieves original packet from buffer using buffer ID
  • Applies newly installed rule (output port 3)
  • All subsequent packets matching this rule bypass controller (fast path, nanosecond forwarding)

Key Insight: This reactive pattern means the first packet of every new flow pays a latency penalty (controller round-trip), but all following packets forward at wire-speed using the installed rule. For IoT sensors sending periodic telemetry, this means only 1 in 1000 packets needs controller involvement.

131.4 OpenFlow Protocol Overview

⏱️ ~15 min | ⭐⭐⭐ Advanced | 📋 P04.C28.U04

OpenFlow protocol architecture showing control plane with SDN controller and data plane with switches, connected via OpenFlow messages including HELLO for handshake, FLOW_MOD for rule installation, PACKET_IN for unknown flows, and STATS for monitoring

OpenFlow Protocol Architecture
Figure 131.1: OpenFlow protocol architecture showing control plane and data plane separation

OpenFlow is the standardized southbound protocol for communication between controller and switches.

131.5 OpenFlow Switch Components

OpenFlow switch components diagram showing SDN controller connecting via OpenFlow protocol to secure channel (TLS/SSL), which manages flow tables (match + actions), group table (multi-output), meter table (rate limiting), packet buffer (temporary storage), and physical ports (network interfaces) with bidirectional packet flow
Figure 131.2: OpenFlow Switch Components: Flow Tables, Meters, and Port Management
Understanding Flow Tables

Core Concept: A flow table is a list of match-action rules stored in switch memory that determines how packets are forwarded without consulting the controller. Why It Matters: Flow tables enable wire-speed packet forwarding (nanoseconds) because switches make forwarding decisions locally using pre-installed rules, rather than asking the controller for every packet (which would add 10-50ms latency). Key Takeaway: Design flow rules with appropriate timeouts - idle timeouts for dynamic traffic (rules expire when unused) and hard timeouts for security-sensitive flows (force periodic re-authorization from controller).

131.6 Flow Table Entry Structure

Each flow entry contains:

1. Match Fields (Packet Header Fields): - Layer 2: Source/Dest MAC, VLAN ID, Ethertype - Layer 3: Source/Dest IP, Protocol, ToS - Layer 4: Source/Dest Port (TCP/UDP) - Input Port - Metadata

2. Priority:

  • Higher priority rules matched first
  • Allows specific rules to override general rules

3. Counters:

  • Packets matched
  • Bytes matched
  • Duration

4. Instructions/Actions:

  • Forward to port(s)
  • Drop
  • Modify header fields (MAC, IP, VLAN)
  • Push/Pop VLAN/MPLS tags
  • Send to controller
  • Go to next table

5. Timeouts:

  • Idle Timeout: Remove rule if no matching packets for N seconds
  • Hard Timeout: Remove rule after N seconds regardless of activity

6. Cookie:

  • Opaque identifier set by controller

Example Flow Rule:

Match: src_ip=10.0.0.5, dst_ip=192.168.1.10, protocol=TCP, dst_port=80
Priority: 100
Actions: output:port3, set_vlan=100
Idle_timeout: 60
Hard_timeout: 300

An OpenFlow 1.3+ flow entry with 12 match fields requires storage space. Calculate per-entry memory footprint:

\[\text{Match Fields} = 6 \text{ (src\_mac)} + 6 \text{ (dst\_mac)} + 4 \text{ (src\_ip)} + 4 \text{ (dst\_ip)} + 2 \text{ (src\_port)} + 2 \text{ (dst\_port)} + 1 \text{ (protocol)} + 2 \text{ (vlan)} + 2 \text{ (ethertype)} + 2 \text{ (input\_port)} + 2 \text{ (priority)} + 8 \text{ (cookie)} = 41 \text{ bytes}\]

\[\text{Actions} \approx 16 \text{ bytes}\] \[\text{Counters} = 8 + 8 + 8 = 24 \text{ bytes (packets, bytes, duration)}\] \[\text{Total per flow} = 41 + 16 + 24 + 8 \text{ (metadata)} = 89 \text{ bytes}\]

A switch with 4,000 TCAM entries: \(4000 \times 89 = 356\) KB of TCAM. At $1 per TCAM entry vs $0.01 per DRAM byte, TCAM costs ~$4,000 vs $3.56 for DRAM – 1,123× more expensive, explaining why flow table capacity limits OpenFlow switch cost.

131.6.1 Flow Table Memory Cost Calculator

Explore the cost tradeoff between TCAM and DRAM for storing flow entries:

131.7 Knowledge Check

Test your understanding of OpenFlow concepts.

131.8 Common Misconceptions About SDN

Common Misconceptions About SDN

Misconception 1: “SDN makes all switches dumb - they just forward blindly”

Reality: OpenFlow switches are intelligent forwarding devices with sophisticated match-action tables, group tables for multicast, meter tables for QoS, and local packet buffers. They make fast forwarding decisions in hardware using TCAM (Ternary Content Addressable Memory). The controller programs the “what” (flow rules), but switches optimize the “how” (wire-speed forwarding).

Misconception 2: “The SDN controller handles every packet”

Reality: Only first packets of new flows (table misses) go to the controller via PACKET_IN messages. The controller installs flow rules, then switches handle all subsequent packets of that flow in hardware at line rate (Gbps/Tbps speeds). Controllers see configuration traffic, not data plane traffic. A well-designed SDN uses proactive rules (pre-installed) to minimize controller involvement.

Misconception 3: “SDN is only for data centers and enterprises, not for IoT”

Reality: SDN is highly valuable for IoT networks: - Wireless Sensor Networks: Centralized routing optimization for energy efficiency - Smart Cities: Dynamic traffic prioritization (emergency vehicles, traffic lights) - Industrial IoT: QoS guarantees for time-critical machine control - LPWAN: Gateway coordination and spectrum management - Edge Computing: Dynamic workload placement and traffic steering

SDN architecture for IoT showing centralized controller managing heterogeneous IoT devices including sensors gateways and edge nodes with application-specific traffic policies for different QoS requirements

SDN for IoT Architecture
Figure 131.3: SDN architecture enabling centralized management of heterogeneous IoT deployments

SDN for mobile networking showing controller managing handoff between base stations optimizing traffic paths and enabling dynamic spectrum allocation for mobile IoT devices

SDN for Mobile Networking
Figure 131.4: SDN enabling intelligent mobile network management with dynamic handoff and spectrum optimization

Misconception 4: “OpenFlow is the only SDN southbound protocol”

Reality: While OpenFlow is the most common standardized protocol, SDN supports multiple southbound APIs: - NETCONF/YANG: Configuration management for network devices - P4: Programmable data plane (define custom packet processing) - gRPC/gNMI: Google’s network management interfaces - OVSDB: Open vSwitch database management - BGP/PCEP: Integration with existing routing protocols

Misconception 5: “SDN eliminates all network security concerns”

Reality: SDN introduces new attack vectors: - Controller compromise: Attacker gains network-wide control - Controller-switch channel: Must use TLS to prevent MITM attacks - Northbound API: Need authentication/authorization for applications - Flow rule manipulation: Malicious apps could install harmful rules - DDoS on controller: Flood with PACKET_IN messages (table-miss attacks)

Best practices: Strong authentication, network segmentation, RBAC, controller clustering, and flow rule validation.

131.9 Cross-Hub Connections

Cross-Hub Connections

Interactive Simulations:

  • Simulations Hub - Network topology visualizer shows SDN control flow
  • Try designing an SDN topology for a smart building with mixed device types

Knowledge Checks:

  • Quizzes Hub - OpenFlow protocol exercises
  • Test your understanding of flow table matching and priority rules

Video Tutorials:

  • Videos Hub - SDN controller programming tutorials
  • Watch practical demonstrations of OpenDaylight and Ryu controllers

Common Gaps:

  • Knowledge Gaps Hub - “Why centralized control doesn’t mean single point of failure”
  • Understanding controller clustering and high availability architectures

131.11 Worked Example: Designing Flow Rules for an IoT Smart Building

Scenario: A smart building has 200 temperature sensors (MQTT), 50 security cameras (RTSP video), and 20 actuator controllers (CoAP). An SDN controller manages a 10-switch network. Design flow rules that prioritize security camera traffic over sensor data.

Step 1: Define traffic classes and priorities

Traffic Class Protocol Priority Bandwidth Timeout
Emergency alerts MQTT QoS 2 (port 8883) 300 1 Mbps reserved Hard: 3600s
Security cameras RTSP (port 554) 200 5 Mbps per camera Idle: 300s
Actuator commands CoAP (port 5684) 150 100 Kbps Idle: 60s
Sensor telemetry MQTT QoS 0 (port 1883) 50 Best effort Idle: 30s
Default (unknown) Any 1 Best effort Hard: 60s

Step 2: Write OpenFlow flow rules

# Rule 1: Emergency alerts -- highest priority, guaranteed path
Match:  dst_port=8883, ip_proto=TCP
Priority: 300
Actions: output:port2, set_queue:0 (priority queue)
Meters:  rate=1000kbps (guaranteed minimum)
Hard_timeout: 3600

# Rule 2: Security cameras -- high priority, reserved bandwidth
Match:  dst_port=554, ip_proto=TCP
Priority: 200
Actions: output:port3, set_queue:1
Meters:  rate=50000kbps (50 Mbps aggregate for 50 cameras)
Idle_timeout: 300

# Rule 3: Actuator commands -- medium priority
Match:  dst_port=5684, ip_proto=UDP
Priority: 150
Actions: output:port4
Idle_timeout: 60

# Rule 4: Sensor telemetry -- low priority, best effort
Match:  dst_port=1883, ip_proto=TCP
Priority: 50
Actions: output:port5
Idle_timeout: 30

# Rule 5: Table-miss -- send to controller for classification
Match:  * (wildcard)
Priority: 1
Actions: output:CONTROLLER
Hard_timeout: 60

Step 3: Calculate flow table capacity

Flow table entries needed:
  - Emergency: 1 rule (port-based, all alerts use same path)
  - Cameras: 50 rules (1 per camera IP for individual routing)
  - Actuators: 20 rules (1 per actuator for individual control)
  - Sensors: 1 rule (aggregate, all sensors same priority)
  - Default: 1 rule (table-miss)
  Total: 73 entries

Typical TCAM capacity: 2,000-8,000 entries per switch
Utilization: 73 / 2,000 = 3.7% (plenty of headroom)

Step 4: Timeout design rationale

  • Sensors (idle: 30s): IoT sensors publish every 5-60 seconds. A 30-second idle timeout removes stale flows quickly, freeing TCAM entries. If a sensor goes silent for 30s, the next packet triggers a new PACKET_IN to the controller, which re-installs the flow.
  • Cameras (idle: 300s): Video streams are continuous but may pause briefly during scene changes or bandwidth adaptation. A 5-minute idle timeout prevents unnecessary flow churn.
  • Emergency (hard: 3600s): Hard timeout forces periodic re-authorization from the controller, even for active flows. This ensures compromised emergency paths are detected within 1 hour.

Key insight: The 4:1 priority ratio between cameras (200) and sensors (50) means that during congestion, the switch drops sensor packets before camera packets. In a building fire scenario, this ensures security footage continues streaming even when hundreds of temperature sensors flood the network with alarm readings.

131.12 OpenFlow Version Evolution: Choosing the Right Version for IoT

OpenFlow has evolved significantly since its initial release. Selecting the right version affects switch compatibility, feature availability, and controller complexity.

Feature OF 1.0 (2009) OF 1.3 (2012) OF 1.5 (2014)
Flow tables 1 (single pipeline) Multiple (sequential pipeline) Multiple + egress tables
Match fields 12 (L2-L4 headers) 40+ (IPv6, MPLS, VLAN stacking) 45+ (TCP flags, PBB)
Meter tables No Yes (per-flow rate limiting) Yes (enhanced)
Group tables No Yes (multicast, ECMP, failover) Yes (enhanced)
TLS requirement Optional Mandatory Mandatory
Bundle messages No No Yes (atomic multi-rule updates)
Table-miss handling Implicit send to controller Explicit table-miss entry required Explicit
Switch support Nearly universal Industry standard Limited

Why OF 1.3 Dominates IoT Deployments: Most production SDN-IoT networks use OpenFlow 1.3 because it provides the critical features – meter tables for QoS, group tables for multicast sensor data, and multiple flow tables for modular pipeline design – while maintaining broad switch support. OF 1.0 lacks meters and groups, making it unsuitable for IoT QoS. OF 1.5 adds useful features (bundle messages for atomic updates) but has limited switch vendor support as of 2025.

Worked Example: Multi-Table Pipeline for Smart Factory

Scenario: A factory floor has 300 sensors (vibration, temperature, pressure), 20 IP cameras, and 15 actuators. The SDN switch must handle classification, QoS enforcement, and security filtering.

Single-Table Design (OF 1.0):

  • All rules in one table: 300 sensor rules + 20 camera rules + 15 actuator rules + 50 ACL rules + 10 QoS rules = 395 entries
  • Problem: Adding a new security ACL requires checking for conflicts with all 395 existing rules
  • Rule interactions grow as O(N2): 3952 = 156,025 potential conflicts to verify

Multi-Table Pipeline Design (OF 1.3):

Table Purpose Entries Match Fields
0 Classification 5 EtherType (sensor/camera/actuator/management/unknown)
1 Security ACL 50 src_IP, dst_IP, protocol
2 QoS marking 10 DSCP values by traffic class
3 Forwarding 335 dst_IP → output port
  • Total entries: 400 (similar to single-table)
  • But each table is independent: adding a security ACL only affects Table 1 (50 entries)
  • Rule interactions within each table: max 502 = 2,500 (62x fewer than single-table)
  • Debugging: trace packet through 4 sequential tables vs searching 395 rules

Performance Impact: Multi-table pipelines also enable hardware optimization. The classification table (5 entries) can use exact-match SRAM (nanosecond lookup), while the forwarding table uses TCAM. This reduces TCAM pressure and improves overall throughput by 15-25% compared to putting all rules in TCAM.

Your Mission: You manage an IoT greenhouse with 50 soil moisture sensors (MQTT port 1883), 10 temperature sensors (CoAP port 5683), and 5 irrigation controllers (HTTP port 80). All devices connect through a single OpenFlow switch to a gateway at port 10. Design flow rules that:

  1. Give irrigation commands the highest priority (they control water valves - time-critical)
  2. Sensor telemetry uses lower priority (best-effort)
  3. Automatically remove stale rules for offline sensors

Step 1: Define Traffic Classes

  • Create a table with columns: Device Type, Protocol, Port, Priority, Timeout Strategy
  • Assign priority values (higher number = checked first)

Step 2: Write Flow Rules

  • For each device class, write a flow rule in this format:

    Match: [fields to match]
Priority: [number]
Actions: [what to do]
Timeouts: idle=[X]s, hard=[Y]s

Step 3: Handle New Devices

  • What happens when a new sensor comes online (not in flow table)?
  • Design a default table-miss rule that sends unknown packets to controller

What to Observe:

  • Which rules get checked first (highest priority)?
  • What timeout values make sense for sensors that publish every 60 seconds?
  • How many flow table entries are needed (count carefully)?
  • What happens if 2 rules match the same packet (priority conflict)?

Challenge Extension:

  • A bug causes temperature sensors to send 100 packets/second instead of 1/minute
  • Without changing the controller, can you design flow rules that rate-limit sensors to protect the network?
  • Hint: Use meter tables with rate limits (if OpenFlow 1.3+)

Expected Outcome: You’ll understand how to map real-world IoT requirements (time-critical vs best-effort, predictable vs bursty traffic) to OpenFlow flow rule parameters (priority, timeouts, meters). The key insight: flow rules are more than forwarding - they encode network policies.

131.13 Concept Relationships

This Concept Relates To Relationship Type Why It Matters
Match Fields Priority Conflict Resolution When multiple rules match the same packet, priority determines which rule executes - enables specific rules to override general rules
Idle Timeout TCAM Memory Resource Management Idle timeout automatically removes unused flows freeing expensive TCAM memory - critical for switches with 2000-8000 entry limits
Group Tables Multicast Efficiency/Scalability Group table enables single flow rule to replicate packet to N ports - without groups: need N flow rules or controller packet-out
Meter Tables QoS Rate Limiting Traffic Policing Meter tables enforce per-flow rate limits in switch hardware - prevents one misbehaving device from saturating network
FLOW_MOD Message PACKET_IN Message Request-Response PACKET_IN asks controller “what to do with this packet?”, FLOW_MOD answers “install this rule for all matching packets”

131.14 See Also

Next Steps - Deep Dives:

Related Concepts:

Place these steps in the correct order for how a new flow is handled reactively in an OpenFlow network.

Common Pitfalls

Running OpenFlow over unencrypted TCP (default port 6633/6653). An attacker on the management network can capture controller-switch communication, inject flow modifications, or replay commands. Always enable TLS for the OpenFlow control channel in production.

Not installing table-miss flow entries (match: any, priority: 0) in flow tables. Without table miss entries, switches apply the default behavior (drop or send-to-controller depending on OpenFlow version) for unmatched packets — causing silent traffic drops until the controller installs matching rules. Always define explicit table-miss actions.

Not configuring fail-safe behavior for when switch-controller connectivity is lost. By default, many switches drop all new flows (fail-closed) when the controller disconnects. Configure fail-open behavior using secondary standalone switch tables for known traffic patterns.

Misunderstanding the relationship between OpenFlow messages (controller-to-switch control channel) and the actual network traffic frames (IoT data flowing through the switch data plane). OpenFlow messages travel on a dedicated management channel separate from user data traffic.

131.15 Summary

This chapter explored the OpenFlow protocol and flow tables:

  • OpenFlow Protocol: Standardized southbound protocol enabling controllers to install flow rules in switches via messages like PACKET_IN, FLOW_MOD, and STATS
  • Flow Table Structure: Match fields (L2-L4 headers), priority, counters, actions (forward/drop/modify), timeouts (idle/hard), and cookies for controller identification
  • Switch Components: Flow tables, group tables (multicast/load balancing), meter tables (rate limiting), packet buffers, and secure TLS channel to controller
  • SDN Security: Controller compromise affects entire network - requires strong authentication, network segmentation, RBAC, and clustering
  • Common Misconceptions: Switches are intelligent forwarding devices, controllers only handle first packets, SDN applies well to IoT networks

OpenFlow flow tables are like a library’s sorting system – every book (packet) gets checked against the catalog and sent to the right shelf!

131.15.1 The Sensor Squad Adventure: The Flow Table Library

The Sensor Squad’s network switches were like librarians sorting millions of messages every second. Each switch had a special catalog called a “flow table” that told it exactly what to do with each message.

“Let me show you how it works!” said Max the Microcontroller. “When a message arrives, the switch checks its catalog.”

The catalog had entries like: - Entry 1 (Priority 200): “If the message is from Sammy the Sensor and going to the Gateway, send it out Port 5. Also count how many times this happens!” - Entry 2 (Priority 100): “If the message is going to ANY sensor, send it out Port 3.” - Entry 3 (Priority 50): “If nothing else matches, send the message to Connie the Controller and ask what to do!”

“The switch checks the HIGHEST priority first,” explained Lila the LED. “So security rules (Block the hacker!) always win over regular routing rules.”

Each entry also had a timer. “Rules don’t last forever,” said Bella the Battery. “An idle timeout means: if no messages match this rule for 30 seconds, delete it to make room. A hard timeout means: delete this rule after 5 minutes no matter what – the controller will send a fresh one!”

This was important because the flow table had limited space – like a library shelf that can only hold so many books. Old rules had to be removed to make room for new ones!

131.15.2 Key Words for Kids

Word What It Means
Flow Table A list of rules in each switch that says “when you see THIS, do THAT”
Match Fields The “if” part of a rule – what the switch looks for (like sender address, destination)
Actions The “then” part of a rule – what the switch does (forward, drop, or modify the message)
Priority A number that decides which rule wins when multiple rules match the same message
Timeout A timer that automatically removes old rules to free up space
Key Takeaway

OpenFlow flow tables enable wire-speed packet forwarding through match-action rules: packets are matched on up to 15 header fields, prioritized by rule priority, and processed with actions (forward, drop, modify). The two timeout mechanisms – idle (expires when unused) and hard (expires regardless of activity) – manage flow table memory automatically. Design rules with appropriate timeouts: idle for dynamic traffic patterns and hard for security-sensitive flows requiring periodic re-authorization.

131.16 What’s Next

If you want to… Read this
Study OpenFlow core concepts OpenFlow Core Concepts
Explore OpenFlow architecture OpenFlow Architecture
Try the OpenFlow hands-on lab OpenFlow Hands-On Lab
Learn about SDN OpenFlow challenges SDN OpenFlow Challenges
Study SDN production deployment SDN Production Framework