Openflow - Learning Module

Loading content...

0/228

Flow Tables: The Heart of OpenFlow Packet Processing

Where Packets Meet Policies

At the core of every OpenFlow switch lies a deceptively simple abstraction: the flow table. This is where high-level network policies—routing decisions, access control rules, quality of service classifications—transform into concrete packet handling behavior.

A flow table is fundamentally a lookup table that answers the question: "What should I do with this packet?" Every packet entering an OpenFlow switch traverses one or more flow tables, where it is matched against stored entries and subjected to the actions those entries prescribe.

Yet this apparent simplicity conceals profound depth. Flow tables must support wildcard matching across dozens of header fields. They must prioritize among overlapping entries. They must track statistics per-flow. They must support modification while handling millions of packets per second. And modern OpenFlow switches chain multiple tables into processing pipelines that rival the complexity of full programming languages.

This page provides an exhaustive exploration of OpenFlow flow tables: their structure, their entries, their pipeline organization, and the engineering considerations that govern their capacity and performance. Understanding flow tables is essential—they are the translation layer between SDN intelligence and actual packet forwarding.

What You Will Master

By completing this page, you will understand: the complete structure of flow table entries, how priority-based matching resolves overlaps, the multi-table pipeline introduced in OpenFlow 1.1+, table-miss handling and default behaviors, hardware implementation via TCAMs, capacity constraints and their implications, and best practices for efficient table utilization.

Flow Table Fundamentals

The Conceptual Model

A flow table is an ordered collection of flow entries, where each entry specifies:

Match fields: Criteria for selecting packets (e.g., "source IP is 10.0.0.0/24 AND destination port is 80")
Priority: Numeric value determining which entry wins when multiple entries match
Counters: Statistics tracking packets and bytes that matched this entry
Instructions/Actions: Operations to perform on matching packets
Timeouts: When the entry should automatically expire
Cookie: Controller-assigned identifier for tracking and management

When a packet arrives, the switch examines all entries in the table, identifies those whose match fields align with the packet's headers, selects the highest-priority matching entry, and executes its instructions.

Converting Mermaid diagram...

Priority-Based Matching

Priority is the tiebreaker when packets match multiple entries. OpenFlow priorities range from 0 (lowest) to 65535 (highest). When a packet matches multiple entries, only the highest-priority entry's instructions execute.

This enables powerful policy layering:

High-priority entries for specific hosts/connections
Medium-priority entries for subnet-level policies
Low-priority entries for default handling
Priority-0 entry for table-miss (unmatched packets)

Counter Tracking

Every flow entry maintains counters updated atomically as packets match:

Flow Entry Counters
Counter	Description	Notes
packet_count	Total packets matching this entry	64-bit, monotonically increasing
byte_count	Total bytes matching this entry	64-bit, includes headers
duration_sec	Seconds since flow installed	For calculating rates
duration_nsec	Nanoseconds beyond duration_sec	High-precision timing

Counter Polling vs. Push

Controllers can query counters via MULTIPART_REQUEST (stats), but frequent polling creates overhead. OpenFlow 1.4+ allows push-based flow monitoring where controllers subscribe to counter updates. For high-frequency monitoring, consider dedicated collector infrastructure that aggregates switch statistics.

Flow Entry Structure in Detail

Let's examine the complete structure of a flow entry, understanding each component at the implementation level.

The Complete Flow Entry

Flow Entry Structure (Conceptual)
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/* Conceptual flow entry structure 
 * (actual OpenFlow encoding is more complex) */
struct flow_entry {
    /* === Identification === */
    uint64_t cookie;              /* Controller-assigned identifier */
    uint64_t cookie_mask;         /* For matching in modify/delete operations */
    
    /* === Matching === */
    uint16_t priority;            /* 0-65535, higher wins on overlap */
    struct ofp_match match;       /* OXM TLV match fields */
    
    /* === Timeouts === */
    uint16_t idle_timeout;        /* Seconds without match before expiry */
    uint16_t hard_timeout;        /* Absolute seconds until expiry */
    
    /* === Flags === */
    uint16_t flags;
    /* OFPFF_SEND_FLOW_REM: notify controller on expiry
     * OFPFF_CHECK_OVERLAP: fail if would create ambiguity
     * OFPFF_RESET_COUNTS: reset counters on modify
     * OFPFF_NO_PKT_COUNTS: don't count packets
     * OFPFF_NO_BYT_COUNTS: don't count bytes */
    
    /* === Processing === */
    struct ofp_instruction instructions[];  /* What to do with matched packets */
    
    /* === Statistics (maintained by switch) === */
    uint64_t packet_count;        /* Packets matched */
    uint64_t byte_count;          /* Bytes matched */
    uint32_t duration_sec;        /* Time since installation (seconds) */
    uint32_t duration_nsec;       /* Time since installation (nanoseconds) */
};

Cookie Management

The 64-bit cookie field is a controller-opaque identifier—the switch doesn't interpret it, merely stores and reports it. Cookies enable:

Flow grouping: Assign common cookies to related entries (e.g., all rules for a tenant)
Bulk operations: Delete all entries matching a cookie/mask pattern
Debugging: Correlate flow entries with controller data structures
Auditing: Track which application created which flows

The cookie_mask enables partial matching: if cookie_mask is 0xFFFF000000000000, only the top 16 bits of the cookie are compared during modify/delete operations.

Cookie Best Practices

Structure your cookies systematically. Common patterns: (1) Top bits = application ID, (2) Middle bits = tenant/customer ID, (3) Low bits = flow sequence number. This enables efficient bulk operations: delete all flows for tenant X by matching cookie with appropriate mask.

Timeout Mechanisms

Flow entries support two independent timeout mechanisms:

Idle Timeout: The entry expires if it hasn't matched any packets for this many seconds. Useful for entries that should persist only while traffic is active—once a connection completes, the entry automatically disappears.

