Take the match-plus-action of section 4.2.1. Let the match cover any header field from any of three layers, and let the action be anything at all. One abstraction then replaces routers, switches, firewalls and load balancers.
Words you will meet
-
Generalized forwarding generalized forwarding Simple Match on anything in the header, then do anything. Precise A match-plus-action paradigm in which the match may be made over multiple header fields from several layers, and the action may forward, drop, duplicate, load-balance or rewrite header values. introduced in ch. 4 — open in glossary — match on many fields, then do something. Not necessarily forward.
-
Flow table match-plus-action table Simple The generalised version of a forwarding table. Precise The flow table in a packet switch, generalising destination-based forwarding: each entry pairs a match over header fields with a list of actions. It is typically computed, installed and updated by a remote controller. introduced in ch. 4 — open in glossary — the generalised forwarding table. Match, counters, actions.
-
OpenFlow openflow Simple The standard that pioneered match-plus-action forwarding and remote controllers. Precise A packet-switch standard [McKeown 2008] whose flow tables pair a match over up to 12 header values — 11 fields plus the ingress port, in OpenFlow 1.0 — with a list of actions. It pioneered the match-plus-action abstraction and the notion of a remote controller, and with them software-defined networking. Later specifications raised the matchable values to 41. introduced in ch. 4 — open in glossary — the standard that pioneered the abstraction.
-
Packet switch packet switch Simple A device that takes a packet arriving on one link and sends it out on another link. Precise A device that takes a packet arriving on one of its incoming communication links and forwards that packet on one of its outgoing communication links. The two most prominent types in today's Internet are routers and link-layer switches. introduced in ch. 1 — open in glossary — the right word here, because these devices are neither routers nor switches.
-
Wildcard —
128.119.*.*matches any address starting with those 16 bits. -
Priority — which entry wins when several match.
Why this matters
Section 4.2.1 ended by noticing that the input port’s job has a shape: match on a header field, take an action. It then listed devices doing the same thing with different fields — link-layer switches, firewalls, NAT (Network Address Translation) Network Address Translation Letting a whole private network share one public IP address by rewriting addresses and ports. introduced in ch. 4 boxes.
This section takes that observation seriously. If the match can cover any header field and the action can be anything, then all of those devices are the same device with different table entries. That is the idea, and it is the data plane of software-defined networking.
Notice the vocabulary shift. The book has said router throughout this chapter, and here it switches deliberately to packet switch. A device matching on link-layer, network-layer and transport-layer fields at once is honestly neither a layer-2 switch nor a layer-3 router.
What a flow-table entry holds
Three things, not two.
- A set of header field values to match. Hardware matching is fastest in the TCAM (Ternary Content Addressable Memory) Ternary Content Addressable Memory Memory whose stored bits can be 0, 1 or don’t-care. Present an address and it returns the matching forwarding-table entry in essentially constant time, whatever the table size. introduced in ch. 4 memory of section 4.2.1 — more than a million entries are possible. A packet matching no entry is dropped, or sent to the controller for further processing.
- A set of counters, updated as packets match: how many have matched this entry, and how long since it was last updated.
- A list of zero or more actions. Forward to an output port, drop, copy to several ports, rewrite header fields. If there are several, they are performed in the order given.
| Destination-based§4.2.1, Figures 4.2 and 4.3 | Generalized§4.4, Figure 4.28 | |
|---|---|---|
| Match on | ||
| Possible actions | ||
| Layers consulted | ||
| When several entries match | ||
| What the table is called | ||
| Who fills it in |
Cells marked ⓘ have a reason behind them — click to read it.
Figures 4.2 and 4.3 against Figure 4.28. The book asks you to compare them; here they are side by side.
Match
Click any box to read what that part of the message is for.
Every field, as text
- Ingress Port — 1 bits — which port it arrived on
- Src MAC — 1 bits — link layer
- Dst MAC — 1 bits — link layer
- Eth Type — 1 bits — link layer
- VLAN ID — 1 bits — link layer
- VLAN Pri — 1 bits — link layer
- IP Src — 1 bits — network layer
- IP Dst — 1 bits — network layer
- IP Proto — 1 bits — network layer
- IP TOS — 1 bits — network layer
- TCP/UDP Src Port — 1 bits — transport layer
- TCP/UDP Dst Port — 1 bits — transport layer
Eleven header fields plus the ingress port. Read the layer labels: this abstraction deliberately reaches across three layers at once.
In plain words
Eleven header fields plus the ingress port — twelve values in OpenFlow 1.0. Later specifications raised that to 41.
Read the layer labels along the bottom. Link layer, network layer, transport layer. The book is direct about what that means:
OpenFlow’s match abstraction allows for a match to be made on selected fields from three layers of protocol headers, thus rather brazenly defying the layering principle we studied in Section 1.5.
That is not an accident or an oversight. It is the point. Forwarding on Ethernet addresses rather than IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 addresses makes the device a layer-2 switch; forwarding on IP addresses makes it a layer-3 router; matching transport ports makes it a firewall. One box, three jobs, because the abstraction refuses to respect the boundary.
Wildcards make it practical: 128.119.*.* matches any datagram whose address
begins with those 16 bits. And because wildcards make overlapping matches
routine, each entry carries a priority — when a packet matches several, the
highest-priority one wins.
Not every field can be matched, and that is deliberate
OpenFlow does not allow matching on the time-to-live field or the datagram length. Why are some fields allowed and others not?
The book’s answer is about the trade-off between functionality and complexity, and it quotes Butler Lampson [Lampson 1983]:
Do one thing at a time, and do it well. An interface should capture the minimum essentials of an abstraction. Don’t generalize; generalizations are generally wrong.
The art is providing enough functionality to do the job: implementing, configuring and managing network-layer functions that previously needed an assortment of separate devices. All that without over-burdening the abstraction with so much detail and generality that it becomes bloated and unusable.
Given OpenFlow’s success, its designers seem to have chosen well.
Action
The most important possible actions:
- Forwarding. To a particular physical output port, broadcast over all ports except the one it arrived on, or multicast over a selected set. The packet may also be encapsulated and sent to the remote controller. That controller may take some action, including installing new flow-table entries, and may return the packet for forwarding under the updated rules.
- Dropping. A flow-table entry with no action means matched packets are dropped. Silence is a decision.
- Modify-field. The values in 10 of the header fields may be rewritten before the packet is forwarded. That is all the layer 2, 3 and 4 fields in Figure 4.29, except the IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 protocol field.
Everything in this chapter, as one action
Look at that list against what you have already read:
| Action | Where you saw it |
|---|---|
| forward to one port | §4.2.1 — ordinary destination-based forwarding |
| drop | §4.3.3 — a firewall denying a datagram entry |
| rewrite header fields | §4.3.3 — NAT rewriting addresses and ports |
| copy to several ports | broadcast and multicast |
| send to the controller | §4.1 — how the table gets filled in at all |
NAT (Network Address Translation) Network Address Translation Letting a whole private network share one public IP address by rewriting addresses and ports. introduced in ch. 4 was presented in section 4.3.3 as a violation of layering that architectural purists objected to. Here the same operation is a first-class action in a standardised abstraction. Section 4.5 is where those two views are made to argue with each other.
Three examples
Drag any device to rearrange the picture. Hover a link to see its rate, delay and length.
The port numbers matter: every flow table below refers to them. They are reconstructed from the book’s three examples, which agree with each other exactly.
Read this diagram as text
- — wired link —
- — wired link —
- — wired link —
- — wired link —
- — wired link —
- — wired link —
- — wired link —
- — wired link —
- — wired link —
- — wired link —
- — wired link —
- — wired link —
Simple forwarding
Traffic from h5 or h6 destined to h3 or h4 must be forwarded s3 → s1 → s2, completely avoiding the direct link between s3 and s2.
| Switch | Match | Action |
|---|---|---|
Cells marked ⓘ have an explanation — click to read it.
Traffic from h5 or h6 to h3 or h4 must go s3 → s1 → s2, never using the direct s3–s2 link. Three switches, three tables.
Nothing here needs generalized forwarding — an ordinary router could do it. It is the baseline.
Load balancing
Datagrams from h3 to 10.1.*.* go over the direct s2–s1 link. Datagrams from
h4 to 10.1.*.* go over s2–s3, and then s3 to s1.
| Switch | Match | Action |
|---|---|---|
Cells marked ⓘ have an explanation — click to read it.
Both rows have the same destination. Only the ingress port differs — and that is the entire point.
This is the example that proves the point
The book flags it: this behaviour could not be achieved with IP’s destination-based forwarding.
Look at the two rules. The destination is 10.1.*.* in both. If that were the
only thing a switch could match on, the two rules would be indistinguishable.
One table entry, one output port, and no way to send the two hosts’ traffic
different ways.
What separates them is the ingress port, which is not a header field at all. Being able to match on “where did this arrive from” is what makes load balancing expressible, and it is exactly what section 4.2.1’s abstraction could not say.
Firewalling
s2 wants to receive, on any of its interfaces, only traffic sent from hosts attached to s3.
| Switch | Match | Action |
|---|---|---|
Cells marked ⓘ have an explanation — click to read it.
s2 will accept traffic only from hosts attached to s3. Notice what makes that true: not a rule that blocks anything.
The firewall is the third row, which is not a rule
There is no entry that blocks anything. There are two entries that permit
traffic from 10.3.*.*, and then nothing.
A packet matching no flow-table entry is dropped. So traffic from anywhere else is discarded because no rule permits it, not because a rule forbids it.
That is default-deny, and it is a strictly stronger security posture than listing what to block — you cannot forget to forbid something you never permitted. Chapter 8 returns to firewalls, and this is the shape the good ones have.
The flow table is an API (Application Programming Interface) Application Programming Interface The published interface through which one program can use another program's services. introduced in ch. 1
The book’s closing observation, and it is the one to carry into chapter 5:
The flow table is essentially an API (Application Programming Interface) Application Programming Interface The published interface through which one program can use another program's services. introduced in ch. 1 , the abstraction through which an individual packet switch’s behaviour can be programmed.
And network-wide behaviours can be programmed the same way, by configuring the tables across a collection of switches. Routing, layer-2 switching, firewalling, load balancing, virtual networks — two or more logically separate networks, each with its own forwarding behaviour, sharing one physical set of switches and links.
Section 5.5 returns to this with the controllers that compute and distribute the tables, and the protocol a switch uses to talk to its controller.
Check yourself
Check yourself
0 of 7 answered1.predictIn the load-balancing example both s2 rules have destination 10.1.*.*. What distinguishes them, and why does it matter?
2.How many values can an OpenFlow 1.0 rule match on?
3.The book says OpenFlow's match abstraction "brazenly defies the layering principle". In what way, and is it a defect?
4.predictIn the firewall example, s2 has two entries permitting traffic from 10.3.*.* and nothing else. What blocks everything else?
5.A flow-table entry has an empty action list. What happens to matching packets?
6.Why does generalized forwarding use an explicit priority rather than longest-prefix matching?
7.OpenFlow cannot match on the time-to-live field or the datagram length. Why not?
What to remember
- A flow-table entry holds three things: the match, a set of counters, and a list of zero or more actions. Zero actions means drop — silence is a decision.
- The match spans three layers, brazenly defying layering. That is the point, not a defect: it is what lets one device be a switch, a router and a firewall.
- The flow table is an API. Chapter 5 is about who calls it.