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

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

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 3

4. Cloud services are getting abundant – Closer: Delay to the cloud is reducing [CloudCmp, IMC10] 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

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

6. 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 View Local Approaches scalability Cloud-Based Approaches flexibility 6

7. Scalability-Flexibility Tradeoff 7

8. 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. Amdahls Law in action! Key Design Question: Where to place the functions? router or the proxy 8

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

10. CAR: Caching and Delegation 10

11. CAR: Caching and Delegation 11

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

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

14. BGP PE Scenario: More Details 14

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

16. 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!

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 17

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 18

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 19

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

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

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