Software-define networking - Generalized forwarding
In Match and Forward based on Longest-prefix Matching, we have seen a router performing destination-based forwarding based on the longest-prefix by simply matching packet destination to forwarding table entry.
In generalized forwarding, instead of each router being a smart, self-contained device that runs its own routing algorithm and forwards packets, SDN turns each router/switch into a “dumb” forwarding device that just follows simple rules — while a centralized “brain” (the controller) computes those rules and pushes them out.
Core idea: separate the decision-making about how packets should be handled (the control plane) from the actual packet handling itself (the data plane), and let a remote, programmable controller manage many network devices at once.
SDN Details
- SDN Controller (Network OS):
- Maintains network state information.
- Interacts with network control applications “above” via northbound APIs.
- Interacts with network switches “below” via southbound APIs.
- Implemented as distributed system for performance, scalability, fault-tolerance, robustness
- Network-control Apps:
- “Brains” of control: implement control functions using lower-level services, APIs provided by SDN controller.
- Unbundled: can be provided by 3rd party distinct from routing vendor, or SDN controller.
Match and Action abstraction
SDN generalizes this into a “match + action” abstraction:
- Match: not just destination IP — can be any combination of header fields, from link layer through transport layer (MAC addresses, VLAN ID, IP src/dst, TCP/UDP ports, etc.)
- Action: not just “forward” — can be forward, drop, copy, modify header fields, or send to the controller
This generalized table is called a flow table (a “flow” = a set of packets defined by matching header field values).
Flow table entries also include:
- Priority — resolves conflicts when a packet matches more than one rule
- Counters — track #packets and #bytes per rule (useful for monitoring/billing/debugging)
OpenFlow: centralized controller communication protocol
OpenFlow is the standard communication protocol between switches/routers and a remote controller. The controller computes flow-table entries (based on whatever policy or algorithm it’s running) and installs them into each device’s flow table over the network.
Each OpenFlow flow table entry has three parts:
| Match | Action | Stats |
|---|---|---|
| header fields to match (ingress port, MAC src/dst, VLAN, IP src/dst, protocol, TCP/UDP ports, etc.) | forward to port(s) / drop / modify header / send to controller | packet + byte counters |
This is the elegant part: match + action can describe what a router, switch, firewall, and NAT middleboxes all do — just with different fields being matched and different actions taken:
| Device | Match on… | Action |
|---|---|---|
| Router | longest destination IP prefix | forward out a link |
| Switch (L2) | destination MAC address | forward or flood |
| Firewall | IP addresses + TCP/UDP ports | permit or deny |
| NAT | IP address + port | rewrite address/port |
Instead of needing separate proprietary boxes for each function, a single programmable “match+action” device can be configured (via software, from the controller) to behave as any of these.
Middleboxes
- Defnition
- Any intermediary device which performs some functions apart from standard functions of an IP router on the data path between a source host and desitnation host.
- Middlebox is everywhere:
- NAT, CDN, Firewalls, Caches, Load Balancers
Architectural Principles of the Internet
There cornerstone belifes exist:
- Simple connectivity
- IP protocol: only protocol in network-layer
- Intelligence and complexity at network edges