cabo: concurrent architectures are better than one

18
Cabo: Concurrent Architectures are Better than One Nick Feamster, Georgia Tech Lixin Gao, UMass Amherst Jennifer Rexford, Princeton

Upload: kalia-briggs

Post on 30-Dec-2015

30 views

Category:

Documents


2 download

DESCRIPTION

Cabo: Concurrent Architectures are Better than One. Nick Feamster, Georgia Tech Lixin Gao, UMass Amherst Jennifer Rexford, Princeton. Network Virtualization. Flexible Network Topology. VINI: Virtual Network Infrastructure. Experimentation with new architectures (“bake off”) - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Cabo: Concurrent Architectures are Better than One

Cabo: Concurrent Architectures are Better than One

Nick Feamster, Georgia TechLixin Gao, UMass AmherstJennifer Rexford, Princeton

Page 2: Cabo: Concurrent Architectures are Better than One

2

Network Virtualization

Page 3: Cabo: Concurrent Architectures are Better than One

3

Flexible Network Topology

Page 4: Cabo: Concurrent Architectures are Better than One

4

VINI: Virtual Network Infrastructure

XORP(routing protocols)

UML

eth1 eth3eth2eth0

Click

PacketForwardEngine

Control

DataUmlSwitch

element

Tunnel table

Filters

• Experimentation with new architectures (“bake off”)– Experiments can share

same physical infrastructure

– Important characteristics for repeatable experiments

• Simultaneous experiments

• Long-running “deployment studies”

• Resource isolation

Page 5: Cabo: Concurrent Architectures are Better than One

5

Idea: Infrastructure is the Architecture

• Pluralist: No single “winning” architecture– Simultaneously running architectures

• Network Operations– Transitioning to new software, configurations, etc.

– Different networks for different services (e.g., VoIP)

– Security: sandboxing unwanted traffic

– Topology-specific routing protocols

• ISPs “rent” slices of resources to each other– Or, perhaps even rent resources from third parties

Page 6: Cabo: Concurrent Architectures are Better than One

6

Today: ISPs Serve Two Roles

• Infrastructure providers: Maintain routers, links, data centers, other physical infrastructure

• Service providers: Offer services (e.g., layer 3 VPNs, performance SLAs, etc.) to end users

Role 1: Infrastructure Providers Role 2: Service Providers

No single party has control over an end-to-end path.

Page 7: Cabo: Concurrent Architectures are Better than One

7

Coupling Causes Problems• Deployment stalemates: Secure routing, multicast, etc.

– Focus on incremental deployability cripples us

• Shrinking profits and commoditization: ISPs cannot enhance end-to-end service– No single ISP has purview over an entire path

“As of 5:30 am EDT, October 5th, [2005], Level(3) terminated peering with Cogent without cause…even though both Cogent and Level(3) remained in full compliance …We are extending a special offering to single homed Level 3 customers. Cogent will offer any Level 3 customer, who is single homed to the Level 3 network on the date of this notice, one year of full Internet transit free of charge at the same bandwidth currently being supplied by Level 3. …”

“How do you think they're going to get to customers? Through a broadband pipe.. we have spent this capital and we have to have a return … there's going to have to be some mechanism for these people who use these pipes to pay for the portion they're using.”

–Edward Witacre

• Peering Tiffs: End-to-end connectivity is in the balance

Page 8: Cabo: Concurrent Architectures are Better than One

8

Proposal: Concurrent Architectures are Better than One (“Cabo”)

• The business entities that play these two roles may be the same in some cases

• Infrastructure providers: maintain physical infrastructure needed to build networks

• Service providers: lease “slices” of physical infrastructure from one or more providers

Page 9: Cabo: Concurrent Architectures are Better than One

9

Similar Trends in Other Industries

• Commercial aviation– Infrastructure providers: Airports– Infrastructure: Gates, “hands and eyes”, etc.– Service providers: Airlines

• Other examples: Automobile industry

SFOATL

BOS

ORD

Page 10: Cabo: Concurrent Architectures are Better than One

10

Communications Networks, Too!

• Packet Fabric: share routers at exchange points• FON: resells users’ wireless Internet connectivity

• Infrastructure providers: Buy upstream connectivity, broker access through wireless

• Nomads: Users who connect to access points• Service provider: FON as broker

Two commercial examples

Broker

Page 11: Cabo: Concurrent Architectures are Better than One

11

Application #1: 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

Page 12: Cabo: Concurrent Architectures are Better than One

12

Application #2: Virtual Co-Location

• Problem: ISP/Enterprise wants presence in some physical location, but doesn’t have equipment there.

• Today: Backhaul, or L3 VPN from single ISP• Cabo: Lease a slice of another’s routers, links

Tokyo

NYC

ATL

Page 13: Cabo: Concurrent Architectures are Better than One

13

Challenge #1: Embedding

• Given: virtual network and physical network– Topology, constraints, etc.

• Problem: find the appropriate mapping onto available physical resources (nodes and edges)

• Many possible formulations– Specific nodes mapping to certain physical nodes– Generic requirements: “three diverse paths from SF to

LA with 100 MBps throughput”– Traffic awareness, dynamic remapping, etc.– Approximate solutions

Page 14: Cabo: Concurrent Architectures are Better than One

14

Challenge #2: Simultaneous Operation

• Problem: Service providers must share infrastructure

• Approach: Virtualize the infrastructure– Nodes

• PlanetLab• Virtual Machines• Virtual Routers

– Links (previous lessons in QoS?)

• Capabilities are similar to those needed for VINI– Many of the same functions needed– Likely more federation in Cabo

Page 15: Cabo: Concurrent Architectures are Better than One

15

Challenge #3: Substrate• Problem: Service providers must be able to

request physical infrastructure (infrastructure providers must be able to instantiate it)

– Discovering physical infrastructure• Decision elements (cf. 4D proposal)

– Creating virtual networks• Requests to decision elements (initially out of

band), which name virtual network components

– Instantiating virtual networks• Challenges include embedding and accounting

Page 16: Cabo: Concurrent Architectures are Better than One

16

Requirements

• Router virtualization– Scheduling of node CPU, link bandwidth, etc.

• Programmable software in each slice– Service providers will customize

• Support for substrate– “Out-of-band” communication– Accounting: what bandwidth has been reserved?

Page 17: Cabo: Concurrent Architectures are Better than One

17

Economic Challenges

• Service providers: great deal– Opportunity to add value by creating new services– Service differentiation

• Infrastructure providers– Can being an infrastructure provider be profitable?– Who will become infrastructure providers vs. service

providers?

Page 18: Cabo: Concurrent Architectures are Better than One

18

Summary

• ISPs are infrastructure + service providers is problematic– Deployment stalemate– Commoditization

• Cabo: “Concurrent Architectures are Better than One”– Separate infrastructure from service providers

• Applications– Multi-provider VPNs, end-to-end services and protocols, …

• Challenges– Simultaneous operation– Bootstrapping

More Information: http://www.cc.gatech.edu/~feamster/papers/cabo-tr.pdf