Hard Timeout: The entry expires unconditionally after this many seconds, regardless of activity. Useful for time-limited policies, session tokens, or periodic refresh requirements.

Both timeouts can be set to 0, meaning "never expire"—permanent entries that persist until explicitly deleted.

Idle Timeout Use Cases

•Connection-based flows (TCP sessions)
•MAC learning entries
•Reactive flow caching
•User session tracking
•Temporary redirections

Hard Timeout Use Cases

•Time-limited access tokens
•Scheduled blacklist entries
•Temporary debugging flows
•Rate-limited trial access
•Periodic policy refresh

Entry Flags

The flags field controls entry behavior:

Flag	Effect
OFPFF_SEND_FLOW_REM	Switch sends FLOW_REMOVED message when entry expires
OFPFF_CHECK_OVERLAP	Installation fails if an overlapping entry exists with same priority
OFPFF_RESET_COUNTS	Reset packet/byte counters when modifying entry
OFPFF_NO_PKT_COUNTS	Don't maintain packet counter (saves resources)
OFPFF_NO_BYT_COUNTS	Don't maintain byte counter (saves resources)

The CHECK_OVERLAP flag deserves special attention. By default, overlapping entries are allowed—priority determines the winner. But if CHECK_OVERLAP is set and the switch detects that a new entry would overlap with an existing same-priority entry (where the winner is ambiguous), it returns an error instead of installing.

Match Field Taxonomy

OpenFlow match fields specify which packets an entry applies to. The protocol has evolved from a fixed 12-tuple (OF 1.0) to an extensible Type-Length-Value (TLV) format called OXM (OpenFlow Extensible Match) in OF 1.2+.

Layer 2 (Data Link) Match Fields

Layer 2 Match Fields
Field	Size	Description	Maskable?
in_port	32 bits	Physical or logical switch port packet arrived on	No
in_phy_port	32 bits	Physical port (when in_port is a tunnel endpoint)	No
metadata	64 bits	Controller-written metadata passed between tables	Yes
eth_dst	48 bits	Ethernet destination MAC address	Yes
eth_src	48 bits	Ethernet source MAC address	Yes
eth_type	16 bits	Ethernet type (0x0800=IPv4, 0x86DD=IPv6, etc.)	No
vlan_vid	12 bits	VLAN ID from 802.1Q header	Yes
vlan_pcp	3 bits	VLAN priority code point	No

Layer 3 (Network) Match Fields

Layer 3 Match Fields
Field	Size	Description	Maskable?
ip_dscp	6 bits	Differentiated Services Code Point	No
ip_ecn	2 bits	Explicit Congestion Notification bits	No
ip_proto	8 bits	IP protocol number (6=TCP, 17=UDP, 1=ICMP)	No
ipv4_src	32 bits	IPv4 source address	Yes (prefix)
ipv4_dst	32 bits	IPv4 destination address	Yes (prefix)
ipv6_src	128 bits	IPv6 source address	Yes (prefix)
ipv6_dst	128 bits	IPv6 destination address	Yes (prefix)
ipv6_flabel	20 bits	IPv6 flow label	Yes
ipv6_exthdr	9 bits	IPv6 extension header pseudo-field	Yes

Layer 4 (Transport) Match Fields

Layer 4 Match Fields
Field	Size	Description	Maskable?
tcp_src	16 bits	TCP source port	No
tcp_dst	16 bits	TCP destination port	No
tcp_flags	12 bits	TCP flags (SYN, ACK, FIN, etc.)	Yes
udp_src	16 bits	UDP source port	No
udp_dst	16 bits	UDP destination port	No
sctp_src	16 bits	SCTP source port	No
sctp_dst	16 bits	SCTP destination port	No
icmpv4_type	8 bits	ICMPv4 message type	No
icmpv4_code	8 bits	ICMPv4 message code	No
icmpv6_type	8 bits	ICMPv6 message type	No
icmpv6_code	8 bits	ICMPv6 message code	No

MPLS and Tunnel Match Fields

MPLS and Tunnel Match Fields
Field	Size	Description	Maskable?
mpls_label	20 bits	MPLS label value	No
mpls_tc	3 bits	MPLS traffic class	No
mpls_bos	1 bit	Bottom-of-Stack bit	No
pbb_isid	24 bits	Provider Backbone Bridge I-SID	Yes
tunnel_id	64 bits	Logical port metadata (tunnel endpoint)	Yes

Match Prerequisites

Most match fields have prerequisites—you can only match on tcp_dst if you've also specified ip_proto=6 (TCP). OXM enforces this through explicit preconditions. Common chains: eth_type=0x0800 → ipv4_* → tcp_* or eth_type=0x8847 → mpls_*. Failing to specify prerequisites results in flow installation errors.

Wildcarding and Masking

OpenFlow supports two levels of matching granularity:

Exact match: The packet header field must exactly equal the specified value. Used for specific host/port matches.

Wildcard match: The field is either fully wildcarded (any value matches) or masked (certain bits must match). IP addresses commonly use CIDR-style prefix matching implemented via masks.

Example: To match all packets from 10.0.0.0/8:

Match field: ipv4_src = 10.0.0.0
Mask: 0xFF000000 (255.0.0.0)
This matches 10.x.x.x where x is any value

Wildcards dramatically reduce table entries needed. Instead of 256 entries for 10.0.0.0 through 10.0.0.255, a single wildcarded entry covers all.

The Multi-Table Pipeline

OpenFlow 1.0 supported only a single flow table—functional but limiting. Complex forwarding decisions required cramming everything into one table, leading to explosion in entry count due to policy Cartesian products.

OpenFlow 1.1 introduced multiple flow tables arranged in a processing pipeline. Packets traverse tables sequentially, with each table adding context, making decisions, or accumulating actions for eventual execution.

Pipeline Processing Model

Converting Mermaid diagram...

Key Pipeline Concepts

