Offloading Routing Complexity to the Cloud(s)

1. Offloading Routing Complexity to the Cloud(s) Hasan T. Karaoglu, Murat Yuksel University of Nevada, Reno ICC’13, Budapest June, 2013

2. Outline • Motivation & Trends • Architectural View • Cloud-Assisted Routing (CAR) • BGP Peering Establishment with CAR • Future Directions

3. 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”

4. Motivation & Trends • 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 Cloud-Assisted Routing (CAR) Can techniques leveraging the memory and computation resources of the cloud remedy the routing scalability issues?”

5. Trends and Our Goal • 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? Cloud Providing CAR Services to Many Routers Proxy Router X (Software with Full Routing Functions) Updates and Packets Updates CAR Router X Router X (Hardware with Partial Routing Functions)

6. An Architectural View Cloud-Based Approaches flexibility Local Approaches scalability Parallel Architectures (e.g., RouteBricks) Clustered Commodity Hardware (e.g., Google) Specialized ASIC (e.g., Cisco) Routing As a Service (e.g., RCP) Managing Routers from Cloud (e.g., NEBULA, Cisco CSR) Separation of Control & Forwarding Planes (e.g., OpenFlow) Cloud-Assisted Routing (CAR) A middle-ground to realize the architectural transition.

7. Scalability-Flexibility Tradeoff

8. CAR: Cloud-Assisted Routing Router Proxy Key Design Question: Where to place the functions? router or the proxy 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! BGP Peer

9. CAR: Heavy Computations Router Proxies Router Proxies on Cloud • Initializations • Peering establishments • Longer timescale optimizations: table restructuring and adaptation BGP Peers CAR Principle 1: Keep the control plane closer to the cloud! Offload heavy computations to the cloud.

10. CAR: Caching and Delegation

11. CAR: Caching and Delegation

12. 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.

13. BGP Peering Establishment (PE) Scenario Phase 1: Table Exchange btw Proxies BGP Peer Establishment • ~400K prefixes (full table) exchanged • 4-5mins at peak CPU utilization • Only 4K prefixes selected as best path Phase 2: ORF List Exchange BetweenRouters and Proxies 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 3: Only Selected Prefixes Exchange Initially Btw Routers BGP Peer Establishment Scenario

14. BGP PE Scenario: More Details

15. BGP PE: Experimental Setup Virtual Peers Virtual Peers . . . . . . ~30ms LINX DECIX Quagga routers in two separate Emulab servers

16. BGP PE: Results LINX-DECIX BGP Peering Establishment Results 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!

17. 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

18. 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

19. 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

20. Questions? Thank You For offline questions: hkaraogl@cisco.com or yuksem@cse.unr.edu

21. Handling Failures Potential loop that must be prevented Traffic Delegatedto Cloud Failed Edge Router

22. Multi-Cloud Designs Backend mirroring among proxy routers Proxy Router Proxy Router Proxy Router Intermediary (e.g., CloudCmp) Router