VINI Virtual Network Infrastructure Jennifer Rexford Princeton University

  • Slides: 40
Download presentation
VINI: Virtual Network Infrastructure Jennifer Rexford Princeton University http: //www. cs. princeton. edu/~jrex 1

VINI: Virtual Network Infrastructure Jennifer Rexford Princeton University http: //www. cs. princeton. edu/~jrex 1

The Internet: A Remarkable Story • Tremendous success – From research experiment to global

The Internet: A Remarkable Story • Tremendous success – From research experiment to global communications infrastructure • The brilliance of under-specifying – Best-effort packet delivery service – Key functionality at programmable end hosts • Enabled massive growth and innovation – Ease of adding hosts and link technologies – Ease of adding services (Web, P 2 P, Vo. IP, …) • But, change is easy only at the edge… 2

Rethinking the Network Architecture • But, the Internet is showing signs of age –

Rethinking the Network Architecture • But, the Internet is showing signs of age – Security, mobility, availability, manageability, … • Challenges rooted in early design decisions – Weak notion of identity, tying address & location – Not just a matter of redesigning a single protocol • Revisit definition and placement of function – What are the types of nodes in the system? – What are their powers and limitations? – What information do they exchange? 3

Hurdle #1: Deployment Dilemma • An unfortunate catch-22 – Must deploy an idea to

Hurdle #1: Deployment Dilemma • An unfortunate catch-22 – Must deploy an idea to demonstrate feasibility – Can’t get an undemonstrated idea deployed • A corollary: the testbed dilemma – Production network: real users, but can’t change – Research testbed: easy changes, but no users • Bad for the research community – Good ideas sit on the shelf – Promising ideas do not grow up into good ones 4

Hurdle #2: Too Many Design Goals • Many different system-engineering goals – Scalability, reliability,

Hurdle #2: Too Many Design Goals • Many different system-engineering goals – Scalability, reliability, security, privacy, robustness, performance guarantees, … – Perhaps we cannot satisfy all of them at once • Applications have different priorities – Online banking: security – Web surfing: privacy, high throughput – Voice and gaming: low delay and loss • Compromise solution isn’t good for anyone 5

Hurdle #3: Coordination Constraint • Difficult to deploy end-to-end services –Benefits only when most

Hurdle #3: Coordination Constraint • Difficult to deploy end-to-end services –Benefits only when most networks deploy –No single network wants to deploy first • Many deployment failures –Qo. S, IP multicast, secure routing, IPv 6, … –Despite solving real, pressing problems • Increasing commoditization of ISPs 1 sender 2 3 receiver 6

Virtualization to the Rescue • Multiple customized architectures in parallel – Multiple logical routers

Virtualization to the Rescue • Multiple customized architectures in parallel – Multiple logical routers on a single platform – Isolation of resources, like CPU and bandwidth – Programmability for customizing each “slice” 7

Overcoming the Hurdles • Deployment Dilemma – Run multiple experimental networks in parallel –

Overcoming the Hurdles • Deployment Dilemma – Run multiple experimental networks in parallel – Some are mature, offering services to users – Isolated from others that are works in progress • Too Many Design Goals – Run multiple operational networks in parallel – Customized to certain applications and users • Coordination Constraint – Run multiple end-to-end services in parallel – Over equipment owned by different parties 8

Three Projects: GENI, VINI, CABO • Global Environment for Network Innovations – Large initiative

Three Projects: GENI, VINI, CABO • Global Environment for Network Innovations – Large initiative for a shared experimental facility – Jointly between NSF CISE division & community – Distributed systems, wireless, optics, backbone • VIrtual Network Infrastructure – Baby step toward the design of GENI – Systems research on network virtualization • Concurrent Architectures Better than One – Clean-slate architecture based on virtualization – Economic refactoring for end-to-end services See http: //www. geni. net and http: //www. vini-veritas. net 9

VINI: VIrtual Network Infrastructure 10

VINI: VIrtual Network Infrastructure 10

VINI Offers “Controlled Realism” Arbitrary, emulated Actual network Topology Synthetic or traces Real clients,

VINI Offers “Controlled Realism” Arbitrary, emulated Actual network Topology Synthetic or traces Real clients, servers Traffic Inject faults, anomalies Observed in operational network Network Events • Start with a controlled experiment • Relax constraints, study effects • Result: an operational virtual network that’s – Feasible – Valuable – Robust – Scalable, etc. 11

