Chair of Network Architectures and Services

School of Computation, Information, and Technology

Technical University of Munich

Advanced Computer Networking (ACN)

IN2097 – WiSe 2023–2024

Prof. Dr.-Ing. Georg Carle

Sebastian Gallenmüller, Max Helm, Benedikt Jaeger,

Marcel Kempf, Patrick Sattler, Johannes Zirngibl

Chair of Network Architectures and Services

School of Computation, Information, and Technology
Technical University of Munich
Software Defined Networking

Introduction

OpenFlow
Introduction
Core concepts
Example

NFV

P4
Motivation
P4 targets
P4 Core
P4 example: IPv4 router
Active area of research

Software Defined Networking 1

Software Defined Networking

Acknowledgements

Bibliography

Software Defined Networking 2

Software Defined Networking

Introduction

OpenFlow

NFV

P4

Acknowledgements

Bibliography

Software Defined Networking 3

Introduction
Management Plane, Control Plane, and Data Plane

Management
configure
Plane

decide
e.g. spanning e.g. spanning
tree protocol tree protocol
Control Plane
forwarding table
updates

forwarding table

forwarding table
lookups Data Plane:
per-packet
processing
incoming frame outgoing frame
forwarding

Software Defined Networking — Introduction 4

Introduction
Tasks of the Management Plane, Control Plane, and Data Plane
Management Plane:

• Allows access for administrators to the configuration of the other planes

• Tuning the parameters of the underlying algorithms

Control Plane:

• Has rules about which frames should go where

• Creates lookup tables from those rules
• Provides lookup tables for the data plane

Data Plane (also called Forwarding Plane):

• Uses lookup tables provided by the control plane

• Actually touches / forwards frames

Software Defined Networking — Introduction 5

Introduction
Tasks of the Management Plane, Control Plane, and Data Plane
Management Plane:

• Allows access for administrators to the configuration of the other planes

• Tuning the parameters of the underlying algorithms

Control Plane:

• Has rules about which frames should go where

• Creates lookup tables from those rules
• Provides lookup tables for the data plane

Data Plane (also called Forwarding Plane):

• Uses lookup tables provided by the control plane

• Actually touches / forwards frames

Example: Tasks of the different planes in a router

• Management Plane: configuring link costs

• Control Plane: creating a routing table
• Data Plane: forwarding of frames according to routing table
Software Defined Networking — Introduction 5
Introduction
Standard Telecommunication Architectures

Traditional architectures consist of three planes:

• management plane,
• control plane,
• and data plane.

What is a plane?
A plane is a group of algorithms and network protocols.
These protocols and algorithms

• process different kinds of traffic,

• have different performance requirements,
• are designed using different methodologies,
• are implemented using different programming languages,
• run on different hardware.

Software Defined Networking — Introduction 6

Introduction
Standard Telecommunication Architectures

Problems with the standard approach

Implementations

• depend heavily on hardware platform and chip vendor,

• depend on the specific vendor implementation,
• offer limited access to the source code,
• are updated rarely or slowly (cf. adoption of IPv6),
• are often changing from one vendor to another.

Software Defined Networking — Introduction 7

Introduction
SDN to the rescue

What is SDN?

• Software Defined Networking

• Provides a layer of abstraction from the physical network

How does it do that?

• Historically, devices include both, the control plane and the data plane
• SDN has one central control plane, which manages all the data planes of all the switches

Software Defined Networking — Introduction 8

Introduction
Illustration

• In your datacenter, you know your traffic flows. It is your datacenter!

• How can you optimize your traffic flows?
• VM1 to VM3 should flow via W Z Y
• VM2 to VM4 should flow via W X Y

Switch X

VM1 VM3

VM2 VM4

Switch W Switch Y
Hypervisor 1 Hypervisor 2
Switch Z

Software Defined Networking — Introduction 9

Introduction
Illustration
VM1 to VM3: W -> Z -> Y

VM2 to VM4: W -> X -> Y

Control plane

Switch X

VM1 VM3

VM2 VM4

Switch W Switch Y
Hypervisor 1 Hypervisor 2
Switch Z

Data plane

Software Defined Networking — Introduction 10

Introduction
A more formal definition

Two requirements for SDN:

• A network in which the control plane is separate from the data plane
• A single control plane controls several forwarding devices

Both have to be met

Software Defined Networking — Introduction 11

Introduction
SDN Benefits

Why the term “Software Defined”?

• The control plane is just software

Abstraction:

• No distributed state, one central view of the network

• Common model: "one big switch"-abstraction — the entire data plane behaves like a single giant switch
• No individual configuration of devices, one centrally managed control plane
• Important: View centralized, control plane itself may be implemented as a distributed system

Gain:

• Complex, distributed protocols such as the Spanning Tree Protocol (STP) are no longer necessary
• Simpler algorithms utilizing the central view (e.g., Dijkstra’s algorithm instead of STP)
• Less complexity in the control plane

Software Defined Networking — Introduction 12

Software Defined Networking

Introduction

OpenFlow
Introduction
Core concepts
Example

NFV

P4

Acknowledgements

Bibliography

Software Defined Networking 13

Introduction
What is OpenFlow?
VM1 to VM3: W -> Z -> Y

VM2 to VM4: W -> X -> Y

Openflow Control plane