Table numbering: Tables are numbered 0 through n-1. Processing always starts at table 0. Entries can only forward to higher-numbered tables (no backward goto).

Metadata: A 64-bit register passed between tables. Tables can write metadata that influences decisions in later tables. Example: Table 0 classifies traffic as "external" (metadata bit) → Table 2 applies stricter routing for external traffic.

Action set: Actions accumulated across tables, executed atomically when packet exits the pipeline. Multiple tables can contribute to the final action set.

Goto-table instruction: Directs the packet to continue processing at a specified table. If no goto-table instruction is present in the matched entry, the packet exits the pipeline and the action set executes.

Benefits of Multi-Table Pipelines

•Reduced entry count: Avoid Cartesian product explosion. 100 L2 rules + 100 L3 rules = 200 entries instead of 10,000
•Modular policies: Each table handles one concern (port classification, forwarding, ACL, QoS) independently
•Hardware efficiency: Tables can be implemented in different memory types (TCAM for wildcards, SRAM for exact match)
•Incremental updates: Update one table without recomputing others
•Clear semantics: Pipeline structure mirrors network switch ASIC architecture

Pipeline Design Philosophy

Design pipelines to mirror conceptual processing stages. A common pattern: Table 0 (port/VLAN classification) → Table 1 (L2 learning/forwarding) → Table 2 (L3 routing) → Table 3 (security/ACL) → Table 4 (QoS) → Table 5 (output). This makes policies readable and maintainable.

Action Set vs. Apply-Actions

OpenFlow distinguishes between two ways to execute actions:

Apply-actions instruction: Execute actions immediately, in order, then continue processing. Useful for packet modifications that affect subsequent table matching.

Write-actions instruction: Add actions to the action set without executing yet. Actions accumulate across tables and execute atomically when the packet exits the pipeline.

Clear-actions instruction: Remove all actions from the action set. Enables one table to override earlier decisions.

When the packet exits the pipeline, the action set executes in a defined order:

Copy TTL inwards
Pop all MPLS/PBB tags
Push tags (MPLS, PBB, VLAN)
Copy TTL outwards
Decrement TTL
Set fields
QoS (set queue)
Group (multicast, load balance)
Output

This ordering ensures predictable behavior regardless of the order actions were added to the set.

Table-Miss Handling

What happens when a packet doesn't match any entry in a flow table? This table-miss scenario is fundamental to OpenFlow operation and has evolved across protocol versions.

Table-Miss Entry (Modern Approach)

In OpenFlow 1.3+, table-miss is handled by a special flow entry:

Priority 0 (lowest possible)
Wildcard match (matches all packets)
Actions as configured by controller

This entry is treated like any other flow entry—it has counters, can be modified, and can be deleted. If no table-miss entry exists and no other entries match, the packet is dropped by default.

Table-Miss Action Strategies

•Send to controller: Packets sent as PACKET_IN for reactive flow installation. Common during initial deployment or for learning switches.
•Drop: Silently discard unmatched packets. Secure default for production networks with proactively installed flows.
•Goto next table: Forward to another table for further processing. Useful in pipelines where one table provides classification used by later tables.
•Apply default actions: Output to specific port(s), set default VLAN, or mark with default QoS.

Table-Miss Entry Examples
Python (Ryu)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
# Table-miss: Send to controller
# Used for reactive flow installation
def add_table_miss_entry_to_controller(self, datapath, table_id=0):
    ofproto = datapath.ofproto
    parser = datapath.ofproto_parser
    
    # Match: empty (matches everything)
    match = parser.OFPMatch()
    
    # Actions: send packet to controller
    actions = [parser.OFPActionOutput(
        ofproto.OFPP_CONTROLLER,
        ofproto.OFPCML_NO_BUFFER  # Send full packet
    )]
    
    # Instructions: apply actions immediately
    instructions = [parser.OFPInstructionActions(
        ofproto.OFPIT_APPLY_ACTIONS, actions)]
    
    # Install with priority 0 (table-miss)
    mod = parser.OFPFlowMod(
        datapath=datapath,
        table_id=table_id,
        priority=0,  # Lowest priority
        match=match,
        instructions=instructions
    )
    datapath.send_msg(mod)
 
 
# Table-miss: Drop
# Secure default for production networks
def add_table_miss_entry_drop(self, datapath, table_id=0):
    ofproto = datapath.ofproto
    parser = datapath.ofproto_parser
    
    match = parser.OFPMatch()
    instructions = []  # No instructions = drop
    
    mod = parser.OFPFlowMod(
        datapath=datapath,
        table_id=table_id,
        priority=0,
        match=match,
        instructions=instructions
    )
    datapath.send_msg(mod)
 
 
# Table-miss: Forward to next table
# Used in multi-table pipelines
def add_table_miss_entry_goto(self, datapath, src_table, dst_table):
    ofproto = datapath.ofproto
    parser = datapath.ofproto_parser
    
    match = parser.OFPMatch()
    
    # Instruction: goto next table
    instructions = [parser.OFPInstructionGotoTable(dst_table)]
    
    mod = parser.OFPFlowMod(
        datapath=datapath,
        table_id=src_table,
        priority=0,
        match=match,
        instructions=instructions
    )
    datapath.send_msg(mod)

The Controller Bottleneck

Sending every unmatched packet to the controller creates significant overhead. At 10 Gbps line rate with 64-byte packets, a table-miss rate of just 1% generates 1.5 million PACKET_IN messages per second. Controllers must handle this load or networks collapse. Strategies: aggressive proactive flow installation, flow aggregation with wildcards, and careful table-miss policy selection.

Historical: OF 1.0 Table-Miss Behavior

In OpenFlow 1.0, table-miss behavior was configured via SET_CONFIG message with the 'send packet to controller' length. If miss_send_len was 0, unmatched packets were dropped. Otherwise, the first miss_send_len bytes were sent to the controller.

