Evolution of Control

1. Per router control plane
2. Logically centralised control plane
3. Match + action abstraction
4. Software defined networking

Dataplane Programmability

In SDN, rigid legacy systems limit evolvability
Instead, use dataplane programability to support new procotols
Programming Procotion-independent Packet Processors (P4)
Language for expressing how packets are processed by the data plane of a programmable forwarding element (i.e. a network device)

P4 allows you to:
Add new protocols
Remove unused protocols (reduce complexity)
Flexible use of tables
Add diagnostics/telemetry
Rapid design cycle -> faster innovation

Devices that can be programmed:

• ASICSs : Intel (Barefoot) Tofino
• FPGA: NetFPGA, Xilinx (Alveo)
• SmartNICs: Netronome Agilio, NVIDIA BlueField v3
• General-purpose CPUs: Intel, AMD, ARM (e.g.,BMV2, P4-OVS, T4P4S DPDK, …)
• These devices let us tell them how to process packets
  

Example: in-band telemetry (INT)
Tell the switch how to handle packets
Tell it to add, e.g. SwitchID, Arrival Time, Queue Delay, Matched rules, ...
Use IP header options to add this data

Now switch 1 indicates a large queue depth, allowing you to see where the congestion has occurred

Portable Protocol-Independent Packet Processor (P4)

PISA: Protocol Independent Switch Architecture

P4${}_{16}$ Language Elements

P4 Architectures

P4${}_{16}$ has outgrown PISA
Need to target multiple programmable devices with different architectures
Architectures are a new capability in P4 to enable it to run on different devices
A P4 architectures is a model that defines the capabilities and logical view of a target's P4 processing pipeline
Each architecture has its programmable blocks, fixed functions and flow that connects these blocks
Abstract hardware details
Providers define architecture and implement compiler backends to map architectures to targets

V1Model Standard Metadata

P4${}_{16}$ Parsers

Functions that map packets into headers + metadata
Written in a state machine style
Every parser has three predefined states
Start
Accept
Reject
Other states may be added by the programmer
In each state, execute zero or more statements, then transition to another state (can be the same, loops are OK)

State transitions can be either conditional or not
Select statements can be used to branch
Similar to a switch/case statement
Often used to branch based on some bits just read
I.e. etherType == 0x800, parse as IPv4
Similar to C functions (without loops)
Can declare variables, tables, externs, etc.
Functionality defined in the apply() statement
Represent all kinds of processing expressible as DAG:
Match-action pipeline
Deparsers
Additional forms of processing

Example: Reflector

Swap source and dst MAC
Bounce the packet back on the same physical port it came in on

P4${}_{16}$ Tables

Fundamentals of the match-action pipeline
Specifies what data field to match on
Specifies list of possible actions
Optionally specify table properties: size, default action, static entries
Each table contains one or more entries
Each entry contains:
A specific key to match on
A single action to execute on match
Action data (parameters for the action, may be empty)

Match kinds are predefined
lpm: longest prefix match
exact: exact
ternary: exact but ignore some bits

Externs

Specialised libraries, differ from vendor to vendor
Allow you to use hardware for specific operations
E.g.
Stateless: hashes, random numbers, header checksums
Stateful: counters, meters, registers

P4 Meters