VINI: Virtual Network Infrastructure

1
VINI Virtual Network Infrastructure

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

Joint with Andy Bavier, Nick Feamster, Lixin Gao,
Mark Huang, Larry Peterson
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
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

4
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

5
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

6
Hurdle 2 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
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 backbone
• 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
9
Providing 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
10
Fixed Infrastructure
Deployed VINI nodes in National Lambda Rail and
Abilene, and PoPs in Seattle and Virginia
11
Shared Infrastructure
Experiments given illusion of dedicated hardware
12
Flexible Topology
VINI supports arbitrary virtual topologies
13
Network Events
VINI exposes, can inject network failures
14
External Connectivity
s
Experiments can carry traffic for real end-users
15
External Routing Adjacencies
s
Experiments can participate in Internet routing
16
Network Virtualization Software

• Initial prototype 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
17
Creating the Virtual Topology

• Goal real routing protocols on virtual network
  topologies
• BGP, OSPF, RIP, IP multicast,
• XORP can run in a PlanetLab VM
• Without modification!

XORP (routing protocols)
18
User-Mode Linux Environment

• Interface network
• PlanetLab limitation
• Experiments cannot create new interfaces
• Run routing software in UML environment
• Create virtual network interfaces in UML

UML
XORP (routing protocols)
eth1
eth3
eth2
eth0
19
Click Data Plane

• Interfaces ? tunnels
• Click UDP tunnels correspond to UML network
  interfaces
• Filters
• Fail a link by blocking packets at tunnel
• Performance
• Avoid UML overhead
• Around 200 Mbps

UML
XORP (routing protocols)
eth1
eth3
eth2
eth0
Control
Data

Packet Forward Engine
UmlSwitch element
Tunnel table
Click
Filters
20
Ongoing Work Faster Forwarding

• Initial design entirely in user space
• In order to avoid modifying the kernel
• Clearly, this is a big performance limitation
• Virtualized network stack in Linux
• Network views that are bound to processes
• Separate kernel forwarding tables per view
• Hardware support through FPGAs and NPs
• Nick McKeowns NetFPGA project
• Jon Turners MetaRouter project

21
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
22
Ping During Link Failure
23
TCP Throughput
24
Arriving TCP Packets
VINI enables a user-space virtual network to
behave like a real network
25
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
• Where should this experimentation lead us?
• Will we ever find the one true answer???

26
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

27
Its Hard to be a Routing Protocol

• Many, many design goals
• Global reachability
• Fast convergence
• Efficient use of resources
• Low protocol overhead
• Secure control plane
• Flexible routing policies
• ltyour wish list heregt
• Perhaps we cannot satisfy all of these goals
• No matter how hard we try

28
Example Security vs. Reachability
Online Banking Web Surfing
Properties Security, even at the expense of reachability Reachability more important than security
Routing Secure control plane for participating parties Insecure control plane for all parties
Addressing Self-certifying address associated with person Ephemeral address related to the topology
29
Example Convergence vs. Scalability
Voice over IP Gateway Remaining Traffic
Properties Fast convergence for a few prefixes Scalability to 200K prefixes
Dissemination Flooding Hierarchical
Routing Protocol Link state (OSPF or IS-IS) Path vector (iBGP with route reflectors)
30
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

31
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
32
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 estate
33
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)

34
Enabling End-to-End Services

• Secure routing protocols
• Multi-provider VPNs
• Paths with end-to-end performance guarantees

Today
Cabo
Competing ISPs with different goals must
coordinate
Single service provider controls end-to-end path
35
Conclusion

• The Internet needs to change
• Security, mobility, availability, management,
• We can overcome barriers to change
• Enable realistic experimentation with new ideas
• 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

36
Backup Slides
37
Ongoing Work Experiment Framework

• Experiment specification and monitoring
• Specifying topology and configuration
• E.g., Internet-in-A-Slice experiments
• Collecting and visualizing packet traces
• Distributed tcpdump and network animator
• Instantiating virtual networks
• Admission control
• Book-keeping of node and link resources
• Topology embedding
• Finding available node and link resources

38
Other Example VINI Experiments

• Scaling Ethernet to a large enterprise
• Scalability of IP routing, self-config of
  Ethernet
• Flat addressing hash-based location resolution
• Routing-protocol support for mobile hosts
• Injecting host address into the routing protocol
• Withdrawing and readvertising as host moves
• Network-layer support for overlay services
• Hosting overlay services directly on the routers
• Notifying the overlay services of network events
• ltInsert your prototype system heregt

39
Success Scenarios for VINI GENI

• Expand the research pipeline
• Sound foundation for future network architectures
• Experimental evaluation, rather than paper
  designs
• Create new services
• Demonstrate new services at scale
• Attract real users
• Aid the evolution of the Internet
• Demonstrate ideas that ultimately see real
  deployment
• Provide architectural clarity for evolutionary
  path
• Lead to a future global network
• Purist converge on a single new architecture
• Pluralist virtualization supporting many
  architectures