• OpenFlow is a protocol configuring the forwarding
plane
• runs on top of TCP/SSL Switch X

• Protocol spoken between control plane and for-

VM1 VM3
warding plane
• Standardized by the Open Networking Founda- VM2 VM4

tion (ONF)
• Version 1.0 was released in 2009 [1]
Switch W Switch Y
• Latest version 1.6 from 2016 [2] Hypervisor 1 Hypervisor 2
Switch Z

Data plane
Software Defined Networking — OpenFlow 14
Core concepts
OpenFlow tables
Data(plane(abstraction:(Flow(table
OpenFlow is based on the match+action principle

Match Actions Counters

Bytes(+(packets
1. Forward((one(or(more(ports)
2. Drop
3. Encapsulate(and(send(to(controller
4. Header( rewrite
5. Push/pop(MPLS(label(/(VLAN(tag
6. Queues( +(bitrate(limiter((bit/s)
7. Etc..

Switch VLAN VLAN MAC MAC Eth IP IP IP IP L4 L4

Port ID pcp src dst type Src Dst ToS Prot sport dport
Slide(courtesy:(Rob(Sherwood
Figure 1: (Source: cleanslate.stanford.edu)
A.(Capone:(ECOOP(6 NetPL(2015 9
Software Defined Networking — OpenFlow 15
Core concepts
Tables examples

Switch MAC MAC Eth IP IP IP IP L4 L4 Action

Port Src Dst Type Src Dst TOS Prot Src Dst
* * 00:1f:... * * * * * * * Port 5

Table 1: Ethernet switch

Switch MAC MAC Eth IP IP IP IP L4 L4 Action

Port Src Dst Type Src Dst TOS Prot Src Dst
* * * * * 1.2.0.0/16 * * * * Port 5

Table 2: Router

Switch MAC MAC Eth IP IP IP IP L4 L4 Action

Port Src Dst Type Src Dst TOS Prot Src Dst
* * * * * * * * * 22 Drop

Table 3: Firewall

Software Defined Networking — OpenFlow 16

Core concepts
Remark about the term switch

Traditional classification

• Switch:
• Works on Layer 2
• Simple forwarding of packets
• Router:
• Works on Layer 3
• Finding out where to route packets (LPM)

In the context of SDN every "box" is considered a switch

• Clear distinction (e.g. switch, router) no longer possible as functionality is determined by software
• These boxes/switches can even be used as firewall, tunnel gateways

Software Defined Networking — OpenFlow 17

 website (https://www.opennetworking.org/). This specification covers the components and the basic
functions of the switch, and the OpenFlow switch protocol to manage an OpenFlow switch from a
remote OpenFlow controller.
Core concepts
OpenFlow switch

Controller Controller

Protocol
OpenFlow Switch
Datapath
OpenFlow OpenFlow
Channel Channel Group Meter
Control Channel Table Table

Port Port
Flow Flow Flow
Table Table Table
Port Port
Pipeline

Figure 2: OpenFlow switch (source: OpenFlow Switch Specification, ONF)

Figure 1: Main components of an OpenFlow switch. Software Defined Networking — OpenFlow 18
Core concepts
Open vSwitch

VM VM VM VM
...
vNIC vNIC vNIC vNIC vNIC
Software Switch
pNIC pNIC pNIC
Physical Switches & Crosslink Connections

Figure 3: Virtual software switches [3]

• Open vSwitch (OvS) is a (virtual) software switch

• Supports OpenFlow (considered as the de-facto standard implementation of OpenFlow)
• OvS is typically used to connect different VMs on the same host or between different hosts
• OvS can also be used to turn a server with into an OpenFlow switch

Software Defined Networking — OpenFlow 19

Example
Controller

Client 1 ctl-if Client 2

1 2

10.0.0.1 OpenFlow 10.0.0.2

switch

Rules installed on the switch

ovs-ofctl add-flow ctl-if priority=0,actions=controller

Software Defined Networking — OpenFlow 20

Example
Controller

Client 1 ctl-if Client 2

1 2

10.0.0.1 OpenFlow 10.0.0.2

switch

Rules installed on the switch

ovs-ofctl add-flow ctl-if priority=0,actions=controller

• add-flow: "OpenFlow rule" (Not a regular network flow!)

• ctl-if: Destination for this OpenFlow flow
• actions=controller: Send packets matching this rule to the controller
• priority=0: 0 is lowest priority

Software Defined Networking — OpenFlow 20

Example
Controller

Client 1 ctl-if Client 2

1 2

10.0.0.1 OpenFlow 10.0.0.2

switch

Rules installed on the switch

ovs-ofctl add-flow ctl-if priority=0,actions=controller

• Packet sent from Client 1 to Client 2

Software Defined Networking — OpenFlow 21

Example
Controller

Client 1 ctl-if Client 2

1 2

10.0.0.1 OpenFlow 10.0.0.2

switch

Rules installed on the switch

ovs-ofctl add-flow ctl-if priority=0,actions=controller

• Packet sent from Client 1 to Client 2

• Packet matches against rule Controller

Software Defined Networking — OpenFlow 21

Example
Controller

Client 1 ctl-if Client 2

1 2

10.0.0.1 OpenFlow 10.0.0.2

switch

Rules installed on the switch

ovs-ofctl add-flow ctl-if priority=0,actions=controller

• Packet sent from Client 1 to Client 2

• Packet matches against rule Controller
• Controller instructs switch to send packet to destination

Software Defined Networking — OpenFlow 21

Example
Controller

Client 1 ctl-if Client 2

1 2

10.0.0.1 OpenFlow 10.0.0.2

switch

Rules installed on the switch

ovs-ofctl add-flow ctl-if priority=0,actions=controller

• Packet sent from Client 1 to Client 2

• Packet matches against rule Controller
• Controller instructs switch to send packet to destination
• Problem: sending each packet to the controller, may create a bottleneck / overload the controller
Software Defined Networking — OpenFlow 21
Example

Controller

Client 1 ctl-if Client 2

1 2

10.0.0.1 OpenFlow 10.0.0.2

switch

Rules installed on the switch

ovs-ofctl add-flow ctl-if priority=0,actions=controller
ovs-ofctl add-flow ctl-if dl_type=0x0800,nw_dst=10.0.0.2, priority=10000,actions=output:2

Software Defined Networking — OpenFlow 21

Example
Controller

Client 1 ctl-if Client 2

1 2

10.0.0.1 OpenFlow 10.0.0.2

switch

Rules installed on the switch

ovs-ofctl add-flow ctl-if priority=0,actions=controller
ovs-ofctl add-flow ctl-if dl_type=0x0800,nw_dst=10.0.0.2, priority=10000,actions=output:2

• Controller can also install rule on switch to make forwarding more efficient
• IPv4 packets (matching ethertype 0x0800 destination address 10.0.0.2) from Client 1 get directly forwarded to Client 2

Software Defined Networking — OpenFlow 21

Example
OpenFlow in the wild

• OpenFlow is not SDN

• OpenFlow with its standardized interface enables SDN deployment
• Very successful in software switches (Open vSwitch)
• There are hardware switches with OpenFlow support
• Did not make traditional switches obsolete as initially expected
• Still many proprietary switches today

OpenFlow

• Allows programming the control plane

• Allows modifications in the data plane
• Standard supports only a limited number of protocols
• To introduce new protocols the standard must be updated
• Switches must be upgraded to handle the new standard

Software Defined Networking — OpenFlow 22

Software Defined Networking

Introduction

OpenFlow

NFV

P4

Acknowledgements

Bibliography

Software Defined Networking 23

NFV
Network Function Virtualization (NFV)

• Defined by ETSI (European Telecommunications Standards Institute)

• Telco-driven approach for networks initiated in 2012
• Definition of NFV according to ETSI: NFV is a concept "leveraging standard IT virtualisation technology to consolidate many network
equipment types onto industry standard high volume servers, switches and storage, which could be located in Datacentres, Network
Nodes and in the end user premises."

Software Defined Networking — NFV 24

NFV
NFV—simply explained

Figure 4: from https://www.slideshare.net/nearyd/nfv- for- beginners

Software Defined Networking — NFV 25

NFV
Some Terminology

• (V)NF: (Virtualized) Network Function, (virtualized) building block performing a network task
• NFC: Network Function Chaining, putting together several network functions to create more complex packet processing chains

VM 1 VM 2 VM 3
NF 1 NF 2 NF 3
Figure 5: Example of a chain of Virtual Network Functions

Software Defined Networking — NFV 26

NFV
NFV vs. SDN

• "SDN and NFV are complementary but increasingly co-dependent" [4]

• SDN: dynamically control the network
• NFV: manage and orchestrate the virtualization of resources for the provisioning of network functions and their composition into
higher-layer network services

Software Defined Networking — NFV 27

NFV
NFV architectures I

Traditional approach VM 1 VM 2 VM 3
• One VM per NF NF 1 NF 2 NF 3
• Communication between NFs via virtual switch
+ Strong isolation between NFs
+ Uses traditional OS sockets Virtual switch
- High load on virtual switch

Figure 6: Traditional VM-based NFC

Non-virtualized NFC
• Entire NFC running directly on host system
NF 1 NF 2 NF 3
• Communication between NFs via NF framework (e.g. DPDK), initial
entry and last exit via virtual switch NF framework
+ No costs for virtual switch
- NFs need to be rewritten to use NF framework Figure 7: Non-virtualized framework-based NFs

Software Defined Networking — NFV 28

NFV
NFV architectures II

Hybrid solution: virtualized NFC VM running NF framework

• One VM for entire NFC
NF 1 NF 2 NF 3
• Communication between NFs via NF framework, initial entry and last
exit via virtual switch
+ Lower load on virtual switch
Virtual switch
+ Isolation between host OS and the NF chain inside the VM
- NFs need to be rewritten to use NF framework
Figure 8: Virtualized framework-based NFs

Software Defined Networking — NFV 29

NFV
Performance of NFs

• Tradeoff between isolation and performance requirements:

• Isolation (high to low): Virtual machines, container, no virtualization
• Performance (low to high): Virtual machines, container, no virtualization

Software Defined Networking — NFV 30

NFV
Performance measurements
VM

vNIC vNIC
Performance of virtual switching solutions [3]
• Investigated 4 different setups involving physi- Switch Switch
cal/virtual pNICs/vNICs
pNIC pNIC pNIC pNIC
• CPU: Intel Xeon E3-1230 V2 CPU (3.3 GHz, base
clock)
(a) pNIC forwarding (b) pNIC to pNIC through VM
• pNIC: 10 Gbit/s Intel X540
• SW: GRML Linux kernel v3.7, Open vSwich v2.0, VM VM VM
DPDK vSwitch v0.1
• Hypervisor: qemu-kvm 1.1.2
• Worst case measurement scenario: minimum-
vNIC vNIC vNIC vNIC
sized packets 64 B (14.88 Million packets per sec-
ond (Mpps) @ 10 Gbit/s)
Switch Switch
pNIC pNIC

(c) pNIC to vNIC2 (d) vNIC to vNIC

Software Defined Networking — NFV 31

Figure 9: Investigated test setups
NFV

Table 4: Single Core Data Plane Performance Comparison

Million packets per second (Mpps) from pNIC to

Application pNIC vNIC vNIC to pNIC vNIC to vNIC

Linux bridge 1.11 0.74 0.20 0.19

IP forwarding 1.58 0.78 0.19 0.16
Open vSwitch (OvS) 1.88 0.85 0.30 0.27
DPDK vSwitch 13.51 2.45 1.10 1.00

• DPDK vSwitch is the DPDK-accelerated version of OvS

• Network IO for VMs is quite expensive

Software Defined Networking — NFV 32

NFV
Conclusion

Traditional approach Virtualized NFC Non-virtualized NFC

Performance + ++ +++
Isolation +++ ++ +
Chaining interface OS sockets Framework-based Framework-based

Table 5: Comparison between different NFC architectures

Possible reasons for choosing different architectures

• Performance requirements
• Integration of legacy NF supporting only socket interface
• Integration of NFs from different vendors
• Stronger isolation requirements for untrusted customer code

Software Defined Networking — NFV 33

Software Defined Networking

Introduction

OpenFlow

NFV

P4
Motivation
P4 targets
P4 Core
P4 example: IPv4 router
Active area of research

Acknowledgements

Bibliography

Software Defined Networking 34

Motivation
OpenFlow versus P4

Management Plane
CLI

OpenFlow
• OpenFlow allows programmability on the control plane Control Plane
• OpenFlow offers a standardized interface to configure the data plane
• OpenFlow only supports protocols known by the hardware or software
ARP IPv4
used on the data plane
OpenFlow
Data Plane
ARP IPv4

Software Defined Networking — P4 35

Motivation
OpenFlow versus P4

Management Plane
CLI
OpenFlow
• OpenFlow allows programmability on the control plane
• OpenFlow offers a standardized interface to configure the data plane Control Plane
• OpenFlow only supports protocols known by the hardware or software
ARP IPv4 NewP

E
used on the data plane
• Introducing a new protocol (e.g., NewP) fails without support from the
data plane
OpenFlow
Data Plane
ARP IPv4

Software Defined Networking — P4 35

Motivation
OpenFlow versus P4

Management Plane
OpenFlow CLI
• OpenFlow allows programmability on the control plane
• OpenFlow offers a standardized interface to configure the data plane
• OpenFlow only supports protocols known by the hardware or software
used on the data plane
Control Plane
P4 (Programming Protocol-Independent Packet Processors) ARP IPv4 NewP
• P4 is a domain specific programming language to program data plane
devices OpenFlow
• P4 allows programming switches to support entirely new protocols (e.g.,
NewP) P4 Data Plane
ARP IPv4 NewP

Software Defined Networking — P4 35

Motivation
OpenFlow versus P4

OpenFlow
• OpenFlow allows programmability on the control plane
Management Plane
• OpenFlow offers a standardized interface to configure the data plane CLI
• OpenFlow only supports protocols known by the hardware or software
used on the data plane
P4 (Programming Protocol-Independent Packet Processors)
• P4 is a domain specific programming language to program data plane
Control Plane
devices ARP IPv4 NewP
• P4 allows programming switches to support entirely new protocols (e.g.,
NewP)
OpenFlow
OpenFlow vs. P4
• P4 is not a successor or a replacement of OpenFlow P4 Data Plane
• OpenFlow and P4 solve specific tasks on separate planes
ARP IPv4 NewP
• P4 can be used to implement OpenFlow-capable applications for switches

Software Defined Networking — P4 35

Motivation
Data plane programmability

Goal: program your own data plane!

Benefits:

• Control and customization: make the device behave exactly as you want, operators can hide internal protocols
• Reliability: include only the features you need
• Efficiency: reduce energy consumption and expand scale by doing only what you need
• Update: Add new features when you want
• Telemetry: See inside the data plane
• Exclusivity: Program your own features without the need for involving a chip vendor
• Rapid Prototyping: enables fast deployment of protocols for prototyping
• Fast Development Cycles: enables software upgrades for protocols

Software Defined Networking — P4 36

Motivation
Data plane programmability

Goal: program your own data plane!

Benefits:

• Control and customization: make the device behave exactly as you want, operators can hide internal protocols
• Reliability: include only the features you need
• Efficiency: reduce energy consumption and expand scale by doing only what you need
• Update: Add new features when you want
• Telemetry: See inside the data plane
• Exclusivity: Program your own features without the need for involving a chip vendor
• Rapid Prototyping: enables fast deployment of protocols for prototyping
• Fast Development Cycles: enables software upgrades for protocols

Challenges:

• Performance: data planes need to process millions of packets per second

• Flexibility: Enable the implementation of various protocols
• Hardware independence: keep the description high-level enough

Software Defined Networking — P4 36

Motivation
Meet P4

An open source language allowing the specification of packet processing logic

Based on a Match+Action forwarding model
Multiple platforms supported:

• Software-based solution (e.g., using DPDK)

• NPUs - Network Processor Units
• FPGAs - Field Programmable Gate Arrays
• P4-specific ASICs

Software Defined Networking — P4 37

P4 targets
Software targets

p4c/bmv2
• open source, available at https://p4.org/code/
• "official" P4 reference implementation developed by p4.org
• used for teaching, testing, trying out new features
• no specific hardware required (mininet) P4TC
• slow, not optimized for performance • open source, available at https://www.p4tc.dev/
• ongoing effort to bring P4 to the Linux kernel
• based on existing Linux modules (traffic control/TC)
T4 P4 S (called tapas) • bringing P4 to end hosts
• open source, available at http://p4.elte.hu/
• compiles P4 for DPDK
• requires DPDK-compatible hardware
• decent performance (>10 Gbit/s)

Software Defined Networking — P4 38

 2x40GbE
10x10GbE

P4 targets
Network Processor Unit (NPU)
Accelerators
Arm11 Core
Crypto Load Balancer Atomic Adaptive Memory
256K L2 Cache Controller
Look-up Queue Bulk
64K I Cache (2x32bit DDR3)
64K D Cache Statistics CAM Hash

Internal Fabric 9.6Tb/s Proximity Memory

Netronome Agilio SmartNIC I/O
• purpose-built processor for packet process- 10x10GbE
Pre-Classifier
2x40GbE
ing ILKN
ILKN-LA
• specialized hardware accelerators (e.g. 48 60
Packet Processing Flow Processing
hashing, look up) Cores
Cores
2x8
• highly parallelized architecture (>100 cores) PCIe Gen3
SR-IOV Packet Modifier Traffic Manager
• supports several programming languages C,
P4, eBPF
NFP-4000 architecture [source: netronome.com]
• up to 2 × 100 Gbit/s interfaces per network NFP-4000 Flow Processor Block Diagram
card

Netronome SmartNIC [source: colfaxdirect.com]

Software Defined Networking — P4 39
P4 targets
Field Programmable Gate Array (FPGA)

NetFPGA
• fully programmable NIC (down to the physical
layer)
• utilizing hardware description languages
such as Verilog or VHDL
• Xilinx Virtex 7 FPGA
• up to 4 × 10 Gbit/s interfaces (via SFP+
transceivers)

NetFPGA Sume [source: github.com/NetFPGA]

Software Defined Networking — P4 40

P4 targets
P4-specific ASICs

Barefoot Tofino 2
• Tofino ASIC: specifically designed switching ASIC with native
P4 support
• capable of up to 12 Tbit/s throughput (unidirectional)
• for comparison: peak traffic at biggest Internet exchange DE-
CIX in Frankfurt was 15 Tbit/s in 2023a
• up to 64 × 200 Gbit/s interfaces (via QSFP56 transceivers)

a https://www.de-cix.net/en/about-de-cix/media/press-releases/europes-largest-internet-exchange-de-cix-frankfurt-sets-new-traffic-record-15-terabits-per-second,
last accessed 2023-01-03

32 / 64-port switch [source: arista.com]

Software Defined Networking — P4 41

P4 targets
Target comparison

SW NPU FPGA ASIC

Performance + ++ ++ +++
Flexibility +++ ++ ++ +
Ease of use +++ + + +
Costs 0C > 500 C > 1000 C > 10 000 C

Software Defined Networking — P4 42

P4 targets
Target comparison

SW NPU FPGA ASIC

Performance + ++ ++ +++
Flexibility +++ ++ ++ +
Ease of use +++ + + +
Costs 0C > 500 C > 1000 C > 10 000 C

Did P4 achieve its goals?

• Performance: data planes need to process millions of packets per second : accomplished ✓
• Flexibility: Enable the implementation of various protocols : accomplished ✓
• Hardware independence: keep the description high-level enough : development ongoing . . .
• Basic P4 functionality can be realized on any target
• Every target offers different additional capabilities not programmed in P4 (e.g. multicast support)
• These additional functionalities make P4 programs hardware dependent

Software Defined Networking — P4 42

P4 targets
Organization
P4 open source efforts are centralized on:

• Official website: https://p4.org

• Github: https://github.com/p4lang
P4.org Membership
P4 consortium members
Original P4 Paper Authors:

Operators/
End Users

Systems

Targets

Solutions/
Services

Academia/
Research

• Open source, evolving, domain-specific language • Membership is free: contributions are welcome
• Permissive Apache license, code on GitHub today
Copyright • – P4.org
© 2017 Independent,
set up as a California nonprofit
Software Defined Networking — P4 43
P4 Core
P4 versions
Two versions available:

• P414 , released in March, 2015

• unified language for all targets
• development driven by hardware developers
• P416 , released in May, 2017
• concentrating P4 language on core functionalities
• development driven by software developers (P4 becoming a more C-like programming language)

Figure 10: P4 logo

P4 Language Tutorial
Note: the following slides are based on the P4 tutorial from P4.org

Software Defined Networking — P4 44

V1Model Architecture
P4 Core
• Implemented on top of Bmv2’s simple_switch target
Overview

Parser Checksum Verification / Checksum Update / Deparser

Ingress Match-Action Egress Match-Action

Traffic
Manager

Figure 11: P4 model architecture

Copyright © 2017 – P4.org 4

Software Defined Networking — P4 45
 V1Model Architecture
P4 Core
• Implemented on top of Bmv2’s simple_switch target
Different switch models
Parser Checksum Verification / Checksum Update / Deparser
Ingress Match-Action Egress Match-Action

Traffic
Manager

Figure 12: P4 model architecture

Copyright © 2017 – P4.org 4

Figure 13: P4 model architecture without traffic manager

Figure 14: P4 model architecture without traffic manager and egress stages

• P4 models present the capabilities of a P4-enabled device

• Models typically reflect the different features of different P4 targets

Software Defined Networking — P4 46

P4 Core Parser
Parser

Function produces a parsed

representation that lists valid headers
Parser tasks
Function that describes all supported
• Finite State Machine (FSM)
header stacks
• Produces a parsed representation of valid headers
• Describes all supported headers
All other
• Describes packets default
the order in which headers may appear
• Undefined header types
• Undefined header stacks
• Undefined field values
Deparser tasks
• Executed before sending a frame
Complex
• Assemble parsers
the different possible
fields and their order (e.g. parser
in a frame
value sets), beyond the scope of this
tutorial
©2016 Open-NFP 57
Exampleoffrom
Abstract representation theparser
a packet p4 1.1 spec open-nfp.org]
[source:

Software Defined Networking — P4 47

P4 Core
Metadata

Tasks

• Data structures associated with every packet

• Standard metadata:
• Default metadata provided by all P4 targets for every packet
• e.g. ingress_port
• Intrinsic metadata:
• Additional target-specific metadata provided for every packet
• e.g. receive_timestamp
• User-defined metadata
• Data created by the P4 program during runtime for every packet
• e.g. new_tunnel_id

Software Defined Networking — P4 48

P4 Core
Match tables

name field match_kind match_value action action data

[0] encap ingress_port exact port_0 encapsulate_act vlantag = 123 Example table
[1] default drop

Tasks

• Each table contains one or more entries

• An entry contains a specific key to match on (field) and a single action (action) to be executed, and additional data (action data)
• The match operation supports different types (match_kind):
• exact: select the entry exactly matching match_value
• lpm: select the entry with the longest prefix matching
• ternary: select with some ignored bits e.g. match_value of 10*1 → 1011 or 1001
• P4 targets may define additional match types, e.g. range
• If no entry matches, the mandatory default entry is selected

Software Defined Networking — P4 49

P4 Core
Actions & extern objects

Tasks

• Similar to C functions without any loops or pointers

• Modification of field values and headers (add or remove)
• Besides the packet/header data, the action also may get additional data from tables
• Primitives for metering, registers, counters, hashes and random numbers

Extern objects

• New in P416
• Externs perform additional tasks which are either not written in or not supported by P4
• Architecture specific:
• Software/NPU targets: extension via programmed functions (C, Python, . . . )
• FPGA: extension via VHDL/Verilog-defined functions
• ASIC: no extension possible

Software Defined Networking — P4 50

P4 Core
Match-Action Processing

Illustration of P4 match-action process [source: p4.org]

Software Defined Networking — P4 51
P4 Core
P4 Portable Switch Architecture (PSA)

Goal:

• Reference architecture for P4 switches

• Separate PSA specification available on p4.org
• Architecture describes common capabilities of network switch devices

Common capabilities

• Metadata definitions
• Hashes and checksums (only simple hashes e.g. CRC, no cryptographic hashes such as SHA)
• Counters and meters
• Registers
• Random number generators
• Access to timestamps

Example for non-common capabilities

• Capabilities of the traffic manager, such as packet generation

Software Defined Networking — P4 52

P4 example: IPv4 router

Disclaimer

• Basic P4 example
• Essential features are missing, no ARP/ICMP/VLAN/IPv6 handling
→ do not use this router for the project ;)

Software Defined Networking — P4 53

P4 example: IPv4 router
Headers and fields definition

t y p e d e f b i t <48> macAddr_t ; bit<n> defines unsigned int of length n

t y p e d e f b i t <32> i p 4 A d d r _ t ; typedef introduces a shorter label for field declarations

header e t h e r n e t _ t {
header declares a new header. The following operations can be called on a
macAddr_t dstAddr ;
header: isValid(), setValid(), and setInvalid().
macAddr_t srcAddr ;
b i t <16> ethpersType ;
}

Software Defined Networking — P4 54

P4 example: IPv4 router
Headers and fields definition

t y p e d e f b i t <48> macAddr_t ; bit<n> defines unsigned int of length n

t y p e d e f b i t <32> i p 4 A d d r _ t ; typedef introduces a shorter label for field declarations

header e t h e r n e t _ t {
header declares a new header. The following operations can be called on a
macAddr_t dstAddr ;
header: isValid(), setValid(), and setInvalid().
macAddr_t srcAddr ;
b i t <16> ethpersType ;
What about the frame check sequence?
}

Software Defined Networking — P4 54

P4 example: IPv4 router
Headers and fields definition

t y p e d e f b i t <48> macAddr_t ; bit<n> defines unsigned int of length n

t y p e d e f b i t <32> i p 4 A d d r _ t ; typedef introduces a shorter label for field declarations

header e t h e r n e t _ t {
header declares a new header. The following operations can be called on a
macAddr_t dstAddr ;
header: isValid(), setValid(), and setInvalid().
macAddr_t srcAddr ;
b i t <16> ethpersType ;
What about the frame check sequence?
}
→ Checked and added automatically

Software Defined Networking — P4 54

P4 example: IPv4 router
Headers and fields definition

t y p e d e f b i t <48> macAddr_t ; bit<n> defines unsigned int of length n

t y p e d e f b i t <32> i p 4 A d d r _ t ; typedef introduces a shorter label for field declarations

header e t h e r n e t _ t {
header declares a new header. The following operations can be called on a
macAddr_t dstAddr ;
header: isValid(), setValid(), and setInvalid().
macAddr_t srcAddr ;
b i t <16> ethpersType ;
What about the frame check sequence?
}
→ Checked and added automatically

header i p v 4 _ t {
b i t <4> version ;
b i t <4> ihl ;
b i t <8> diffserv ; Offset 0 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

b i t <16> totalLen ; 0B Version IHL TOS Total Length

4B Identification Flags Fragment Offset
b i t <16> identification ;
8B TTL Protocol Header Checksum
b i t <16> flagsfragOffset ; 12 B Source Address
b i t <8> ttl ; 16 B Destination Address
b i t <8> protocol ; 20 B Options / Padding (optional)
b i t <16> hdrChecksum ;
ip4Addr_t srcAddr ; IPv4 header
ip4Addr_t dstAddr ;
} Software Defined Networking — P4 54
P4 example: IPv4 router
Metadata definition
/* Architecture */
s t r u c t standard_metadata_t { struct defines a unsorted collection of members
b i t <9> i n g r e s s _ p o r t ;
b i t <9> egress_spec ;
b i t <9> e g r e s s _ p o r t ;
b i t <32> clone_spec ;
b i t <32> i n s t a n c e _ t y p e ;
b i t <1> drop ;
b i t <16> r e c i r c u l a t e _ p o r t ;
b i t <32> p a c k e t _ l e n g t h ;
...
}

/ * User program * /
s t r u c t metadata {
...
}

s t r u c t headers {
ethernet_t ethernet ;
ipv4_t ipv4 ;
}
Software Defined Networking — P4 55
 P4 Parsers
P4 example: IPv4 router
16
P416 Parsers

• Parsers are functions that map packets

into headers and metadata, written in a start
state machine style
• Parsers map packets to headers and metadata
•• Every parser has three predefined states
Parsers are written as state machines
• ◦Each
start
parser has three predefined stats:
◦ accept
• start

◦ reject
• accept
• reject
•• Other
Additional states may
states may be definedbe defined
by the programmer by the
• programmer
Each state may execute statements and then transition to an-
other state
•• In each state, execute zero or more
Loops are allowed
statements, and then transition to
accept reject
another state (loops are OK)

Copyright © 2017 – P4.org 26

Software Defined Networking — P4 56
P4 example: IPv4 router
Parser definition
p a r s e r MyParser ( p a c k e t _ i n packet , MyParser
o u t headers hdr ,
i n o u t metadata meta , packet hdr
i n o u t standard_metadata_t std_meta ) {

state start { meta meta

t r a n s i t i o n parse_ethernet ;
}
std_meta std_meta
state parse_ethernet {
packet . e x t r a c t ( hdr . e t h e r n e t ) ;
t r a n s i t i o n s e l e c t ( hdr . e t h e r n e t . ethType ) {
TYPE_IPV4 : pa r s e _ i p v 4 ; / / 0x800
d e f a u l t : accept ; select works similar to case statements in
} Java/C
} select ends after successful match (default is
not executed after successful TYPE_IPV4 match)
s t a t e p a r s e_ i p v 4 {
packet . e x t r a c t ( hdr . i p v 4 ) ;
extract set header and its fields to valid
t r a n s i t i o n accept ;
}
}
Software Defined Networking — P4 57
P4 example: IPv4 router
Ingress and table definition
c o n t r o l MyIngress ( i n o u t headers hdr , A control block contains the functionality
i n o u t metadata meta , of the program
i n o u t standard_metadata_t std_meta ) {
a c t i o n drop ( ) { mark_to_drop ( ) ; } Control blocks can represent different
kinds of processing:
a c t i o n i p v 4 _ f o r w a r d ( macAddr_t dstAddr , egressSpec_t p o r t ) {
• Match-Action pipelines
standard_metadata . egress_spec = p o r t ;
hdr . e t h e r n e t . srcAddr = hdr . e t h e r n e t . dstAddr ; • Deparsers
hdr . e t h e r n e t . dstAddr = dstAddr ; • Additional forms of processing
hdr . i p v 4 . t t l = hdr . i p v 4 . t t l − 1 ; (checksums)
}

Typically headers and metadata act as

t a b l e ipv4_lpm {
interfaces between control blocks
key = { hdr . i p v 4 . dstAddr : lpm ; }
actions = { ipv4_forward ; drop ; NoAction ; }
Execution starts with apply() statement
s i z e = 1024;
d e f a u l t _ a c t i o n = NoAction ( ) ;
}

apply {
i f ( hdr . i p v 4 . i s V a l i d ( ) ) { ipv4_lpm . a p p l y ( ) ; }
}
} Software Defined Networking — P4 58
P4 example: IPv4 router
IPv4 Table example

field match_kind key action action data

[0] hdr.ipv4.dstAddr lpm 10.0.1.1/32 ipv4_forward dstAddr=00:00:00:00:01:01,
port=1
[1] hdr.ipv4.dstAddr lpm 10.0.1.2/32 drop
[2] - - - NoAction

Software Defined Networking — P4 59

P4 example: IPv4 router
Checksum verification
c o n t r o l MyVerifyChecksum ( i n o u t headers hdr , i n o u t metadata meta ) {
apply {
verify_checksum (
hdr . i p v 4 . i s V a l i d ( ) , / / check v a l i d i t y o f header
{ / / l i s t of inputs
hdr . i p v 4 . v e r s i o n ,
hdr . i p v 4 . i h l ,
hdr . i p v 4 . d i f f s e r v ,
hdr . i p v 4 . t o t a l L e n ,
hdr . i p v 4 . i d e n t i f i c a t i o n ,
hdr . i p v 4 . f l a g s ,
hdr . i p v 4 . f r a g O f f s e t ,
hdr . i p v 4 . t t l ,
hdr . i p v 4 . p r o t o c o l ,
hdr . i p v 4 . srcAddr ,
hdr . i p v 4 . dstAddr
},
hdr . i p v 4 . hdrChecksum , / / o u t p u t
HashAlgorithm . csum16 / / hash c a l c u l a t i o n
);
}
}

Software Defined Networking — P4 60

P4 example: IPv4 router
Checksum calculation
c o n t r o l MyComputeChecksum ( i n o u t headers hdr , i n o u t metadata meta ) {
apply {
update_checksum (
hdr . i p v 4 . i s V a l i d ( ) , / / check v a l i d i t y o f header
{ / / l i s t of inputs
hdr . i p v 4 . v e r s i o n ,
hdr . i p v 4 . i h l ,
hdr . i p v 4 . d i f f s e r v ,
hdr . i p v 4 . t o t a l L e n ,
hdr . i p v 4 . i d e n t i f i c a t i o n ,
hdr . i p v 4 . f l a g s ,
hdr . i p v 4 . f r a g O f f s e t ,
hdr . i p v 4 . t t l ,
hdr . i p v 4 . p r o t o c o l ,
hdr . i p v 4 . srcAddr ,
hdr . i p v 4 . dstAddr
},
hdr . i p v 4 . hdrChecksum , / / o u t p u t
HashAlgorithm . csum16 / / hash c a l c u l a t i o n
);
}
}

Software Defined Networking — P4 61

P4 example: IPv4 router
Egress, deparser and switch definition
c o n t r o l MyEgress ( i n o u t headers hdr ,
i n o u t metadata meta ,
i n o u t standard_metadata_t std_meta ) {
apply { }
}

/ / no e x p l i c i t deparser o b j e c t => c o n t r o l
c o n t r o l MyDeparser ( p a ck e t_ o u t packet , i n headers hdr ) {
apply {
packet . e m i t ( hdr . e t h e r n e t ) ;
packet . e m i t ( hdr . i p v 4 ) ;
}
}

Router (
MyParser ( ) ,
MyVerifyChecksum ( ) ,
MyIngress ( ) ,
MyEgress ( ) ,
MyComputeChecksum ( ) ,
MyDeparser ( )
) main ;

Software Defined Networking — P4 62

Active area of research

P4, like OpenFlow, has attracted a lot of researchers

• Extension of the P4 language itself

• Proposition of new platforms supporting P4
• New protocols and services on top of P4
• Other open programming languages for common network functionalities (e.g., packet scheduling)
• ...

Theses offered at the chair

• P4 benchmarking
• P4 extensions
• ...

Software Defined Networking — P4 63

Software Defined Networking

Introduction

OpenFlow

NFV

P4

Acknowledgements

Bibliography

Software Defined Networking 64

Acknowledgements

• Slides partially based on work by Cornelius Diekmann

Software Defined Networking — Acknowledgements 65

Software Defined Networking

Introduction

OpenFlow

NFV

P4

Acknowledgements

Bibliography

Software Defined Networking 66

Software Defined Networking

[1] O. N. Foundation, “Openflow switch specification, version 1.0.0,”, 2009.

[2] O. N. Foundation, “Openflow switch specification, version 1.6,”, 2016.

[3] P. Emmerich, D. Raumer, S. Gallenmüller, F. Wohlfart, and G. Carle, “Throughput and Latency of Virtual Switching with Open vSwitch:
A Quantitative Analysis,” in Journal of Network and Systems Management, Jul. 2017. DOI: 10.1007/s10922-017-9417-0.

[4] ESI, Network function virtualisation, last accessed: 2019-11-24, 2012. [Online]. Available: https://www.etsi.org/technologies/nfv.

Software Defined Networking 67