Software Defined Networking

• management plane

• control plane

• data plane

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

• Tuning the parameters of the underlying algorithms

• Has rules about which frames should go where

• Creates lookup tables from those rules

• Provides lookup tables for the data plane

• Uses lookup tables provided by the control plane

• Actually touches / forwards frames

• Management Plane: configuring link costs

• Control Plane: creating a routing table

• Data Plane: forwarding of frames according to routing table

• 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.

• 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

• Provides a layer of abstraction from the physical network

• 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

• A network in which the control plane is separate from the data plane

• A single control plane controls several forwarding devices

• The control plane is just software

• No distributed state, one central view of the network

• Common model: "one bigswitch"-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 distributed system

• 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

• OpenFlow is a protocol configuring the forwarding plane

  • runs on top of TCP/SSL

  • Protocol spoken between control plane and for-

    warding plane

• Based on Match+Action principles using tables

• => has match conditions associated with match actions…

• Switch Port

• VLAN ID

• VLAN pcp

• MAC Src

• MAC Dst

• Ether type

• IP Src

• IP Dst

• IP ToS

• IP Protocol

• L4 Scr Port

• L4 Dst Port

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 Port: *

• MAC Src: *

• MAC Dst: 00:01:ff:…

• Eth Type: *

• … (rest of the fields *)

• Action: Port 5 (destination port)…

• All fields *

• IP Dst : 1.2.0.0/16 (destination …)

• Action: Port 5 (next hop interface…)

• All fields *

• L4 Dst: 22

• Action: Drop

• => Block all ssh connection establishments…

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

• Outside: Controllers (control plane) controlling and managing/ used to configure the switch

• OpenFlow channel that connects the switch via OpenFLow Protocol with one or more controllers

• Ports connected to Flow Table Pipeline for processing of the packets…

• Group and Meter Table

• 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

• Is not a SDN itself

• 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

• 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

• Network Functoin Virtualization

• 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."

• => Allows for virtualizing many of the Network Hardware Equipment…

• (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

• "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

• One VM per NF (Network Function)

• Communication between NFs via virtual switch

• +  Strong isolation between NFs

• +  Uses traditional OS sockets

• - High load on virtual switch

• Entire NFC running directly on host system

• Communication between NFs via NF framework (e.g. DPDK), initial

  entry and last exit via virtual switch

• + No costs for virtual switch

• - NFs need to be rewritten to use NF framework

• One VM for entire NFC

• Communication between NFs via NF framework, initial entry and last exit via virtual switch

• +  Lower load on virtual switch

• +  Isolation between host OS and the NF chain inside the VM

• - NFs need to be rewritten to use NF framework

=> One virtual switch that communicates with NF framework in single VM

=> standard: one VM for each NFC -> communicaton between NF over Virtual Switch

=> No virtualization: chaining direct in Host system…

• Tradeoff between isolation and performance requirements:

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

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

• Performance requirements

• Integration of legacy NF supporting only socket interface

• Integration of NFs from different vendors

• Stronger isolation requirements for untrusted customer code

• 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

• P4 is a domain specific programming language to program data plane

  devices

• P4 allows programming switches to support entirely new protocols (e.g., NewP)

=> OpenFlow as Interface / Protocol allowing control of data plane

=> P4 to actually programm data plane…

• P4 is not a successor or a replacement of OpenFlow

• OpenFlow and P4 solve specific tasks on separate planes

• P4 can be used to implement OpenFlow-capable applications for switches

• 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

• 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

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

• p4c/bmv2

• T4P4S

• 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)

• slow, not optimized for performance

• open source, available at http://p4.elte.hu/

• compiles P4 for DPDK

• requires DPDK-compatible hardware

• decent performance (>10 Gbit/s)

• Network processor unit

• Example: Netronome Agilio SmartNIC

• purpose-built processor for packet processing

• specialized hardware accelerators (e.g. hashing, look up)

• highly parallelized architecture (>100 cores)

• supports several programming languages C,

  P4, eBPF

• up to 2 × 100 Gbit/s interfaces per network card

• Field Programmable Gate Arrays

• fully programmable NIC (down to the physical layer)

• utilizing hardware description languages such as Verilog or VHDL

• Xilinx Virtex 7 FPGA

• up to 4 × 10Gbit/s interfaces (via SFP+ transceivers)

Barefoot Tofino

• Tofino ASIC: specifically designed switching ASIC with native P4 support

• capable of up to 6.5 Tbit/s throughput (unidirectional)

• for comparison: peak traffic at biggest Internet exchange DE-CIX in Frankfurt was 6.74 Tbit/s in 2018

• up to 64 × 100 Gbit/s interfaces (via QSFP28 transceivers)

• Performance: data planes need to process millions of packets persecond : 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

• P4_14

  • unified language for all targets

  • development driven by hardware developers

• P4_16

  • concentrating P4 language on core functionalities

  • development driven by software developers (P4 becoming a more C-like programming language)

• Parser

• Checksum Verification / Ingress Match-Action

• Traffic Manager

• Checksum Update / Egress Match-Action

• Deparser

• Finite State Machine (FSM)

• Produces a parsed representation of valid headers

• Describes all supported headers

• Describes the order in which headers may appear

• No -> using different core elements leads to different switch types with different functionality…

• => allows to only include what is actually needed…

• Executed before sending a frame

• Assemble the different fields and their order in a frame

• 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

• 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

• 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

• New in P4_16

• 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

• Look relevant header & metadata fields / values

• -> compare them to lookup table

  • => if match, retrieve lookup key

• Use lookup key to look up associated action in lookup table; else default action…

• provide the action data from the lookup (data actoin is performed upon) and action code (actual action processing)

• => execute action code on action data and create new headers & metadata

• Porable Switch Architecture

• Reference architecture for P4 switches

• Separate PSA specification available on p4.org

• Architecture describes common capabilities of network switch devices

• 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

• Capabilities of the traffic manager, such as packet generation