VINI and its Future Directions
Andy Bavier
Princeton University
http://www.cs.princeton.edu/~acb
Joint with Nick Feamster, Larry Peterson, Jennifer Rexford
1
Technology Transfer
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
2
Overview
• VINI vision
–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
3
Fixed Infrastructure
VINI nodes in National LambdaRail, Internet2,
PoPs in Seattle and Virginia, CESNET
Shared Infrastructure
Experiments given illusion of dedicated hardware
Flexible Topology
VINI supports arbitrary virtual topologies
Network Events
VINI exposes, can inject network failures
External Connectivity
c
s
Experiments can carry traffic for real end-users
External Routing Adjacencies
BGP
BGP
c
s
BGP
BGP
Experiments can participate in Internet routing
Overview
• VINI vision
–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
10
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
11
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
Virtual Machine Monitor (VMM)
(Linux++)
PlanetLab node
12
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
VINI Trellis v0.1
application
user
kernel
kernel FIB
virtual
NIC
virtual
NIC
bridge
bridge
shaper
shaper
EGRE
tunnel
EGRE
tunnel
Virtual host
• Linux kernel IPv4 routing table
• Point-to-point virtual Ethernet
• Applications add/change routes
Substrate
• Ethernet software bridge
• Traffic shaper
• Ethernet-over-GRE tunnels
(to span multiple IP hops)
Overview
• VINI vision
–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
15
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
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
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
Adding New Features
• VINI technology trade-offs:
– 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
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)
20
Overview
• VINI vision
–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
21
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)
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!
Spiral Development
GENI grows through a well-structured, adaptive process
• An achievable starting point
Planning
Design
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
Use
Use
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
Integration
Build out
Strawman GENI Construction Plan
Re-evaluate goals and technologies yearly by
a systematic process, decide what to
prototype and build next.
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
Compute
Cluster
#2
My GENI Slice
Access
#1
Backbone #2
NSF parts of GENI
Other-Nation
GENI facilities
Other-Nation
GENI facilities
This approach looks
remarkably familiar . . .
Wireless
#2
Goals: avoid technology “lock in,” add new technologies as they mature, and potentially
grow quickly by incorporating existing facilities into the overall “GENI ecosystem”
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
26
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
http://www.vini-veritas.net