Mobile Communication and Internet Technologies Software Defined Networks and OpenFlow Mobile Communication and Internet Technologies Courtesy of: AT&T Tech Talks http://web.uettaxila.edu.pk/CMS/AUT2014/teMCITms/

Module Overview Motivation What is OpenFlow Deployments Conclusion

Specialized Packet Forwarding Hardware We have lost our way Routing, management, mobility management, access control, VPNs, … App App App Million of lines of source code 5400 RFCs Barrier to entry Operating System Specialized Packet Forwarding Hardware 500M gates 10Gbytes RAM Bloated Power Hungry

An industry with a “mainframe-mentality” iBGP, eBGP IPSec Authentication, Security, Access Control Multi layer multi region Software Control Router Hardware Datapath Firewall L3 VPN anycast IPV6 NAT multicast Mobile IP HELLO OSPF-TE HELLO L2 VPN RSVP-TE VLAN MPLS HELLO Many complex functions packed into the infrastructure OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, MPLS, redundant layers, … An industry with a “mainframe-mentality”

Process of innovation made worse by captive standards process Deployment Idea Standardize Wait 10 years Driven by vendors Consumers largely locked out Layer by layer innovation

New Generation Providers already Buying into It In a nutshell Driven by cost and control Started in data centers…. What New Generation Providers have been Doing Within the Datacenters Buy bare metal switches/routers Write their own control/management applications on a common platform 6 6

Change is happening in non-traditional markets Network Operating System App Operating System App Specialized Packet Forwarding Hardware Operating System App Specialized Packet Forwarding Hardware Operating System App Specialized Packet Forwarding Hardware Operating System Specialized Packet Forwarding Hardware App Operating System Specialized Packet Forwarding Hardware

The “Software-defined Network” 2. At least one good operating system Extensible, possibly open-source 3. Well-defined open API App App App Network Operating System 1. Open interface to hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware

Trend Virtualization or “Slicing” Virtualization layer Controller 1 App Controller 2 Virtualization or “Slicing” OpenFlow NOX (Network OS) Network OS App App App Windows (OS) Linux Mac OS Windows (OS) Linux Mac OS Windows (OS) Linux Mac OS Virtualization layer x86 (Computer) Computer Industry Network Industry Simple common stable hardware substrate below+ programmability + strong isolation model + competition above = Result : faster innovation 9

What is OpenFlow?

Short Story: OpenFlow is an API Control how packets are forwarded Implementable on COTS hardware Make deployed networks programmable not just configurable Makes innovation easier Result: Increased control: custom forwarding Reduced cost: API  increased competition

Ethernet Switch/Router

Control Path (Software) Data Path (Hardware)

OpenFlow Controller Control Path OpenFlow Data Path (Hardware) OpenFlow Protocol (SSL/TCP) Control Path OpenFlow Data Path (Hardware)

OpenFlow Firmware Controller PC OpenFlow Flow Table Abstraction Software Layer Flow Table MAC src dst IP Src Dst TCP sport dport Action Hardware Layer * 5.6.7.8 port 1 port 1 port 2 port 3 port 4 5.6.7.8 1.2.3.4

OpenFlow Basics Flow Table Entries Rule Action Stats Packet + byte counters Forward packet to port(s) Encapsulate and forward to controller Drop packet Send to normal processing pipeline Modify Fields Now I’ll describe the API that tries to meet these goals. Switch Port VLAN ID MAC src MAC dst Eth type IP Src IP Dst IP Prot TCP sport TCP dport + mask what fields to match 16

Examples Switching Flow Switching Firewall Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action * * 00:1f:.. * * * * * * * port6 Flow Switching Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action port3 00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6 Firewall Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Forward * * * * * * * * * 22 drop

Examples Routing VLAN Switching Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action * * * * * * 5.6.7.8 * * * port6 VLAN Switching Switch Port MAC src dst Eth type VLAN ID IP Src Dst Prot TCP sport dport Action port6, port7, port9 * * 00:1f.. * vlan1 * * * * *

OpenFlow Usage Dedicated OpenFlow Network Controller Aaron’s code PC OpenFlow Switch OpenFlow Protocol Rule Action Statistics OpenFlow Switch OpenFlow Switch Rule Action Statistics Rule Action Statistics OpenFlowSwitch.org 19 19

Network Design Decisions Forwarding logic (of course) Centralized vs. distributed control Fine vs. coarse grained rules Reactive vs. Proactive rule creation Likely more: open research area

Centralized vs Distributed Control Centralized Control Distributed Control Controller Controller OpenFlow Switch OpenFlow Switch Controller OpenFlow Switch OpenFlow Switch Controller OpenFlow Switch OpenFlow Switch

