Download presentation
Presentation is loading. Please wait.
1
VINI and its Future Directions
Andy Bavier Princeton University Joint with Nick Feamster, Larry Peterson, Jennifer Rexford
2
Technology Transfer Deploy and support a prototype system
SIGCOMM paper Deployment studies Commercial adoption Deploy and support a prototype system Wide area, longer timescales, real traffic, etc. Technical feasibility Scalability, robustness under realistic conditions System integration and testing Economic incentives Real users potential market
3
Overview VINI vision Current status of VINI Future directions for VINI
Enable deployment studies in real networks Share the nodes, links using virtualization Current status of VINI Future directions for VINI VINI and the NSF GENI project
4
Fixed Infrastructure VINI nodes in National LambdaRail, Internet2,
The first requirement of VINI is that it be a fixed infrastructure. The reason is for control: experiments don’t want the network topology changing from under them. … The idea is that your experiment will provide layer 3 VINI nodes in National LambdaRail, Internet2, PoPs in Seattle and Virginia, CESNET
5
Shared Infrastructure
Building a VINI requires a big investment, so it has to be shared. At the same time, we expect some VINI experiments to be long-running. So there can be a red experiment deployed on VINI, and a blue experiment on the same nodes. A VINI isolates experiments by giving each the illusion of dedicated hardware and resources. Experiments given illusion of dedicated hardware
6
VINI supports arbitrary virtual topologies
Flexible Topology Red experiment chooses a topology that mirrors network. Blue chooses some other topology. VINI supports arbitrary virtual topologies
7
VINI exposes, can inject network failures
Network Events A VINI exposes network events and can also inject them into an experiment. If a physical link fails, this failure is exposed to all topologies that traverse the link. So the red topology sees this link fail, and if the blue link happened to traverse that physical wire, then it would fail as well. Link failures don’t happen often, so it’s desirable to inject our own failures. So the red experiment could inject a link failure and not affect the blue experiment. VINI exposes, can inject network failures
8
External Connectivity
Client traffic for real servers can be diverted into an experiment. The experiment decides how to route the traffic over its topology. The servers – and perhaps even the clients – don’t need to know that this is happening. s Experiments can carry traffic for real end-users
9
External Routing Adjacencies
BGP c How does an experiment find out about external destinations? It should be able to integrate with the current Internet routing infrastructure, e.g., peer with BGP routers. Ultimately experiments should be able to advertise address blocks into the Internet, become a virtual ISP. s Experiments can participate in Internet routing
10
Overview VINI vision Current status of VINI Future directions for VINI
Enable deployment studies in real networks Share the nodes, links using virtualization Current status of VINI Future directions for VINI VINI and the NSF GENI project
11
VINI Current Status - Deployment
Two VINI nodes per site Operational sites: 7 NLR sites 9 Internet2 (NewNet) sites 2 colo sites: Seattle WA, Ashburn VA 1 European site: CESNET Prague 1Gb/s lightpath between Prague and VINI Internet2 nodes in Chicago
12
VINI Status - Virtual Hosts
VINI based on PlanetLab software Simultaneous experiments in separate VMs Each has “root” in its own VM, can customize Reserve CPU and bandwidth per experiment Node Mgr Local Admin VM1 VM2 VMn … A key reason for choosing PlanetLab is that it supports sharing and isolation between experiments. … So here’s a picture of a PlanetLab node. There’s a VMM based on Linux. Each experiment runs in its own VM. Here’s the red and blue experiments, and some others. Virtual Machine Monitor (VMM) (Linux++) PlanetLab node 12
13
VINI Status - Virtual Networks
Configure a virtual topology for a slice Point-to-point virtual Ethernet links Slice controls routing table, virtual devices on the virtual hosts Purpose: allow experimentation with routing software (e.g., XORP, Quagga) that already runs on Linux
14
VINI Trellis v0.1 Virtual host Linux kernel IPv4 routing table
kernel FIB virtual NIC application user kernel Virtual host Linux kernel IPv4 routing table Point-to-point virtual Ethernet Applications add/change routes bridge shaper EGRE tunnel Substrate Ethernet software bridge Traffic shaper Ethernet-over-GRE tunnels (to span multiple IP hops)
15
Overview VINI vision Current status of VINI Future directions for VINI
Enable deployment studies in real networks Share the nodes, links using virtualization Current status of VINI Future directions for VINI VINI and the NSF GENI project
16
Future Questions for VINI
How to leverage other testbeds? Experiments, user communities, tools, etc. How to grow VINI? What new features should VINI offer? Custom hardware Programmable data planes How to link a virtual network to the “real world”? Real users, real traffic, real routing information
17
Leveraging Other Testbeds
Testbed federation mechanisms Federate VINI with PlanetLab, Emulab, OneLab Create experiments that span multiple testbeds Move experiments from one testbed to another Open, modular system architecture Incorporate Emulab topology creation GUI
18
Deploying more VINI nodes
You can join the public VINI CESNET deployment: Prague, Pilsen, ??? Other European research networks? You can create your own VINI VINI is a “private PlanetLab”, based on MyPLC MyVINI = MyPLC + VINI kernel, tools Development platform or dedicated testbed
19
Adding New Features VINI technology trade-offs: Custom hardware
Performance (to carry real traffic) Isolation (to support multiple experiments) Programmability (make it easy to use) Custom hardware NetFPGA from Stanford Supercharged PlanetLab Platform from WUSTL Programmable data plane Allow users to run Click Modular Software Router in Linux kernel, on NetFPGA
20
Connecting to the World
Getting real routing information BGP Multiplexer service Receive BGP information from real routers Advertise routes, experiment becomes ISP Getting real traffic Deploy wireless access points Hide behind a proxy (e.g., game server) Leverage existing PlanetLab services (e.g., CDN)
21
Overview VINI vision Current status of VINI Future directions for VINI
Enable deployment studies in real networks Share the nodes, links using virtualization Current status of VINI Future directions for VINI VINI and the NSF GENI project
22
NSF’s GENI Vision A national facility to explore radical designs for a future global networking infrastructure Large, wide-area footprint Enables large-scale, end-to-end experiments Shared among researchers by virtualization & slices Current / projected substrates High capacity optical nets and programmable cores Large clusters of CPUs, storage Edge / access technologies (e.g. cellular, sensor networks)
23
GENI creates a huge opportunity for ambitious research!
How GENI will be used GENI is meant to enable . . . Trials of new architectures, which may or may not be compatible with today’s Internet Long-running, realistic experiments with enough instrumentation to provide real insights and data ‘Opt in’ for real users into long-running experiments Large-scale growth for successful experiments, so good ideas can be shaken down at scale A reminder . . . GENI itself is not an experiment ! GENI is a stable facility on which experiments run GENI creates a huge opportunity for ambitious research!
24
Strawman GENI Construction Plan
Spiral Development GENI grows through a well-structured, adaptive process An achievable starting point Example: Rev 1 “narrow waist”, federation of multiple substrates (clusters, wireless, regional / national optical net with early GENI ‘routers’, perhaps some existing testbeds), Rev 1 user interface and instrumentation. Envisioned ultimate goal Example: Planning Group’s desired GENI facility, probably trimmed some ways and expanded others. Incorporates large-scale distributed computing resources, high-speed backbone nodes, nationwide optical networks, wireless & sensor nets, etc. Spiral Development Process Re-evaluate goals and technologies yearly by a systematic process, decide what to prototype and build next. Planning Design Use Use Integration Build out Strawman GENI Construction Plan
25
Federation GENI grows by “gluing together” heterogeneous facilities over time
My experiment runs across the evolving GENI federation. Wireless #1 Corporate GENI facilities Backbone #1 Compute Cluster #1 My GENI Slice Other-Nation GENI facilities Access #1 Compute Cluster #2 Backbone #2 This approach looks remarkably familiar . . . Other-Nation GENI facilities Wireless #2 NSF parts of GENI Goals: avoid technology “lock in,” add new technologies as they mature, and potentially grow quickly by incorporating existing facilities into the overall “GENI ecosystem”
26
VINI and the GENI Project
VINI and PlanetLab can be regarded as small-scale prototypes of pieces of GENI Goal: Be GENI-compliant Participate in GENI design efforts Implement new GENI interfaces Influence GENI development process First GENI solicitation: Feb 2008
27
Conclusion VINI is a platform for deployment studies
Need help growing, developing VINI Install VINI nodes in national research networks Extend the VINI platform (e.g., federation) Perform interesting research on VINI Goal: influence the GENI effort in the US
Similar presentations