This legacy mechanism was replaced by the explicit table-miss entry approach in OF 1.3, which provides more flexible handling and is consistent with normal flow entry management.

Hardware Implementation: TCAM

Understanding flow table hardware implementation is essential for designing efficient SDN applications. The key technology is TCAM (Ternary Content-Addressable Memory).

Content-Addressable Memory (CAM)

Traditional memory is address-addressable: you provide an address, it returns data at that address. CAM inverts this: you provide data (search key), and it returns the address where that data is stored (if anywhere).

This enables O(1) exact-match lookups regardless of table size—essential for wire-speed packet processing.

Ternary CAM (TCAM)

TCAM extends CAM with a third state: "don't care" (X). Each bit can be:

0: Must match 0
1: Must match 1
X: Matches either 0 or 1

This enables wildcard matching. An IPv4 address entry of "10.0.X.X" (where each X represents 8 don't-care bits) matches all addresses in 10.0.0.0/16.

Converting Mermaid diagram...

TCAM Characteristics and Constraints

TCAM is expensive—both in cost and power:

TCAM vs. SRAM Comparison
Aspect	TCAM	SRAM
Lookup speed	O(1) parallel, ~10ns	O(1) indexed, ~10ns
Match type	Wildcards, masks, ranges	Exact match only
Power consumption	~15W per Mbit	~0.1W per Mbit
Cost per bit	~10x SRAM	Baseline
Density	~6 transistors/bit	~1 transistor/bit
Typical capacity	1K-64K entries	Millions of entries

TCAM is Precious Real Estate

A typical top-of-rack switch might have 2K-8K TCAM entries for OpenFlow. Each wildcard flow entry consumes one TCAM slot. Running out of TCAM means new flows are rejected. Smart entry design—using wildcards, aggregating flows, minimizing match fields—is essential for scalable SDN deployment.

Entry Width and Utilization

TCAM entries have fixed width. A commodity switch TCAM might be 480 bits wide to accommodate all OpenFlow match fields. If your match only uses 48+48 (MAC) + 32 (IPv4 dst) = 128 bits, you still consume the full 480-bit entry.

Strategies to maximize TCAM utilization:

Field reduction: Only include match fields you actually need. Platform-specific implementations may optimize based on which fields are populated.

Entry aggregation: Combine multiple specific entries into wildcarded supersets where possible. 10.0.0.1, 10.0.0.2, ... 10.0.0.255 → 10.0.0.0/24.

Table migration: Move exact-match flows to cheaper SRAM hash tables. Reserve TCAM for wildcard matches. Some switches support hybrid table modes.

Priority encoding: TCAM inherently costs more for lower priorities that might match (must check all entries). Some architectures optimize by partitioning.

Software Flow Tables

Not all OpenFlow implementations use hardware TCAM. Software switches (Open vSwitch, BESS) implement flow tables in CPU memory using optimized data structures:

Linear search: Simple but O(n). Only viable for very small tables.

Hash tables: O(1) average for exact match. Doesn't support wildcards.

Tuple space search: Group entries by "tuple" (set of fields matched with what mask). Hash within tuples. Enables wildcard matching with reasonable performance.

Decision trees: Hierarchical structure optimized for specific field combinations.

Software switches trade performance for flexibility—Open vSwitch can handle millions of entries but at lower packet rates than hardware switches.

Table Capacity Planning

Planning flow table capacity is a critical network engineering exercise. Running out of table space mid-deployment is catastrophic—new connections may fail silently or fall through to unintended catch-all rules.

Capacity Factors

Key Capacity Dimensions

•Per-table entry limits: Each table has a maximum entry count. Limits vary by hardware (2K-64K typical for TCAM tables).
•Total entry pool: Some switches share TCAM across all tables from a common pool; others have per-table dedicated resources.
•Entry width consumption: Wide matches (more fields) may consume multiple TCAM slots per logical entry.
•Counters and timers: Per-entry statistics consume additional memory. Some platforms offer 'lightweight' entries without counters.
•Group/meter table limits: Separate capacity constraints apply to group and meter tables.

Estimating Entry Requirements

Entry requirements depend on your application model:

Entry Requirements by Application Type
Application	Entry Scaling Factor	Example at 1000 hosts
L2 MAC learning	O(n) hosts	1,000 entries
L3 routing (per-host)	O(n) hosts	1,000 entries
L3 routing (prefixes)	O(p) prefixes	~600K Internet routes (problem!)
Firewall (host pairs)	O(n²) forbidden pairs	1,000,000 entries (problem!)
Load balancing (VIPs)	O(v) virtual IPs	Typically 10-100 entries
QoS classification	O(c) traffic classes	Typically 10-50 entries
Reactive per-flow	O(f) active flows	Variable—could be millions

Avoid O(n²) Scaling

Policies that scale with the square of entities (host-to-host ACLs, all-pairs QoS) quickly exhaust tables. Redesign to use aggregation (subnet policies), indirection (group-based tagging), or push evaluation to endpoint hosts where per-host state is acceptable.

Capacity Monitoring

OpenFlow provides mechanisms to monitor table utilization:

Multipart Table Stats Request: Query entry counts per table Table Features Request: Query maximum table capacities Vacancy Events (OF 1.4+): Proactive notification when table reaches threshold

Production deployments should:

Monitor table utilization continuously
Alert when crossing 70% capacity
Action required above 80% capacity
Emergency response above 90% capacity

Failure Modes

When tables fill, switches typically reject new FLOW_MOD installations with an error. Some scenarios:

Graceful degradation: New flows route through table-miss (may overload controller) Silent failure: Packets drop or route incorrectly Cascading failure: Back-pressure to controller stalls entire network

Design for headroom—plan for 50-70% peak utilization to accommodate bursts.

Monitoring Table Capacity
Python (Ryu)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
from ryu.controller.handler import set_ev_cls
from ryu.controller import ofp_event
 
class TableMonitor:
    """Monitor flow table utilization and alert on capacity issues."""
    
    WARNING_THRESHOLD = 0.70  # 70%
    CRITICAL_THRESHOLD = 0.85  # 85%
    
    def request_table_stats(self, datapath):
        """Request current table statistics from switch."""
        parser = datapath.ofproto_parser
        req = parser.OFPTableStatsRequest(datapath, 0)
        datapath.send_msg(req)
    
    @set_ev_cls(ofp_event.EventOFPTableStatsReply, MAIN_DISPATCHER)
    def table_stats_reply_handler(self, ev):
        """Process table statistics reply."""
        datapath = ev.msg.datapath
        
        for stat in ev.msg.body:
            table_id = stat.table_id
            active_count = stat.active_count
            max_entries = stat.max_entries  # May be 0 if unknown
            
            if max_entries > 0:
                utilization = active_count / max_entries
                
                if utilization >= self.CRITICAL_THRESHOLD:
                    self.logger.critical(
                        f"CRITICAL: Switch {datapath.id} Table {table_id} "
                        f"at {utilization:.1%} capacity "
                        f"({active_count}/{max_entries})"
                    )
                    self.trigger_emergency_cleanup(datapath, table_id)
                    
                elif utilization >= self.WARNING_THRESHOLD:
                    self.logger.warning(
                        f"WARNING: Switch {datapath.id} Table {table_id} "
                        f"at {utilization:.1%} capacity"
                    )
    
    def trigger_emergency_cleanup(self, datapath, table_id):
        """Emergency flow cleanup when table near capacity."""
        # Example: Delete oldest idle flows
        parser = datapath.ofproto_parser
        ofproto = datapath.ofproto
        
        # Request flow stats sorted by idle time
        match = parser.OFPMatch()
        req = parser.OFPFlowStatsRequest(
            datapath, 0, table_id, ofproto.OFPP_ANY, 
            ofproto.OFPG_ANY, 0, 0, match
        )
        datapath.send_msg(req)
        # Handler would identify and delete least-recently-matched flows

Summary and Key Takeaways

Flow tables are the foundation of OpenFlow packet processing. Every forwarding decision, policy enforcement, and traffic manipulation is expressed through flow entries that match packets and execute actions.

Core Concepts Mastered

•Flow entry structure: Match fields + priority + counters + instructions + timeouts + cookie form complete entries
•Priority-based matching: Highest priority among all matching entries determines packet handling
•Match field taxonomy: Layer 2 through Layer 4 fields, plus MPLS/tunnel metadata, with optional masking
•Multi-table pipeline: Packets traverse numbered tables via goto-table, accumulating actions in action set
•Table-miss handling: Priority-0 wildcard entries provide configurable default behavior
•TCAM implementation: Hardware wildcard matching with O(1) lookup but expensive cost/power/capacity
•Capacity planning: Entry scaling, utilization monitoring, and graceful degradation strategies

What's Next:

With flow table fundamentals understood, we'll now explore match-action rules in detail—the combining of match fields with specific actions to express complete forwarding policies. You'll learn the full action vocabulary, instruction types, and how to compose them for complex network behaviors.

Page Complete

You now have a thorough understanding of OpenFlow flow tables—their structure, matching semantics, pipeline organization, and hardware constraints. This knowledge is essential for designing efficient SDN forwarding rules and capacity planning. Next, we dive deep into match-action rules.

Flow Tables: The Heart of OpenFlow Packet Processing

Where Packets Meet Policies

What You Will Master

Flow Table Fundamentals

The Conceptual Model

A flow table is an ordered collection of flow entries, where each entry specifies:

Match fields: Criteria for selecting packets (e.g., "source IP is 10.0.0.0/24 AND destination port is 80")
Priority: Numeric value determining which entry wins when multiple entries match
Counters: Statistics tracking packets and bytes that matched this entry
Instructions/Actions: Operations to perform on matching packets
Timeouts: When the entry should automatically expire
Cookie: Controller-assigned identifier for tracking and management

Converting Mermaid diagram...

Priority-Based Matching

This enables powerful policy layering:

High-priority entries for specific hosts/connections
Medium-priority entries for subnet-level policies
Low-priority entries for default handling
Priority-0 entry for table-miss (unmatched packets)

Counter Tracking

Every flow entry maintains counters updated atomically as packets match:

Flow Entry Counters
Counter	Description	Notes
packet_count	Total packets matching this entry	64-bit, monotonically increasing
byte_count	Total bytes matching this entry	64-bit, includes headers
duration_sec	Seconds since flow installed	For calculating rates
duration_nsec	Nanoseconds beyond duration_sec	High-precision timing

Counter Polling vs. Push

Flow Entry Structure in Detail

Let's examine the complete structure of a flow entry, understanding each component at the implementation level.

The Complete Flow Entry

Flow Entry Structure (Conceptual)
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/* Conceptual flow entry structure 
 * (actual OpenFlow encoding is more complex) */
struct flow_entry {
    /* === Identification === */
    uint64_t cookie;              /* Controller-assigned identifier */
    uint64_t cookie_mask;         /* For matching in modify/delete operations */
    
    /* === Matching === */
    uint16_t priority;            /* 0-65535, higher wins on overlap */
    struct ofp_match match;       /* OXM TLV match fields */
    
    /* === Timeouts === */
    uint16_t idle_timeout;        /* Seconds without match before expiry */
    uint16_t hard_timeout;        /* Absolute seconds until expiry */
    
    /* === Flags === */
    uint16_t flags;
    /* OFPFF_SEND_FLOW_REM: notify controller on expiry
     * OFPFF_CHECK_OVERLAP: fail if would create ambiguity
     * OFPFF_RESET_COUNTS: reset counters on modify
     * OFPFF_NO_PKT_COUNTS: don't count packets
     * OFPFF_NO_BYT_COUNTS: don't count bytes */
    
    /* === Processing === */
    struct ofp_instruction instructions[];  /* What to do with matched packets */
    
    /* === Statistics (maintained by switch) === */
    uint64_t packet_count;        /* Packets matched */
    uint64_t byte_count;          /* Bytes matched */
    uint32_t duration_sec;        /* Time since installation (seconds) */
    uint32_t duration_nsec;       /* Time since installation (nanoseconds) */
};

Cookie Management

The 64-bit cookie field is a controller-opaque identifier—the switch doesn't interpret it, merely stores and reports it. Cookies enable:

Flow grouping: Assign common cookies to related entries (e.g., all rules for a tenant)
Bulk operations: Delete all entries matching a cookie/mask pattern
Debugging: Correlate flow entries with controller data structures
Auditing: Track which application created which flows

The cookie_mask enables partial matching: if cookie_mask is 0xFFFF000000000000, only the top 16 bits of the cookie are compared during modify/delete operations.

Cookie Best Practices

Timeout Mechanisms

Flow entries support two independent timeout mechanisms:

Hard Timeout: The entry expires unconditionally after this many seconds, regardless of activity. Useful for time-limited policies, session tokens, or periodic refresh requirements.

Both timeouts can be set to 0, meaning "never expire"—permanent entries that persist until explicitly deleted.

Idle Timeout Use Cases

•Connection-based flows (TCP sessions)
•MAC learning entries
•Reactive flow caching
•User session tracking
•Temporary redirections

Hard Timeout Use Cases

•Time-limited access tokens
•Scheduled blacklist entries
•Temporary debugging flows
•Rate-limited trial access
•Periodic policy refresh

Entry Flags

The flags field controls entry behavior:

Flag	Effect
OFPFF_SEND_FLOW_REM	Switch sends FLOW_REMOVED message when entry expires
OFPFF_CHECK_OVERLAP	Installation fails if an overlapping entry exists with same priority
OFPFF_RESET_COUNTS	Reset packet/byte counters when modifying entry
OFPFF_NO_PKT_COUNTS	Don't maintain packet counter (saves resources)
OFPFF_NO_BYT_COUNTS	Don't maintain byte counter (saves resources)

Match Field Taxonomy

Layer 2 (Data Link) Match Fields

Layer 2 Match Fields
Field	Size	Description	Maskable?
in_port	32 bits	Physical or logical switch port packet arrived on	No
in_phy_port	32 bits	Physical port (when in_port is a tunnel endpoint)	No
metadata	64 bits	Controller-written metadata passed between tables	Yes
eth_dst	48 bits	Ethernet destination MAC address	Yes
eth_src	48 bits	Ethernet source MAC address	Yes
eth_type	16 bits	Ethernet type (0x0800=IPv4, 0x86DD=IPv6, etc.)	No
vlan_vid	12 bits	VLAN ID from 802.1Q header	Yes
vlan_pcp	3 bits	VLAN priority code point	No

Layer 3 (Network) Match Fields

Layer 3 Match Fields
Field	Size	Description	Maskable?
ip_dscp	6 bits	Differentiated Services Code Point	No
ip_ecn	2 bits	Explicit Congestion Notification bits	No
ip_proto	8 bits	IP protocol number (6=TCP, 17=UDP, 1=ICMP)	No
ipv4_src	32 bits	IPv4 source address	Yes (prefix)
ipv4_dst	32 bits	IPv4 destination address	Yes (prefix)
ipv6_src	128 bits	IPv6 source address	Yes (prefix)
ipv6_dst	128 bits	IPv6 destination address	Yes (prefix)
ipv6_flabel	20 bits	IPv6 flow label	Yes
ipv6_exthdr	9 bits	IPv6 extension header pseudo-field	Yes

Layer 4 (Transport) Match Fields

Layer 4 Match Fields
Field	Size	Description	Maskable?
tcp_src	16 bits	TCP source port	No
tcp_dst	16 bits	TCP destination port	No
tcp_flags	12 bits	TCP flags (SYN, ACK, FIN, etc.)	Yes
udp_src	16 bits	UDP source port	No
udp_dst	16 bits	UDP destination port	No
sctp_src	16 bits	SCTP source port	No
sctp_dst	16 bits	SCTP destination port	No
icmpv4_type	8 bits	ICMPv4 message type	No
icmpv4_code	8 bits	ICMPv4 message code	No
icmpv6_type	8 bits	ICMPv6 message type	No
icmpv6_code	8 bits	ICMPv6 message code	No

MPLS and Tunnel Match Fields

MPLS and Tunnel Match Fields
Field	Size	Description	Maskable?
mpls_label	20 bits	MPLS label value	No
mpls_tc	3 bits	MPLS traffic class	No
mpls_bos	1 bit	Bottom-of-Stack bit	No
pbb_isid	24 bits	Provider Backbone Bridge I-SID	Yes
tunnel_id	64 bits	Logical port metadata (tunnel endpoint)	Yes

Match Prerequisites

Wildcarding and Masking

OpenFlow supports two levels of matching granularity:

Exact match: The packet header field must exactly equal the specified value. Used for specific host/port matches.

Wildcard match: The field is either fully wildcarded (any value matches) or masked (certain bits must match). IP addresses commonly use CIDR-style prefix matching implemented via masks.

Example: To match all packets from 10.0.0.0/8:

Match field: ipv4_src = 10.0.0.0
Mask: 0xFF000000 (255.0.0.0)
This matches 10.x.x.x where x is any value

Wildcards dramatically reduce table entries needed. Instead of 256 entries for 10.0.0.0 through 10.0.0.255, a single wildcarded entry covers all.

The Multi-Table Pipeline

Pipeline Processing Model

Converting Mermaid diagram...

Key Pipeline Concepts

Table numbering: Tables are numbered 0 through n-1. Processing always starts at table 0. Entries can only forward to higher-numbered tables (no backward goto).

Action set: Actions accumulated across tables, executed atomically when packet exits the pipeline. Multiple tables can contribute to the final action set.

Benefits of Multi-Table Pipelines

•Reduced entry count: Avoid Cartesian product explosion. 100 L2 rules + 100 L3 rules = 200 entries instead of 10,000
•Modular policies: Each table handles one concern (port classification, forwarding, ACL, QoS) independently
•Hardware efficiency: Tables can be implemented in different memory types (TCAM for wildcards, SRAM for exact match)
•Incremental updates: Update one table without recomputing others
•Clear semantics: Pipeline structure mirrors network switch ASIC architecture

Pipeline Design Philosophy

Action Set vs. Apply-Actions

OpenFlow distinguishes between two ways to execute actions:

Apply-actions instruction: Execute actions immediately, in order, then continue processing. Useful for packet modifications that affect subsequent table matching.

Write-actions instruction: Add actions to the action set without executing yet. Actions accumulate across tables and execute atomically when the packet exits the pipeline.

Clear-actions instruction: Remove all actions from the action set. Enables one table to override earlier decisions.

When the packet exits the pipeline, the action set executes in a defined order:

Copy TTL inwards
Pop all MPLS/PBB tags
Push tags (MPLS, PBB, VLAN)
Copy TTL outwards
Decrement TTL
Set fields
QoS (set queue)
Group (multicast, load balance)
Output

This ordering ensures predictable behavior regardless of the order actions were added to the set.

Table-Miss Handling

What happens when a packet doesn't match any entry in a flow table? This table-miss scenario is fundamental to OpenFlow operation and has evolved across protocol versions.

Table-Miss Entry (Modern Approach)

In OpenFlow 1.3+, table-miss is handled by a special flow entry:

Priority 0 (lowest possible)
Wildcard match (matches all packets)
Actions as configured by controller

This entry is treated like any other flow entry—it has counters, can be modified, and can be deleted. If no table-miss entry exists and no other entries match, the packet is dropped by default.

Table-Miss Action Strategies

•Send to controller: Packets sent as PACKET_IN for reactive flow installation. Common during initial deployment or for learning switches.
•Drop: Silently discard unmatched packets. Secure default for production networks with proactively installed flows.
•Goto next table: Forward to another table for further processing. Useful in pipelines where one table provides classification used by later tables.
•Apply default actions: Output to specific port(s), set default VLAN, or mark with default QoS.

Table-Miss Entry Examples
Python (Ryu)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
# Table-miss: Send to controller
# Used for reactive flow installation
def add_table_miss_entry_to_controller(self, datapath, table_id=0):
    ofproto = datapath.ofproto
    parser = datapath.ofproto_parser
    
    # Match: empty (matches everything)
    match = parser.OFPMatch()
    
    # Actions: send packet to controller
    actions = [parser.OFPActionOutput(
        ofproto.OFPP_CONTROLLER,
        ofproto.OFPCML_NO_BUFFER  # Send full packet
    )]
    
    # Instructions: apply actions immediately
    instructions = [parser.OFPInstructionActions(
        ofproto.OFPIT_APPLY_ACTIONS, actions)]
    
    # Install with priority 0 (table-miss)
    mod = parser.OFPFlowMod(
        datapath=datapath,
        table_id=table_id,
        priority=0,  # Lowest priority
        match=match,
        instructions=instructions
    )
    datapath.send_msg(mod)
 
 
# Table-miss: Drop
# Secure default for production networks
def add_table_miss_entry_drop(self, datapath, table_id=0):
    ofproto = datapath.ofproto
    parser = datapath.ofproto_parser
    
    match = parser.OFPMatch()
    instructions = []  # No instructions = drop
    
    mod = parser.OFPFlowMod(
        datapath=datapath,
        table_id=table_id,
        priority=0,
        match=match,
        instructions=instructions
    )
    datapath.send_msg(mod)
 
 
# Table-miss: Forward to next table
# Used in multi-table pipelines
def add_table_miss_entry_goto(self, datapath, src_table, dst_table):
    ofproto = datapath.ofproto
    parser = datapath.ofproto_parser
    
    match = parser.OFPMatch()
    
    # Instruction: goto next table
    instructions = [parser.OFPInstructionGotoTable(dst_table)]
    
    mod = parser.OFPFlowMod(
        datapath=datapath,
        table_id=src_table,
        priority=0,
        match=match,
        instructions=instructions
    )
    datapath.send_msg(mod)

The Controller Bottleneck

Historical: OF 1.0 Table-Miss Behavior

This legacy mechanism was replaced by the explicit table-miss entry approach in OF 1.3, which provides more flexible handling and is consistent with normal flow entry management.

Hardware Implementation: TCAM

Understanding flow table hardware implementation is essential for designing efficient SDN applications. The key technology is TCAM (Ternary Content-Addressable Memory).

Content-Addressable Memory (CAM)

This enables O(1) exact-match lookups regardless of table size—essential for wire-speed packet processing.

Ternary CAM (TCAM)

TCAM extends CAM with a third state: "don't care" (X). Each bit can be:

0: Must match 0
1: Must match 1
X: Matches either 0 or 1

This enables wildcard matching. An IPv4 address entry of "10.0.X.X" (where each X represents 8 don't-care bits) matches all addresses in 10.0.0.0/16.

Converting Mermaid diagram...

TCAM Characteristics and Constraints

TCAM is expensive—both in cost and power:

TCAM vs. SRAM Comparison
Aspect	TCAM	SRAM
Lookup speed	O(1) parallel, ~10ns	O(1) indexed, ~10ns
Match type	Wildcards, masks, ranges	Exact match only
Power consumption	~15W per Mbit	~0.1W per Mbit
Cost per bit	~10x SRAM	Baseline
Density	~6 transistors/bit	~1 transistor/bit
Typical capacity	1K-64K entries	Millions of entries

TCAM is Precious Real Estate

Entry Width and Utilization

Strategies to maximize TCAM utilization:

Field reduction: Only include match fields you actually need. Platform-specific implementations may optimize based on which fields are populated.

Entry aggregation: Combine multiple specific entries into wildcarded supersets where possible. 10.0.0.1, 10.0.0.2, ... 10.0.0.255 → 10.0.0.0/24.

Table migration: Move exact-match flows to cheaper SRAM hash tables. Reserve TCAM for wildcard matches. Some switches support hybrid table modes.

Priority encoding: TCAM inherently costs more for lower priorities that might match (must check all entries). Some architectures optimize by partitioning.

Software Flow Tables

Not all OpenFlow implementations use hardware TCAM. Software switches (Open vSwitch, BESS) implement flow tables in CPU memory using optimized data structures:

Linear search: Simple but O(n). Only viable for very small tables.

Hash tables: O(1) average for exact match. Doesn't support wildcards.

Tuple space search: Group entries by "tuple" (set of fields matched with what mask). Hash within tuples. Enables wildcard matching with reasonable performance.

Decision trees: Hierarchical structure optimized for specific field combinations.

Software switches trade performance for flexibility—Open vSwitch can handle millions of entries but at lower packet rates than hardware switches.

Table Capacity Planning

Capacity Factors

Key Capacity Dimensions

•Per-table entry limits: Each table has a maximum entry count. Limits vary by hardware (2K-64K typical for TCAM tables).
•Total entry pool: Some switches share TCAM across all tables from a common pool; others have per-table dedicated resources.
•Entry width consumption: Wide matches (more fields) may consume multiple TCAM slots per logical entry.
•Counters and timers: Per-entry statistics consume additional memory. Some platforms offer 'lightweight' entries without counters.
•Group/meter table limits: Separate capacity constraints apply to group and meter tables.

Estimating Entry Requirements

Entry requirements depend on your application model:

Entry Requirements by Application Type
Application	Entry Scaling Factor	Example at 1000 hosts
L2 MAC learning	O(n) hosts	1,000 entries
L3 routing (per-host)	O(n) hosts	1,000 entries
L3 routing (prefixes)	O(p) prefixes	~600K Internet routes (problem!)
Firewall (host pairs)	O(n²) forbidden pairs	1,000,000 entries (problem!)
Load balancing (VIPs)	O(v) virtual IPs	Typically 10-100 entries
QoS classification	O(c) traffic classes	Typically 10-50 entries
Reactive per-flow	O(f) active flows	Variable—could be millions

Avoid O(n²) Scaling

Capacity Monitoring

OpenFlow provides mechanisms to monitor table utilization:

Production deployments should:

Monitor table utilization continuously
Alert when crossing 70% capacity
Action required above 80% capacity
Emergency response above 90% capacity

Failure Modes

When tables fill, switches typically reject new FLOW_MOD installations with an error. Some scenarios:

Design for headroom—plan for 50-70% peak utilization to accommodate bursts.

Monitoring Table Capacity
Python (Ryu)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
from ryu.controller.handler import set_ev_cls
from ryu.controller import ofp_event
 
class TableMonitor:
    """Monitor flow table utilization and alert on capacity issues."""
    
    WARNING_THRESHOLD = 0.70  # 70%
    CRITICAL_THRESHOLD = 0.85  # 85%
    
    def request_table_stats(self, datapath):
        """Request current table statistics from switch."""
        parser = datapath.ofproto_parser
        req = parser.OFPTableStatsRequest(datapath, 0)
        datapath.send_msg(req)
    
    @set_ev_cls(ofp_event.EventOFPTableStatsReply, MAIN_DISPATCHER)
    def table_stats_reply_handler(self, ev):
        """Process table statistics reply."""
        datapath = ev.msg.datapath
        
        for stat in ev.msg.body:
            table_id = stat.table_id
            active_count = stat.active_count
            max_entries = stat.max_entries  # May be 0 if unknown
            
            if max_entries > 0:
                utilization = active_count / max_entries
                
                if utilization >= self.CRITICAL_THRESHOLD:
                    self.logger.critical(
                        f"CRITICAL: Switch {datapath.id} Table {table_id} "
                        f"at {utilization:.1%} capacity "
                        f"({active_count}/{max_entries})"
                    )
                    self.trigger_emergency_cleanup(datapath, table_id)
                    
                elif utilization >= self.WARNING_THRESHOLD:
                    self.logger.warning(
                        f"WARNING: Switch {datapath.id} Table {table_id} "
                        f"at {utilization:.1%} capacity"
                    )
    
    def trigger_emergency_cleanup(self, datapath, table_id):
        """Emergency flow cleanup when table near capacity."""
        # Example: Delete oldest idle flows
        parser = datapath.ofproto_parser
        ofproto = datapath.ofproto
        
        # Request flow stats sorted by idle time
        match = parser.OFPMatch()
        req = parser.OFPFlowStatsRequest(
            datapath, 0, table_id, ofproto.OFPP_ANY, 
            ofproto.OFPG_ANY, 0, 0, match
        )
        datapath.send_msg(req)
        # Handler would identify and delete least-recently-matched flows

Summary and Key Takeaways

Core Concepts Mastered

•Flow entry structure: Match fields + priority + counters + instructions + timeouts + cookie form complete entries
•Priority-based matching: Highest priority among all matching entries determines packet handling
•Match field taxonomy: Layer 2 through Layer 4 fields, plus MPLS/tunnel metadata, with optional masking
•Multi-table pipeline: Packets traverse numbered tables via goto-table, accumulating actions in action set
•Table-miss handling: Priority-0 wildcard entries provide configurable default behavior
•TCAM implementation: Hardware wildcard matching with O(1) lookup but expensive cost/power/capacity
•Capacity planning: Entry scaling, utilization monitoring, and graceful degradation strategies

What's Next:

Page Complete