Fixed Infrastructure Deployed VINI nodes in National Lambda Rail and Abilene, and Po. Ps

Fixed Infrastructure Deployed VINI nodes in National Lambda Rail and Abilene, and Po. Ps in Seattle and Virginia 12

Shared Infrastructure Experiments given illusion of dedicated hardware 13

Shared Infrastructure Experiments given illusion of dedicated hardware 13

Flexible Topology VINI supports arbitrary virtual topologies 14

Flexible Topology VINI supports arbitrary virtual topologies 14

Network Events VINI exposes, can inject network failures 15

Network Events VINI exposes, can inject network failures 15

External Connectivity c s Experiments can carry traffic for real end-users 16

External Connectivity c s Experiments can carry traffic for real end-users 16

External Routing Adjacencies BGP c BGP s BGP Experiments can participate in Internet routing

External Routing Adjacencies BGP c BGP s BGP Experiments can participate in Internet routing 17

VINI Platform Design 18

VINI Platform Design 18

Virtualizingthe Computer • Starting with the Planet. Lab software – Each experiment has its

Virtualizingthe Computer • Starting with the Planet. Lab software – Each experiment has its own virtual machine – Each has “root” in its own VM, can customize – Reserve processing resources per VM Node Mgr Local Admin VM 1 VM 2 … VM n Virtual Machine Monitor (VMM) (Linux++) Planet. Lab node 19

Creating the Virtual Topology XORP (routing protocols) • Goal: real routing protocols on virtual

Creating the Virtual Topology XORP (routing protocols) • Goal: real routing protocols on virtual network topologies • Various routing protocols (BGP, OSPF, RIP, IP multicast) • Run unmodified routing software in a virtual machine VM 20

Virtual Network Abstraction • Planet. Lab limitation: User space XORP (routing protocols) eth 0

Virtual Network Abstraction • Planet. Lab limitation: User space XORP (routing protocols) eth 0 eth 1 eth 2 – Does not virtualize the underlying network • For each VM we want eth 3 Control Data FIB – Interfaces, bound to tunnels to other nodes – Networking stack (e. g. , forwarding table) – Packet forwarding in OS • Across VMs we want tunnels OS – Independent topologies – Resource isolation 21

Network Name Spaces (Net. NS) • Net. NS extension to Linux – Virtualizes the

Network Name Spaces (Net. NS) • Net. NS extension to Linux – Virtualizes the network stack – Each network stack bound to user process(es) • Provides us with – Separate forwarding table (FIB) – Separate interfaces • But, a few challenges remain – Connecting interfaces to tunnels – Supporting non-IP protocols – Providing isolation between virtual nodes 22

Connecting Interfaces to Tunnels User space XORP (routing protocols) eth 0 eth 1 eth

Connecting Interfaces to Tunnels User space XORP (routing protocols) eth 0 eth 1 eth 2 eth 3 • Ethernet switch – Linux bridge module – Connects all interfaces – And all tunnels • Short bridge FIB etun 1 etun 2 – No MAC learning – No forwarding look-up – No frame header copying etun 3 Short Bridge • EGRE tunnels OS – Carry Ethernet frames – Support non-IP protocols 23

Isolation Between Virtual Networks XORP (routing protocols) eth 0 eth 1 eth 2 eth

Isolation Between Virtual Networks XORP (routing protocols) eth 0 eth 1 eth 2 eth 3 User • Virtual host (user space) space – Experimenter’s software – Protocols, applications • Virtual host (OS) FIB etun 1 etun 2 etun 3 OS – Forwarding tables – Virtual Ethernet interfaces • Shared substrate (OS) Short Bridge – Tunnels between nodes – Enforcing rate limits OS 24

Ongoing Work on Packet Forwarding • Tension between three goals – High-speed packet forwarding

Ongoing Work on Packet Forwarding • Tension between three goals – High-speed packet forwarding – Customization of the data plane – Sharing of the data plane • Step #1: Greater flexibility – Customized data planes in the kernel – Virtualizing Click to support different virtual hosts • Step #2: Greater speed – Customized data planes in an FPGA – Virtualizing the Net. FPGA board from Stanford 25

Example Experiment on VINI 26

Example Experiment on VINI 26

