Embed Size (px)
Citation preview
Offloading Routing Complexity to the Cloud(s)
Hasan T. Karaoglu,Murat Yuksel
University of Nevada, RenoICC’13, Budapest
June, 2013
Outline
• Motivation & Trends• Architectural View• Cloud-Assisted Routing (CAR)• BGP Peering Establishment with CAR• Future Directions
2
Motivation & Trends• Routing scalability is a burning issue!
– State is growing, and so its computational complexity • Growing FIB and RIB size (~ 400K)• Growing computational burden of routing and forwarding on router hardware• Lookups are getting harder to do as the transmission speeds are increasing
– Cost of routing unit traffic is not scaling well• Specialized router designs are getting costlier, currently > $40K
• Growing demand on router programmability– Customizable Routing (Source Routing, VPN)– Flexibility in path composition: policy, quality– Software-defined “everything”
3
• Cloud services are getting abundant– Closer:
• Delay to the cloud is reducing [CloudCmp, IMC’10]• Bandwidth to the cloud is increasing
– Cheaper:• CPU and memory are becoming commodity at the cloud• Cloud prices are declining
– Computational speedups via parallelization– Scalable resources, redundancy
Motivation & Trends
Cloud-Assisted Routing (CAR)Can techniques leveraging the memory and computation resources of the
cloud remedy the routing scalability issues?”4
• Goal: To mitigate the growing routing complexity to the cloud.
• Research Question: If we maintain the full router functionality at the cloud but only partial at the router hardware, can we solve some of the routing scalability problems?
Trends and Our Goal
Router X(Hardware with Partial Routing Functions)
Upd
ates
and
Pa
cket
s
Proxy Router X(Software with Full Routing Functions)
CAR
Rout
er X
Upd
ates
Cloud Providing CAR Services to Many Routers
5
Routing As a Service(e.g., RCP)
Managing Routers from Cloud
(e.g., NEBULA, Cisco CSR)
Separation of Control & Forwarding Planes
(e.g., OpenFlow)
Parallel Architectures(e.g., RouteBricks)
Clustered Commodity Hardware
(e.g., Google)
Specialized ASIC(e.g., Cisco)
Cloud-Assisted Routing (CAR)
A middle-ground to realize the architectural
transition.
An Architectural ViewLocal Approaches
scalability
Cloud-Based Approachesflexibility
6
Scalability-Flexibility Tradeoff
7
BGP Peer
Router Proxy
CAR: Cloud-Assisted Routing
Use the valuable router hardware for the most used prefixes and the
most urgent computations, and delegate the rest to the cloud.
Amdahl’s Law in action!
Key Design Question:Where to place the functions?router or the proxy
8
Router Proxies on Cloud• Initializations• Peering establishments• Longer timescale optimizations:
table restructuring and adaptation
BGP Peers
Router Proxies
CAR: Heavy Computations
CAR Principle 1: Keep the control plane closer to the cloud! Offload heavy computations to the cloud.
9
CAR: Caching and Delegation
10
CAR: Caching and Delegation
11
CAR: Caching and Delegation
CAR Principle 2: Keep data plane closer to the router.Keep the forwarding operations at the router to the extent possible.
12
BGP Peer Establishment
Scenario
BGP Peer Establishment• ~400K prefixes (full table) exchanged• 4-5mins at peak CPU utilization• Only 4K prefixes selected as best
path
BGP Peer Establishment• Parallelization speedup at the cloud• ~4K prefixes provided to Routers• Outbound Route Filtering RFC 5291• Route-map to apply high LOCAL-PREF• Takes approx. 1-2 minutes
Phase 1: Table Exchange btw Proxies
Phase 2: ORF List Exchange Between Routers
and Proxies
Phase 3: Only Selected
Prefixes Exchange Initially Btw
Routers
BGP Peering Establishment (PE) Scenario
13
BGP PE Scenario: More Details
14
LINX
.
.
.
.
.
.DECIX
Virtual Peers
Virtual Peers
~30ms
Quagga routers in two separate Emulab servers
BGP PE: Experimental Setup
15
LINX-DECIX BGP Peering Establishment Results
BGP PE: Results
16
small traffic rates per interface, small route-to-prefix ratio, and limited inbound-outbound filtering
The affect of CAR in a real setting will be more pronounced!
Summary
• A hybrid approach– partial functions at the router, full functions at the cloud
• Two principles:– Data plane close to the router– Control plane close to the cloud
• Potential for leveraging temporal and spatial locality– BGP control traffic can be reduced
• CPU bursts can be tamed on peering routers
17
Many Possibilities
• Intra-cloud optimizations among routers receiving the CAR service– Data Plane: Forwarding can be done in the cloud – Control Plane: Peering exchanges and routing
updates can be done in the cloud• Per-AS optimizations– Data Plane: Pkts do not have to go back to the
physical router until the egress point– Control Plane: iBGP exchanges
18
Some Interesting Analogies
• High cloud-router delay– CAR miss at the router Page Fault– Delegation is preferable• Forward the pkt to the cloud proxy
• Low cloud-router delay– CAR miss at the router Cache Miss– Caching (i.e. immediate resolution) is preferable• Buffer the pkt at the router and wait until the miss is
resolved via the full router state at the cloud proxy
19
Failed Edge Router
Traffic Delegated to
Cloud
Potential loop that must be prevented
Handling Failures
21
Router
Backend mirroring among proxy routers
Intermediary(e.g., CloudCmp)
Proxy Router Proxy RouterProxy Router
Multi-Cloud Designs
22