Flow Routing vs. Aggregation Both models are possible with OpenFlow Flow-Based Every flow is individually set up by controller Exact-match flow entries Flow table contains one entry per flow Good for fine grain control, e.g. campus networks Aggregated One flow entry covers large groups of flows Wildcard flow entries Flow table contains one entry per category of flows Good for large number of flows, e.g. backbone

Reactive vs. Proactive Both models are possible with OpenFlow First packet of flow triggers controller to insert flow entries Efficient use of flow table Every flow incurs small additional flow setup time If control connection lost, switch has limited utility Proactive Controller pre-populates flow table in switch Zero additional flow setup time Loss of control connection does not disrupt traffic Essentially requires aggregated (wildcard) rules

OpenFlow Application: Network Slicing Divide the production network into logical slices each slice/service controls its own packet forwarding users pick which slice controls their traffic: opt-in existing production services run in their own slice e.g., Spanning tree, OSPF/BGP Enforce strong isolation between slices actions in one slice do not affect another          Allows the (logical) testbed to mirror the production network real hardware, performance, topologies, scale, users Prototype implementation: FlowVisor very text heavy; think about a picture (what!?) "systems solution to a networking problem (this is why it's at OSDI)"

Add a Slicing Layer Between Planes Slice 2 Controller Slice 3 Controller Slice 1 Controller Slice Policies "Each slice runs its own, custom control plane process and generates its own rules" Control/Data Protocol Rules Excepts Data Plane

Network Slicing Architecture A network slice is a collection of sliced switches/routers Data plane is unmodified Packets forwarded with no performance penalty Slicing with existing ASIC Transparent slicing layer each slice believes it owns the data path enforces isolation between slices i.e., rewrites, drops rules to adhere to slice police forwards exceptions to correct slice(s)

Slicing Policies The policy specifies resource limits for each slice: Link bandwidth Maximum number of forwarding rules Topology Fraction of switch/router CPU FlowSpace: which packets does the slice control?

FlowSpace: Maps Packets to Slices "flowspace is a way of thinking about classes of packets" "each slice has forwarding control of a specific set of packets, as specified by packet header fields" "that is, all packets in a given flow are controlled by the same slice" "each flow is controlled by exactly one slice" (ignoring monitoring slices for the purpose of the talk) "in practice, flow spaces are described using ordered ACL-like rules"

Real User Traffic: Opt-In Allow users to Opt-In to services in real-time Users can delegate control of individual flows to Slices Add new FlowSpace to each slice's policy Example: "Slice 1 will handle my HTTP traffic" "Slice 2 will handle my VoIP traffic" "Slice 3 will handle everything else" Creates incentives for building high-quality services

FlowVisor Implemented on OpenFlow Server Servers Custom Control Plane Switch/ Router OpenFlow Firmware Data Path Controller FlowVisor OpenFlow Controller Network OpenFlow Protocol Stub Control Plane OpenFlow Firmware Data Plane Data Path Switch/ Router Switch/ Router

FlowVisor Message Handling OpenFlow Firmware Data Path Alice Controller Bob Cathy FlowVisor Rule Policy Check: Is this rule allowed? Policy Check: Who controls this packet? Full Line Rate Forwarding Exception Packet Packet

OpenFlow Deployments

OpenFlow has been prototyped on…. Ethernet switches HP, Cisco, NEC, Quanta, + more underway IP routers Cisco, Juniper, NEC Switching chips Broadcom, Marvell Transport switches Ciena, Fujitsu WiFi APs and WiMAX Basestations Most (all?) hardware switches now based on Open vSwitch…

Deployment: Stanford Our real, production network 15 switches, 35 APs 25+ users 1+ year of use Same physical network hosts 7 different Stanford demos

Deployments: GENI

(Public) Industry Interest Google has been a main proponent of new OpenFlow 1.1 WAN features ECMP, MPLS-label matching MPLS LDP-OpenFlow speaking router: NANOG50 NEC has announced commercial products Initially for datacenters, talking to providers Ericsson “MPLS Openflow and the Split Router Architecture: A Research Approach“ at MPLS2010

Conclusions Current networks are complicated OpenFlow is an API Interesting apps include network slicing OpenFlow has potential for Service Providers Custom control for Traffic Engineering Combined Packet/Circuit switched networks

Q A &

Assignment #6 Write Notes on the terms highlighted in Red in slides 36 and 37 Write a summary of the paper “MPLS Openflow and the Split Router Architecture: A Research Approach“ at MPLS2010