Transcript VINI: Virtual Network Infrastructure

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
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, P2P, VoIP, …)
• But, change is easy only at the edge… 
2
Internet is Showing Signs of Age
• Security
– Weak notions of identity that are easy to spoof
– Protocols that rely on good behavior
• Mobility
– Hierarchical addressing closely tied with routing
– Presumption that communicating hosts are connected
• Availability
– Poor visibility into underlying shared risks
– Multiple interconnected protocols and systems
• Network management
– Many coupled, decentralized control loops
3
Variety of Architectural Solutions
• Revisiting definition & placement of function
–Naming, addressing, and location
–Routing, forwarding, and addressing
–Management, control, and data planes
–End hosts, routers, and operators
• Designing with new constraints in mind
–Selfish and adversarial participants
–Mobile hosts and disconnected operation
–Large number of small, low-power devices
–Ease of network management
4
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
5
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
6
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
–QoS, IP multicast, secure routing, IPv6,…
–Despite solving real, pressing problems
• Increasing commoditization of ISPs
1
sender
2
3
receiver7
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”
8
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
9
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
10
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 PoPs in Seattle and Virginia
12
Shared Infrastructure
Experiments given illusion of dedicated hardware
13
Flexible Topology
VINI supports arbitrary virtual topologies
14
Network Events
VINI exposes, can inject network failures
15
External Connectivity
c
s
Experiments can carry traffic for real end-users
16
External Routing Adjacencies
BGP
BGP
c
s
BGP
BGP
Experiments can participate in Internet routing
17
Virtualizing the Computer
• Starting with the PlanetLab software
–Simultaneous experiments in separate VMs
–Each has “root” in its own VM, can customize
–Reserve processing resources per VM
Node
Mgr
Local
Admin
VM1
VM2
…
VMn
Virtual Machine Monitor (VMM)
(Linux++)
PlanetLab node
18
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 PlanetLab VM
PlanetLab VM
19
User-Mode Linux: Environment
UML
XORP
(routing protocols)
eth0
eth1
eth2
eth3
• Interface ≈ network
• PlanetLab limitation:
– Does not virtualize the
underlying network
• Level of indirection
– Run routing software in
UML environment
– Create virtual network
interfaces in UML
PlanetLab VM
20
Click: Data Plane
• Interfaces  tunnels
– Click UDP tunnels
correspond to UML
network interfaces
UML
XORP
(routing protocols)
eth0
eth1
eth2
eth3
• Filters
Control
Data
Packet
Forward
Engine
Click
PlanetLab VM
UmlSwitch
element
Tunnel table
Filters
– “Fail a link” by blocking
packets at tunnel
• Forwarding packets
– Avoid UML overhead
– Around 200 Mbps
– Not good enough
21
Intra-domain Route Changes
s
856
2095
700
260
1295
c
639
366
233
548
587
846
902
1893
1176
Watch OSPF route convergence on Abilene
22
Ping During Link Failure
Link down
120
Routes converging
110
Ping RTT (ms)
Link up
100
90
80
Abilene RTT: 73ms
70
0
10
20
30
Seconds
40
50
23
TCP Throughput
Link down
12
Link up
Megabytes transferred
Packet receiv ed
10
8
6
4
Zoom in
2
0
0
10
20
30
40
50
Seconds
24
Arriving TCP Packets
2.45
Megabytes in stream
Packet receiv ed
2.4
2.35
VINI
2.3
enables
Slow start a virtual network
to
behave
like
a
real
network
2.25
2.2
Retransmit
lost packet
2.15
2.1
17.5
18
18.5
19
Seconds
19.5
20
25
Operating System Extensions
• Move data plane into the operating system
–Higher speed, lower jitter, and better scalability
• Virtualize the network data structures
–Separate forwarding table per virtual host
• Virtual links inside the operating system
–Terminate tunnels inside the operating system
–No data copying leads to fast packet forwarding
• Resource isolation
–Apply traffic shaping to control resource usage
26
Three-Level Design
• Virtual host, in user space
–Experimenter’s software
–Routing protocols, applications
Research
experiment
• Virtual host, in the OS
–Forwarding tables
–Virtual Ethernet interfaces
• Shared substrate, in the OS
–Tunnels between VINI nodes
–Shaping to enforce rate limits
Forwarding table,
Virtual interfaces
Traffic shaping,
Tunnel interfaces
Network
27
Ongoing Work on Packet Processing
• Tension between three goals
–High-speed packet processing
–Customization of the packet processing
–Sharing of the packet processor
• Shared, fast, customized packet processing
– Within the operating system
–Field Programmable Gate Array (FPGA)
–Network Processor (NP)
• Practical programmable virtual networks
28
What Do People Run on VINI?
• Scaling Ethernet to a large enterprise
• Routing-protocol support for mobile hosts
• Network-layer support distributed services
• Piggybacking diagnostic data on packets
• <Insert your prototype system here>
• Multiple solutions to multiple problems…
29
Network Virtualization in Practice
• Moving beyond experimental facilities
–Helping folks run their networks better
• Customized virtual networks
–Security for online banking
–Fast-convergence for VoIP and gaming
–Anonymity and throughput for Web 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
30
Virtualization for Economic Refactoring
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
31
Similar Trends in Other Industries
• Commercial aviation
–Infrastructure providers: Airports
–Infrastructure: Gates, “hands and eyes” support
–Service providers: Airlines
JFK
SFO
NRT
ATL
E.g.: airplanes, auto industry, and commercial real estate32
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)
33
Enabling End-to-End Services
• Secure routing protocols
• 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
34
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
35