Intra-domain Route Changes s 856 2095 700 260 1295 c 639 366 548 902

Intra-domain Route Changes s 856 2095 700 260 1295 c 639 366 548 902 1893 233 587 846 1176 Watch OSPF route convergence on Abilene 27

Ping During Link Failure Link down Link up Routes converging Abilene RTT: 73 ms

Ping During Link Failure Link down Link up Routes converging Abilene RTT: 73 ms 28

TCP Throughput Link down Link up Zoom in 29

TCP Throughput Link down Link up Zoom in 29

Arriving TCP Packets VINI enables Slow start a virtual network to behave like a

Arriving TCP Packets VINI enables Slow start a virtual network to behave like a real network Retransmit lost packet 30

Other Example VINI Experiments • Scaling Ethernet to a large enterprise • Routing-protocol support

Other Example VINI Experiments • Scaling Ethernet to a large enterprise • Routing-protocol support for mobile hosts • Network-layer support for overlay services • Piggybacking diagnostic data on packets • <Insert your prototype system here> • Multiple solutions to multiple problems… 31

Where does all this experimentation lead us? 32

Where does all this experimentation lead us? 32

The Case for Pluralism • Suppose we can break down the barriers… – Enable

The Case for Pluralism • Suppose we can break down the barriers… – Enable realistic evaluation of new ideas – Overcome the coordination constraint • Maybe there isn’t just one right answer – Maybe the problem is over-constrained – Too many goals, some of them conflicting • Maybe the goals change over time – And we’ll always be reinventing ourselves – The only constant is change • So, perhaps we should design for change 33

Different Services, Different Goals • Performance – Low delay/jitter: Vo. IP and online gaming

Different Services, Different Goals • Performance – Low delay/jitter: Vo. IP and online gaming – High throughput: bulk file transfer • Security/privacy – High security: online banking and e-commerce – High privacy: Web surfing • Scalability – Very scalable: global Internet reachability – Not so scalable: communication in small groups 34

Applications Within an Single ISP • Customized virtual networks – Security for online banking

Applications Within an Single ISP • Customized virtual networks – Security for online banking – Fast-convergence for Vo. IP and gaming – Specialized handling of suspicious traffic • Testing and deploying new protocols – Evaluate on a separate virtual network – Rather than in a dedicated test lab – Large scale and early-adopter traffic • Leasing virtual components to others – ISPs have unused node and link capacity – Can allow others to construct services on top 35

Economic Refactoring in CABO Infrastructure Providers Service Providers • Infrastructure providers: Maintain routers, links,

Economic Refactoring in CABO Infrastructure Providers Service Providers • Infrastructure providers: Maintain routers, links, data centers, and other physical infrastructure • Service providers: Offer end-to-end services (e. g. , layer 3 VPNs, SLAs, etc. ) to users Today: ISPs try to play both roles, and cannot offer end-to-end services 36

Similar Trends in Other Industries • Commercial aviation – Infrastructure providers: Airports – Infrastructure:

Similar Trends in Other Industries • Commercial aviation – Infrastructure providers: Airports – Infrastructure: Gates, “hands and eyes” support – Service providers: Airlines JFK SFO PEK ATL E. g. : airplanes, auto industry, and commercial real estate 37

Communications Networks, Too! • Two commercial examples in IP networks – Packet Fabric: share

Communications Networks, Too! • Two commercial examples in IP networks – Packet Fabric: share routers at exchange points – FON: resells users’ wireless Internet connectivity Broker • FON economic refactoring – Infrastructure providers : Buy upstream connectivity – Service provider: FON as the broker (www. fon. com) 38

Enabling End-to-End Services • Secure routing protocols • Multi-provider Virtual Private Networks • Paths

Enabling End-to-End Services • Secure routing protocols • Multi-provider Virtual Private Networks • Paths with end-to-end performance guarantees Today Competing ISPs with different goals must coordinate Cabo Single service provider controls end-to-end path 39

Conclusion • The Internet needs to change – Security, mobility, availability, management, … •

Conclusion • The Internet needs to change – Security, mobility, availability, management, … • We can overcome barriers to change – Enable realistic experimentation with new ideas – Enable multiple designs with different trade-offs – Enable end-to-end deployment of new services • Network virtualization is the key – Run many research experiments in parallel – Offer customized end-to-end services in parallel • VINI as an enabling experimental platform 40