Future Internet Revisiting the Internet architecture? Research @ INET Stefan Schmid 1 The “Internet” r Goal: m Better use of computing power m connect expensive machines at unis and research labs r Rumors: m Arpanet for robust communication 2 Internet design goals (in decreasing order of importance) - Connect existing networks - Survivability - Support multiple types of services - Must accommodate a variety of networks - Allow distributed management - Allow host attachment with a low level of effort - Be cost effective - Allow resource accountability 3 The “Internet”: What it is r Social phenomena m Cyperspace m Changing/redefining communication • Human to human • Human to computer r Business impact m Changing/redefining processes r A man-made artifact m Well defined (in principle) What makes the Internet so sexy - Applications can be deployed by anybody that is connected to the Internet (Fundamentally different to the Telephone world) - Multi-service network: Everything over the Internet 5 The “Future Internet”? - Information and Media Society - Everyone generates content - Sensors and cameras everywhere - New distribution channels - Challenges - Verification - Fusion/filtering of information - Situation adaptation - Incentives, trust, privacy 6 Today’s Internet: Out of Shape! Data plane Control plane Picture due to Rui Aguilar Especially control plane not well structured (“fat waist?”) Redesign needed? 7 Today’s Internet: Architectural limits - Trust assumptions - Internet assumes cooperation - Competition - Original Internet assumed no commercial considerations - Edge diversity - Original Internet is host-centric - Ignores mobility, sensors, ... - Network services - Original Internet exposes limited information - Limits new services - Limits network management - Almost no changes in the network core - Designed to be a open, cooperating system - Focus on data plane 8 Why rethink the Internet architecture Reliability and availability E-Commerce increasingly depends on fragile Internet Debuggability Security Known vulnerabilities lurking in the Internet (prevent DoS?) Addressing security has a significant cost Scale & diversity Cyberspace (everything is networked) Support for new applications/services Mobility / Quality of service High speed connections to the home Economics Cost-effectively Business models 9 Rethinking the Internet architecture Explore alternative architectures Approach Incremental • Apply point-solutions to the current architecture Clean slate design (CSD) • Start from scratch Advantage CSD No limitations: enables rethinking of the network and service architecture Architecture not intrinsic New types of experiments are possible 10 How to get there? How to determine that one has a good new architecture? Paperware? No Built, evaluated, deployed? Yes Intellectual challenge: uncover otherwise ignored system aspects Approach: Research how to build/operate an experimental facility Research into new architectures Benefit: Go beyond point solutions 11 Clean slate design: Drivers - Technical - Virtualization techniques - Cloud computing / networking - Significant computational resources in the network - Fast packet forwarding hardware, e.g., OpenFlow - Starting points - PlanetLab / OneLab - Geant2/Internet2 - Emulab - Vini - … 12 Future Internet: Sample initiatives and projects EU IST FP7 Future CNGI Project (China) Internet projects http://www.future- internet.eu/activities/fp7- G-LAB funded by BMBF projects.html (Germany) Future Internet network design – FIND http://find.isi.edu/ AKARI Project (Japan) ANR (France) it839/u-it839 (Korea) Clean Slate Program (Stanford University) Groupe de Reflexion Internet du Futur (France) Super Janet funded by EPSRC (UK) Internet del Futuro (SP) NICTA (Australia) 13 OpenFlow: Flow-based Networking An exciting new technology for separating hardware and software • Incremental for data plane • CSD for control plane Quick 101 ControllerExecute packet_in OpenFlowevent handler program Default: forward Install rule; to controller forward packet Host A Host B Packet Switch 1 Switch 2 Flow Table Rule 1 Match Actions Counters Rule 2 Dst: Host B Fwd: Switch 2 pkts / bytes Rule N 15 Why ? Classical Switch: Cisco 3548XL 16 Why ? Control software (Management, STP, Basic VTP, etc. ) Control Hardware: Embedded PC Dataplane: Interfaces, TCAM, Switch fabric Classical Switch: A closed box Cisco 3548XL 17 Why ? r Operator says: Cisco's answer: But I need Buy one of these! extended VTP (VLAN trunk protocol) / a 3rd spanport etc. ! SPAN: switched port analyzer (port mirror) 18 Why ? r Operator says: Cisco's answer: I need something We don't better than STP for my have that! datacenter... 19 Why ? r On a more serious note: m Closed HW/SW hurts innovation m Researchers can't try their ideas at scale m Data center ops can't differentiate by building customized network 20 OpenFlow – An enabler for open control of the network Local header Network forwarding Control Generic decision per concept of packet: per flow A flow of switching today consists of OpenFlow Switch 100s of Network Forwarding Table packets Control Calculation Secure sw Channel Packet Forwarding Flow Traditional Engine hw OpenFlow Table Switch Switch r OpenFlow moves control path in each switch/router (middlebox) to an external controller, which makes policy decisions at the flow level (flow is defined by Layer 2, Layer 3 and/or Layer 4 header fields). r With OpenFlow, each switch speaks a separate control protocol with an external controller over TCP+SSL 21 Example service using OpenFlow Per-flow policy and QoS on demand - Interface between the OpenFlow network and the client enables, e.g., on demand - Constraints on route - Temporary upgrade in service/QoS OpenFlow devices QoSQoS /privacyboost: Increasecontraints bandwidth: for this.Delay specific < 10ms flow. .Bandwidth > 1Mbps .Not through region X Controller 22 OpenFlow usage – Simple virtualization. Dedicated OpenFlow network. Controller ’ Peter s code ’ OpenFlowPeter sSwitch Rule PC Decision? OpenFlow Protocol ’ ’ OpenFlowPeter Switchs Rule OpenFlowPeter Switchs Rule 23 OpenFlow is already supported on routers/switches. Juniper MX-series NEC IP8800 WiMax (NEC) HP Procurve 5400 Cisco Catalyst 6k PC Engines Quanta LB4G 24 Software-Defined Networking (SDN) Third-party control program Control Control Control Control 25 An OpenFlow based Router Taking advantage of + OpenSource Routing Software + Inexpensive Switch Hardware 26 OpenFlow based router: FIBIUM. Evaluation of open-source routers. Levers and current situation Our Approach . ISPs spend significant annual . Understand if low cost switches with CAPEX for routers etc. open-source software can be suitable replacement for high-cost . Currently a quasi-monopoly vendor market for backbone routers. routers and routers in huge data . Build and evaluate prototype router centers. using low-cost components and open-source software. Modularization/standardization of router components/open-source software may open the market . Similar to Linux . Industry standards for blade servers The OpenFlow might be a low cost, flexible alternative 27 OpenFlow based router: FIBIUM. Today’s inflexible routers. Current IP routers Observations . Proprietary software . Carrier-grade open-source based routers, e.g., Vyatta, IPInfusion, Quagga . Limited features customization . High-performance and inexpensive layer- . No access to datapath 3 switches with OpenFlow support, e.g. HP, NEC, Cisco . Optimized but non- programmable hardware 28 OpenFlow based router: FIBIUM. Divide and conquer. Principles Observations . Decouple routing and datapath . Current switches have sufficient datapath performance . Combine inexpensive OpenFlow-enabled switch with . Switch control logic is limited open-source routing software . Current commodity hardware has on commodity hardware better performance than embedded micro-processor on switch 29 Exploiting Zipf’s Law 30 Cache&Aggregate Bottleneck: : Aggregate smart Exploit locality: Details: 31 OpenFlow based router: FIBIUM. From concept to reality. FIBIUM RouteVisor . Leverages OpenFlow interface of switch: . Ensures that switch and PC combination . RouteVisor programs the switch appears as a router to the outside world . Route cache management ensures . Interface between route control logic good fast path performance despite on PC and switch limited switch control logic . Collects traffic statistics from switch . Slow path handled by PC and updates data path on switch 32 OpenFlow based router: FIBIUM. Prototype. Test lab Performance evaluation . Test: 2 HP switches, commercial . Control plane: 100K BGP updates per routers (Cisco and Juniper) and minute Linux routers . Communication channel between PC and switch: . RouteVisor tasks: . Traffic statistics: 100K per second . Switch configuration . Switch data path updates: 1000 . Handle OSPF and BGP modifications per second messages . Route Cache management 33 Lessons learned - Open interface == new opportunities - Flexibility of software wins over closed systems - Example: FIBIUM - Control: Open source routing software - Data path: Commodity switches Case study: Locating performance problems aided by network virtualization 35 Network debugging: Motivation How do you test an update to the configuration or software of your system? testbed simulation ✓may be more accurate ๏ but user behavior? ✓scalable ✓ ๏ expensive to run cheap ๏ on large scale? ๏ accuracy? ๏ longtime? Problem: bugs may happen rarely, non-deterministically, based on external events (Heisenbugs), … 36 Network