Network Virtualization
Jennifer Rexford
Advanced Computer Networks
http://www.cs.princeton.edu/courses/archive/fall08/cos561/
Tuesdays/Thursdays 1:30pm-2:50pm
Introduction
• Motivation for network virtualization
– Deployment dilemma, too many design goals,
and coordination constraint
• Pluralist networks
– Economic refactoring
– Infrastructure and service providers
• Research challenges
– Systems challenges
– Resource allocation
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… 
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?
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
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
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
receiver
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”
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
Pluralist Future
The Case for Pluralism
• Suppose we can break down the barriers…
– Enable realistic evaluation of new ideas
– Overcome the coordination constraint
• Maybe there isn’t just one right answer
– Maybe the problem is over-constrained
– Too many goals, some of them conflicting
• Maybe the goals change over time
– And we’ll always be reinventing ourselves
– The only constant is change
• So, perhaps we should design for change
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
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
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
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
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)
Enabling End-to-End Services
• Secure routing protocols
• Multi-provider Virtual Private Networks
• Paths with end-to-end performance guarantees
Today
Competing ISPs
with different goals
must coordinate
Cabo
Single service
provider controls
end-to-end path
Research Challenges
Virtualized and Programmable Routers
• Multiple routers on a single substrate
– Multiple control planes
– Multiple data planes
• Design trade-offs
– Speed: aggregate forwarding performance
• Getting close to raw forwarding speed
– Isolation: avoiding interference
• Avoiding jitter and resource contention
– Customization: programmability of the data plane
• Moving beyond IPv4 packets and Ethernet frames
• Software (e.g., Click) vs. hardware (e.g., NetFPGA)?
Control Frameworks
• Embedding virtual topology in physical one
– Finding suitable physical nodes and physical links
– With enough CPU, bandwidth, and memory
– … and satisfying geographic and delay constraints
• Instantiating the virtual network
– Creating each virtual node and virtual link
– Reserving the necessary resources
• Monitoring the running system
– Detecting and diagnosing problems
– Providing measurement data to virtual network
Ways to Exploit Router Virtualization
• Exploiting the new capabilities in routers
– Separation of the physical from the logical
– Ability to run multiple routers in parallel
• Example: virtual router migration
– Moving router from one physical node to another
– E.g., for planned maintenance or service roll-out
• Example: bug-tolerant routers
– Running multiple instances of routing software
– … and “voting” to protect the system from bugs
Discussion: Internet vs. Pluralism
• Internet architecture
– End-to-end argument
– Best-effort packet-delivery service
– Narrow waist of IP
– Separation of intradomain from interdomain
• Virtualized programmable networks
– Complete control within a virtual network
– Programmable functionality inside the network
– Different (virtual) networks for different services
Discussion: Experimental Infrastructure
• How to evaluate research ideas?
– Analysis
– Simulation
– Prototyping
– Deployment studies
• Importance of wide-area deployment?
– Realistic traffic and network conditions
– Real users and participation in experiments
• How real does real need to get?
• Will researchers bother to build and deploy?
– Incentives for conducting this kind of research