VINI: Virtual Network Infrastructure

1
VINI Virtual Network Infrastructure

• Jennifer Rexford
• Princeton University
• http//www.cs.princeton.edu/jrex

2
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 ?

3
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?

4
Hurdle 1 Deployment Dilemma

• An unfortunate catch-22
• Must deploy an idea to demonstrate feasibility
• Cant get an undemonstrated idea deployed
• A corollary the testbed dilemma
• Production network real users, but cant 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 isnt 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
2
3
sender
receiver
7
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-verita
s.net
10
VINI VIrtual Network Infrastructure
11
VINI Offers Controlled Realism

• Start with a controlled experiment
• Relax constraints, study effects
• Result an operational virtual network thats
• Feasible
• Valuable
• Robust
• Scalable, etc.

Real clients, servers
Synthetic or traces
Traffic
12
Fixed Infrastructure
Deployed VINI nodes in National Lambda Rail and
Abilene, and PoPs in Seattle and Virginia
13
Shared Infrastructure
Experiments given illusion of dedicated hardware
14
Flexible Topology
VINI supports arbitrary virtual topologies
15
Network Events
VINI exposes, can inject network failures
16
External Connectivity
s
Experiments can carry traffic for real end-users
17
External Routing Adjacencies
s
Experiments can participate in Internet routing
18
VINI Platform Design
19
Virtualizing the Computer

• Starting with the PlanetLab 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
VM1
VM2
VMn

Virtual Machine Monitor (VMM) (Linux)
PlanetLab node
20
Creating the Virtual Topology

• Goal real routing protocols on virtual network
  topologies
• Various routing protocols (BGP, OSPF, RIP, IP
  multicast)
• Run unmodified routing software in a virtual
  machine

XORP (routing protocols)
VM
21
Virtual Network Abstraction

• PlanetLab limitation
• Does not virtualize the underlying network
• For each VM we want
• Interfaces, bound to tunnels to other nodes
• Networking stack (e.g., forwarding table)
• Packet forwarding in OS
• Across VMs we want
• Independent topologies
• Resource isolation

User space
XORP (routing protocols)
eth1
eth3
eth2
eth0
Control
Data
FIB
tunnels
OS
22
Network Name Spaces (NetNS)

• NetNS 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

23
Connecting Interfaces to Tunnels

• Ethernet switch
• Linux bridge module
• Connects all interfaces
• And all tunnels
• Short bridge
• No MAC learning
• No forwarding look-up
• No frame header copying
• EGRE tunnels
• Carry Ethernet frames
• Support non-IP protocols

User space
XORP (routing protocols)
eth1
eth3
eth2
eth0
etun3
etun1
etun2
FIB
Short Bridge
OS
24
Isolation Between Virtual Networks

• Virtual host (user space)
• Experimenters software
• Protocols, applications
• Virtual host (OS)
• Forwarding tables
• Virtual Ethernet interfaces
• Shared substrate (OS)
• Tunnels between nodes
• Enforcing rate limits

User space
XORP (routing protocols)
eth1
eth3
eth2
eth0
etun3
etun1
etun2
FIB
OS
Short Bridge
OS
25
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 NetFPGA board from Stanford

26
Example Experiment on VINI
27
Intra-domain Route Changes
s
2095
856
700
260
233
1295
c
639
548
366
846
587
902
1893
1176
Watch OSPF route convergence on Abilene
28
Ping During Link Failure
29
TCP Throughput
30
Arriving TCP Packets
VINI enables a virtual network to behave like a
real network
31
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
• ltInsert your prototype system heregt
• Multiple solutions to multiple problems

32
Where does all this experimentation lead us?
33
The Case for Pluralism

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

34
Different Services, Different Goals

• Performance
• Low delay/jitter VoIP 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

35
Applications Within an Single ISP

• Customized virtual networks
• Security for online banking
• Fast-convergence for VoIP 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

36
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
37
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
38
Communications Networks, Too!

• Two commercial examples in IP networks
• Packet Fabric share routers at exchange points
• FON resells users wireless Internet connectivity

• FON economic refactoring
• Infrastructure providers Buy upstream
  connectivity
• Service provider FON as the broker (www.fon.com)

39
Enabling End-to-End Services

• Secure routing protocols
• Multi-provider Virtual Private Networks
• Paths with end-to-end performance guarantees

Today
Cabo
Competing ISPs with different goals must
coordinate
Single service provider controls end-to-end path
40
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