Building Virtual Networks for Experimentation and Profit Nick Feamster, Georgia Tech Andy Bavier, Lixin Gao, Mark Huang, Murtaza Motiwala, Jennifer Rexford, Larry Peterson, Yaping Zhu
Original Internet Design Goals • • Interconnection/Multiplexing (packet switching) Resilience/Survivability (fate sharing) Heterogeneity Distributed management Decreasing Cost effectiveness Priority Ease of attachment Accountability 2
Internet Faces New Demands • High availability and performance – Path diversity, low-latency paths, fast reaction to failures, convergence… • Security guarantees – Defense against unwanted traffic • Manageability – Fault detection and localization • Scaling • Mobility 3
Design Goal Redux “…some of the most significant problems with the Internet today relate to lack of sufficient tools for distributed management, especially in the area of routing. ” —Dave Clark, The Design Philosophy of the DARPA Internet Protocols • Human costs, operational expenditure dominate – The network must provide support for manageability “Dr Cerf admits that with hindsight, there are two things he regrets not including: authentication, to ensure that internet packets really do come from where they claim to have originated, and support for mobile devices. ” ---The Economist, June 2006 • Accountability increasingly important – Mobility, security, etc. to the forefront 4
New Protocols to the Rescue • Addressing: IPv 6, 8+8, HIP, NIRA • Security: Secure BGP (S-BGP), so. BGP, SPV • Routing: HLP, RCP, Compact/Valiant Routing • Naming: DOA • Unwanted traffic: Capabilities, SANE, Do. SResistant Internet Archictecture, 5
These Solutions Face Two Hurdles Deployment Dilemma • Deployment demonstrates feasibility • Demonstrating feasibility requires deployment Coordination Constraint • Benefits only realized when large fraction of networks deploy • No single network wants to deploy first 6
Network Virtualization: Characteristics Sharing • Multiple logical routers on a single platform • Resource isolation in CPU, memory, bandwidth, forwarding tables, … Customizability • Customizable routing and forwarding software • General-purpose CPUs for the control plane • Network processors and FPGAs for data plane 7
Two Hurdles Deployment Dilemma • Deployment demonstrates feasibility • Demonstrating feasibility requires deployment VINI: Realistic and controlled network experimentation. Coordination Constraint • Benefits only realized when large fraction of networks deploy • No single network wants to deploy first Cabo: “Concurrent Architectures are Better than One” 8
VINI Overview Bridge the gap between “lab experiments” and live experiments at scale. ? VINI Emulation Simulation • • • Small-scale experiment Live deployment Runs real routing software Exposes realistic network conditions Gives control over network events Carries traffic on behalf of real users Is shared among many experiments 9
Goal: Control and Realism • Control Topology Arbitrary, emulated Actual network Traffic Synthetic or traces Real clients, servers Network Events Inject faults, anomalies Observed in operational network – Reproduce results – Methodically change or relax constraints • Realism – Long-running services attract real users – Connectivity to real Internet – Forward high traffic volumes (Gb/s) – Handle unexpected events 10
VINI: Overview • VINI characteristics – – Fixed, shared infrastructure Flexible network topology Expose/inject network events External connectivity and routing adjacencies • PL-VINI: prototype on Planet. Lab • Preliminary Experiments • Ongoing work 11
Fixed Physical Infrastructure 12
Shared By Many Parties 13
Supports Arbitrary Virtual Topologies 14
Supports Controlled Link Failures 15
Carry Traffic for Real End Users c s 16
Participate in Internet Routing BGP c BGP s BGP 17
Why Is This Difficult? • Creation of virtual nodes – Sharing of resources – Creating the appearance of multiple interfaces – Arbitrary software • Creation of virtual links – Expose underlying failures of links – Controlled link failures – Arbitrary forwarding paradigms • Embedding virtual topologies – Support for simultaneous virtual experiments – Must map onto available resources, account, etc. 18
PL-VINI: Prototype on Planet. Lab • First experiment: Internet In A Slice – XORP open-source routing protocol suite – Click modular router • Expose issues that VINI must address – Unmodified routing (and other) software on a virtual topology – Forwarding packets at line speed – Illusion of dedicated hardware – Injection of faults and other events 19
PL-VINI: Prototype on Planet. Lab • Planet. Lab: testbed for planetary-scale services • Simultaneous experiments in separate VMs – Each has “root” in its own VM, can customize • Can reserve CPU, network capacity per VM Node Mgr Local Admin VM 1 VM 2 … VMn Planet. Lab node Virtual Machine Monitor (VMM) (Linux++) 20
Internet In A Slice XORP • Run OSPF • Configure FIB Click • FIB • Tunnels • Inject faults Open. VPN & NAT • Connect clients and servers 21
XORP: Control Plane XORP (routing protocols) • BGP, OSPF, RIP, PIMSM, IGMP/MLD • Goal: run real routing protocols on virtual network topologies 22
User-Mode Linux: Environment UML XORP (routing protocols) eth 0 eth 1 eth 2 eth 3 • Planet. Lab limitation: – Slice cannot create new interfaces • Run routing software in UML environment • Create virtual network interfaces in UML • Challenge: Map these interfaces to the right tunnels 23
Click: Data Plane • Performance UML XORP – Avoid UML overhead – Move to kernel, FPGA (routing protocols) eth 0 eth 1 eth 2 • Interfaces tunnels eth 3 Control Data Packet Forward Engine Click Uml. Switch element Tunnel table – Click UDP tunnels correspond to UML network interfaces • Filters – “Fail a link” by blocking packets at tunnel Filters 24
Recent Developments: Independence from IP New Routers XORP and Protocols (routing protocols) eth 0 eth 1 eth 2 UML Forwarding cannot depend on IP eth 3 Control Data Packet Forward Engine Uml. Switch element • Solution: Forwarding should depend on MAC addresses in UML Tunnel table Click 25
Demonstration planetlab 6. csail. mit. edu planetlab 1. csail. mit. edu planetlab 4. csail. mit. edu 1 2 1 3 planetlab 3. csail. mit. edu 26
Experiments • • IGP convergence: data and control plane RON and overlay experiments i. BGP convergence Network troubleshooting 27
Intra-domain Route Changes s 856 2095 700 260 1295 c 639 366 548 902 1893 233 587 846 1176 28
Ping During Link Failure Routes converging Link down Link up 29
Close-Up of TCP Transfer PL-VINI enables a user-space virtual network to behave like a real network on Planet. Lab Slow start Retransmit lost packet 30
Attracting Real Users • Could the experiment have been run in Emulab? – Maybe, though interconnection with real Internet could provide some advantages – “Turning the dials” between realism and contro • Goal: Operate our own virtual network – Carrying traffic for actual users – We can tinker with routing protocols 31
Two Hurdles Deployment Dilemma • Deployment demonstrates feasibility • Demonstrating feasibility requires deployment Coordination Constraint • Benefits only realized when large fraction of networks deploy • No single network wants to deploy first 32
Overcoming the Coordination Constraint • Key problem: Federation – No Internet Service Provider has control over an entire end-to-end path – This makes deployment, troubleshooting, accountability, etc. very dificult • Idea: Make the infrastructure that supports the testbed the architecture itself – Separate providers of infrastructure and service 33
Concurrent Architectures are Better than One (“Cabo”) • Infrastructure: physical infrastructure needed to build networks • Service: “slices” of physical infrastructure from one or more providers The same entity may sometimes play these two roles. 34
End-to-End Services • Multi-provider VPNs • Paths with end-to-end performance guarantees Today Competing ISPs with different goals must coordinate Cabo Single service provider controls end-to-end path 35
End-to-End Services • Today: Deployment logjam – Deployment requires consensus and coordination • Instead: Adopt pluralist approach – Determined service provider leases infrastructure and deploys technology end-to-end More Security More Complete Reachability Online Banking Web Surfing Example Routing Secure routing protocol (e. g. , S-BGP) Lowest common denominator Addressing Self-certifying addresses (optimized for persistence) Dynamic addresses (optimized for convenience) 36
Application-Specific Networks • Today: Optimize a single set of protocols • Instead: Parallel deployment – Run multiple networks, each catered to specific applications Faster Convergence Better Scalability Example Internal BGP Link-State Protocols Dissemination Hierarchical, incremental Flooding Computation Shortest Paths BGP-style decision process 37
Embedding • Given: virtual network and physical network – Topology, constraints, etc. • Problem: find the appropriate mapping onto available physical resources (nodes and edges) • Many possible formulations – Specific nodes mapping to certain physical nodes – Generic requirements: “three diverse paths from SF to LA with 100 MBps throughput” – Traffic awareness, dynamic remapping, etc. – On-the-fly creation of links in the substrate 38
Accounting and Provisioning • Problem: Brokering of physical infrastructure – Discovery: Discovering physical infrastructure • Autodiscovery of components and topology • Decision elements that configure components – Provisioning: Creating virtual networks • Requests to decision elements (initially out of band), which name virtual network components • Turner et al. , Substrate Control Metanet – Creation: Instantiating virtual networks 39
Parallel Deployment: Questions • Guaranteeing global reachability – Do we need an end-to-end global reachability service? • Proliferation of protocols and architectures – Is “low barrier to entry” a good thing for an architecture? • Security – Should parallel deployment imply isolation? – If so, how to implement it? 40
Economic Refactoring • Infrastructure providers: maintain physical infrastructure needed to build networks • Service providers: lease “slices” of physical infrastructure from one or more providers 41
Examples in Communications Networks • Packet Fabric: share routers at exchange points • FON: resells users’ wireless Internet connectivity Broker • Infrastructure providers: Buy upstream connectivity, broker access through wireless • Nomads: Users who connect to access points • Service provider: FON as broker 42
Economic Refactoring: Challenges Need to understand whether this refactoring would occur • Being a service provider: a great deal – Opportunity to add value by creating new services • Infrastructure providers – Can this enterprise be profitable? • Who will become infrastructure providers? http: //www. cc. gatech. edu/~feamster/papers/cabo-tr. pdf 43
Summary • Internet faces stronger demands from users – Not necessarily designed for those challenges – Difficult to deploy fundamentally new fixes • Virtualization: help us move beyond paper design – Testbed – Architectural foundation • Applications and Opportunities – Simultaneous operation – Substrate and interface 44
45
Can Other Industries Offer Clues? • Infrastructure providers: Airports • Infrastructure: Gates, “hands and eyes”, etc. • Service providers: Airlines BOS ORD SFO ATL 46
Скачать презентацию Building Virtual Networks for Experimentation and Profit Nick
19c4a86f679969e7506bbb8dd8fadfd6.ppt