BANANAS An Evolutionary Framework for Explicit and Multipath

BANANAS: An Evolutionary Framework for Explicit and Multipath Routing in the Internet 5 B C 3 5 2 A 2 1 2 D 1 F 1 3 E 2 Hema T. Kaur, S. Kalyanaraman, A. Weiss, S. Kanwar, A. Gandhi Rensselaer Polytechnic Institute hema@networks. ecse. rpi. edu, shivkuma@ecse. rpi. edu http: //www. ecse. rpi. edu/Homepages/shivkuma Sponsors: DARPA-NMS, NSF, Intel, AT&T Rensselaer Polytechnic Institute 1 Shivkumar Kalyanaraman

In case you were wondering… BANANAS is not an acronym Just something to remember this by… Rensselaer Polytechnic Institute 2 Shivkumar Kalyanaraman

Outline q Motivation: Best-effort path multiplicity q BANANAS: Data-plane q BANANAS: Control-plane q BANANAS: Mapping to BGP q Performance Results Rensselaer Polytechnic Institute 3 Shivkumar Kalyanaraman

Motivation: Best-Effort Path Multiplicity Phone modem USB/802. 11 a/b 802. 11 a Wi. Fi (802. 11 b) Ethernet Firewire/802. 11 a/b ISP-1 AS 1 Internet . . . ISP-n Rensselaer Polytechnic Institute 4 Shivkumar Kalyanaraman

Multiplicity: Flows, Paths, Exits/Interfaces Multiple E 2 E Flows Multi-homed interfaces & ISP/AS peers Multi-paths within a routing domain Multi-AS-paths across domains W/o specifying intra-domain paths Multiple exits from an AS w/o. To specifying paths BANANAS: A Single Abstract Framework Exploitintra-domain These Forms of Multiplicity In the Internet and Future Networks Rensselaer Polytechnic Institute 5 Shivkumar Kalyanaraman

Isn’t multi-path routing an old subject? q Lots of old work: q q q Multi-path algorithms/protocols [5, 6, 7, 8], Internet signaling architectures [9, 10, 11, 12, 13] Novel overlay routing methods [14, 15] Transport-level approaches for multi-homed hosts [16, 17] But newer goals: q Traffic engineering (reliability, availability, survivability, re-route): q Separation of traffic trunking from route selection q Packet level or aggregate (micro-flow or macro-flow level) Security q Best-effort e 2 e service composition… q Why hasn’t it happened after 2 decades of work? Rensselaer Polytechnic Institute 6 Shivkumar Kalyanaraman

Missing Architectural Concepts q An evolutionary partial deployment strategy q q Abstract enough to be applicable to other scenarios: q q Allows partial deployment, incremental upgrades Incentives: increasing value with increasing deployment Fits the connectionless nature of dominant routing protocols, q Must not require signaling (unlike ATM, MPLS etc) Overlay networks, last-mile multi-hop (mesh or community) wireless networks, ad-hoc/sensor networks… Flexible enough to have other realizations/semantics: q q q Different placement of functions (edge vs core) Tunneling/Label Stacking Geographic/Trajectory routing Rensselaer Polytechnic Institute 7 Shivkumar Kalyanaraman

Limits of Connectionless Traffic Engg (OSPF/BGP) State-of-the-art: parameter tweaking q OSPF, IS-IS: Link weight tweaking or q BGP-4 parameter (LOCAL_PREF, MED) tweaking q Performance ultimately limited by the single path q 1 B B 1 A A 1 2 C D 2 1 1 4 A E B 1 2 D E 1 2 Links AB and overloaded C BD are Links AC Cand CD arenot overloaded Can do this with SP routing! Rensselaer Polytechnic Institute 8 Shivkumar Kalyanaraman

The Questions Can we do multi-path & explicit routing ? q without signaling (I. e. in a connectionless context) q without variable (and large) per-packet overhead q being backward compatible with OSPF & BGP q allowing incremental network upgrades q Non-Goals: Monitoring, Traffic trunking/mapping q Traffic Engineering (TE) Spectrum Shortest Path … MPLS BANANAS-TE Signaled TE Rensselaer Polytechnic Institute 9 Shivkumar Kalyanaraman

Outline q Motivation: Best-effort path multiplicity q BANANAS: Data-plane q BANANAS: Control-plane q BANANAS: Mapping to BGP q Performance Results Rensselaer Polytechnic Institute 10 Shivkumar Kalyanaraman

Big Picture: How does it fit? Multi-paths within a routing domain Rensselaer Polytechnic Institute 11 Shivkumar Kalyanaraman

Detour: What can we learn from ATM and MPLS ? q MPLS label = Path identifier at each hop q Labels is a local identifier… q Signaling maps global identifiers (addresses, path specifications) to local identifiers Seattle New York (Egress) San Francisco (Ingress) IP 0 IP 1321 IP 120 1321 120 5 Miami IP Label Rensselaer Polytechnic Institute 12 Shivkumar Kalyanaraman

Global Path Identifiers? q Instead of using local path identifiers (labels in MPLS), consider the use of “global” path identifiers q q q Constructed out of global variables a node already knows! Eg: Link/Router IP addrs, Link weights, ASNs, Area Ids, GPS location Avoid the need for signaling to establish a mapping! Seattle 5 New York (Egress) 4 San Francisco (Ingress) 4 18 10 IP 36 27 IP 3 1 IP 0 IP 27 9 Miami 5 IP Rensselaer Polytechnic Institute 13 Path. Id Shivkumar Kalyanaraman

Global Path Identifier: Key Ideas IP i 2 w 1 Path. Id(1, j) k 1 IP wm j m-1 Path. Id(i, j) Key ideas (take-home!): 1. Global pathids (computed from global variables) instead of local labels! 2. Avoid inefficient path encoding (IP) AND 3. Avoid signaling (MPLS) 4. Incrementally deployable: w/ control-plane modifications Rensselaer Polytechnic Institute 14 Shivkumar Kalyanaraman

Global Path Identifier (continued) i w 2 w 1 wm 2 m-1 1 x k th Pa q j fi suf Path = {i, w 1, 1, w 2, 2, …, wk, k, wk+1, … , wm, j} q Sequence of globally known node IDs & Link weights q Global Path. ID: hash of this sequence: computable w/o signaling! Canonical method: MD 5 hashing of the subsequence of node. IDs followed by a CRC-32 to get a 32 -bit hash value (MD 5+CRC) q. Low collision (i. e. non-uniqueness) probability q q Note: Different Path. ID encodings have different architectural implications Rensselaer Polytechnic Institute 15 Shivkumar Kalyanaraman

Abstract Forwarding Paradigm q q Forwarding table (Eg; at Node k): q [Destination Prefix, Path. ID ] [Next-Hop, Suffix. Path. ID ] q [j, H{k, k+1, … , m-1} ] [k+1, H{k+1, … , m-1} ] Packet Header: [j, H{k, k+1, … , m-1} ] [j, H{k+1, … , m-1} ] i w 2 w 1 wm 2 j m-1 1 k th Pa Rensselaer Polytechnic Institute 16 f suf ix Shivkumar Kalyanaraman

BANANAS TE: Partial Deployment q Only red nodes are upgraded q “Virtual hop” between upgraded nodes q Black nodes compute single-shortest-path Seattle 5 New York (Egress) 4 10 San Francisco (Ingress) 1 IP 27 30 1 9 2 3 Rensselaer Polytechnic Institute 4 28 IP 27 IP 0 X Miami 1 IP 27 17 Shivkumar Kalyanaraman

Outline q Motivation: Best-effort path multiplicity q BANANAS: Data-plane q BANANAS: Control-plane q BANANAS: Mapping to BGP q Performance Results Rensselaer Polytechnic Institute 18 Shivkumar Kalyanaraman

Baseline: Route Computation Strategy q 1 -bit in LSA: node is “multi-path capable” (MPC) q Two phase algorithm: (m upgraded nodes) q 1. (N-m) Dijkstra’s for non-upgraded nodes q 2. DFS to discover valid paths to destinations. q Computes all valid paths partial-upgrade (PU) constraints q Problem: inflexible and complex! Rensselaer Polytechnic Institute 19 Shivkumar Kalyanaraman

Route Computation: Flexibility 5 A 2 1 B 2 D 3 C 5 1 3 2 1 E F 2 q Eg: k shortest-paths instead of DFS q Issue: Forwarding for k-shortest paths may not exist q Need to validate the forwarding availability for paths! q Idea: A path is valid only if its path suffixes are valid. q 2 -phase validation algorithm provided in BANANAS Rensselaer Polytechnic Institute 20 ( complexity) Shivkumar Kalyanaraman

Implementation: OSPF LSA Extensions Rensselaer Polytechnic Institute 21 Shivkumar Kalyanaraman

Architectural Flexibility: Placement of Functions q q Architecture = placement of functions BANANAS functions: q Data-plane = hash processing q Control-plane = route computation Goal: Move functions from the core to the edges Recall: Different Path. ID encodings have different architectural implications Link Indices Rensselaer Polytechnic Institute Path. ID = concatenation of link indexes 22 Path. ID processing: bit shifting! Shivkumar Kalyanaraman

Outline q Motivation: Best-effort path multiplicity q BANANAS: Data-plane q BANANAS: Control-plane q BANANAS: Mapping to BGP q Performance Results Rensselaer Polytechnic Institute 23 Shivkumar Kalyanaraman

Big Picture: How does it Fit Multi-AS-paths across domains W/o specifying intra-domain paths Rensselaer Polytechnic Institute Multiple exits from an AS w/o specifying intra-domain paths 24 Shivkumar Kalyanaraman

Explicit-Exit Routing: Concept AS 2 ASBR 1 ASBR 4 AS 4 ABR 2 ASBR 2 ABR 1 Dest. d AS 3 ASBR 3 AS 1 q q q Upgraded IBGP & EBGP nodes synchronize on a set of exits for prefixes IBGP locally installs explicit exit(s) for chosen prefix Packet tunneled to explicitly chosen exit (like MPLS stacking) Rensselaer Polytechnic Institute 25 Shivkumar Kalyanaraman

BGP Explicit-Exit Routing: Details q IBGP Table: q Dest-Prefix Exit-ASBR Next-Hop q Dest-Prefix Default-Next-Hop q When a packet matches the explicit route (policy definable): q Push destination address q Replace with Exit-ASBR address. q Exit-ASBR pops destination address q 1 -level label-stacking (a. k. a connectionless tunneling) Note: address stacking/tunneling is a different realization of the BANANAS hashing concept q Rensselaer Polytechnic Institute 26 Shivkumar Kalyanaraman

Inter-AS Explicit AS-Path Choice AS 0 AS 2 ASBR 1 ASBR 2 AS 1 ASBR 3 AS 4 Dest. d AS 3 Caveat: this requires more coordination across ISPs and control traffic (control-plane penalty)! Rensselaer Polytechnic Institute 27 Shivkumar Kalyanaraman

Outline q Motivation: Best-effort path multiplicity q BANANAS: Data-plane q BANANAS: Control-plane q BANANAS: Mapping to BGP q Performance Results Rensselaer Polytechnic Institute 28 Shivkumar Kalyanaraman

Simulation/Implementation/Testing Platforms MIT’s Click Modular Router On Linux: Forwarding Plane Modular Utah’s Emulab Testbed: Experiments with Linux/Zebra/Click implementation Rensselaer Polytechnic Institute Router SSFnet Simulation for OSPF/BGP Dynamics 29 Shivkumar Kalyanaraman

Putting It Together: Integrated OSPF/BGP Simulation Rensselaer Polytechnic Institute 30 Shivkumar Kalyanaraman

Blow-up of AS 2’s Internal Topology Rensselaer Polytechnic Institute 31 Shivkumar Kalyanaraman

E-Path. ID Processing Rensselaer Polytechnic Institute 32 Shivkumar Kalyanaraman

FORWARDING Table in AS 2 (node#5) Corresponding Changes in Packet Headers Rensselaer Polytechnic Institute 33 Shivkumar Kalyanaraman

Summary q q q Goals: q Best-effort path multiplicity: q MPLS-like features in OSPF, IS-IS and BGP q Overlay routing (Planetlab deployment) Non-Goals: Performance monitoring, traffic trunking & mapping to paths BANANAS Framework: q Data-Plane: Hash = Global Path. ID => NO SIGNALING q Control-plane: route computation algos (partial upgrade constraints) q Architectural Flexibility, incrementally deployable Traffic Engineering Shortest Path … MPLS BANANAS-TE Signaled TE Rensselaer Polytechnic Institute 34 Shivkumar Kalyanaraman

Multiplicity: Take-Home Message… Multiple E 2 E Flows Multi-homed interfaces & ISP/AS peers Multi-paths within a routing domain Multi-AS-paths across domains W/o specifying intra-domain paths Rensselaer Polytechnic Institute Multiple exits from an AS w/o specifying intra-domain paths 35 Shivkumar Kalyanaraman

EXTRA SLIDES Rensselaer Polytechnic Institute 36 Shivkumar Kalyanaraman

Acknowledgements Biplab Sikdar (faculty colleague) q Mehul Doshi (MS) q Niharika Mateti (MS) q Also thanks to: q Satish Raghunath (Ph. D) q Jayasri Akella (Ph. D) q Hemang Nagar (MS) q q Work funded in part by DARPA-ITO, NMS Program. Contract number: F 30602 -00 -2 -0537, Intel, AT&T Rensselaer Polytechnic Institute 37 Shivkumar Kalyanaraman

Multiple Areas Area 1 Area 2 5 B 1 C 2 1 7 2 D 1 ABR 1 4 3 ABR 4 1 2 A Red nodes: upgraded Green nodes: regular Area 0 1 2 ABR 2 4 G 5 1 2 3 4 7 1 H 2 4 2 ABR 3 5 2 J I 1 ABR 5 q q Path. ID re-initialized after crossing area boundaries Source-routing notion similar to, but weaker than PNNI Rensselaer Polytechnic Institute 38 Shivkumar Kalyanaraman

Why is the Index-based Encoding Interesting? q Ans: Architectural flexibility q Core (interior) nodes: q Forwarding function simplified q Minimal state (only the index table) q No control-plane computation complexity at interior nodes q Edge nodes: q Path validation simplified q Edge-nodes can store an arbitrary subset of validated paths q Heterogeneous route computation algorithms can be used Rensselaer Polytechnic Institute 39 Shivkumar Kalyanaraman

Path Multiplicity q Internet routing protocols designed for “best-effort” reachability, has implicitly meant “single end-to-end path” q q q Internet topology (level of hosts, routers, AS’es) is not a tree: multi-homing and multi-path availability Path multiplicity available in several contexts: q q q Why cannot the concept of “best-effort” allow path-multiplicity ? layer 3 (eg: OSPF, BGP, ad-hoc network routing), or layer 4 -7 (eg: overlay networks, peer-to-peer networks) Path multiplicity offers the potential for spatio-temporal statistical multiplexing gains q q Packet switching offered temporal stat-muxing gains over ckt switching Gains may vary in different contexts (eg: ad-hoc networks where capacity is shared network wide) Rensselaer Polytechnic Institute 40 Shivkumar Kalyanaraman

Zebra/Click Implementation on Linux (Tested on Utah Emulab) 75 13 53 3 9 45 51 4 83 2 7 93 38 5 5 q 4 3 1 67 6 21 51 67 1 0 8 Part of table at node 1: (Path. ID= Link Weights, for simplicity) Destination Path. ID Next. Hop Suffix. Path. ID 4 260 2 177 (=260 – 83) 4 98 3 0 (= 98 – 98) 4 51 4 0 (= 51 – 51) 4 160 5 0 (=160 – 160) Rensselaer Polytechnic Institute 41 Shivkumar Kalyanaraman

Linux/Zebra/Emulab Results Active Avg. # of Paths to Nodes each Dest B(k=3) 2. 94 D(k=3) 2. 94 C(k=3) 2. 79 Avg. # of Paths/k *100 B D C 98% 93% D Active Avg. # of Paths to Nodes each Dest B(k=5) 4. 83 D(k=5) 4. 78 C(k=5) 4. 44 Avg. # of Paths/k *100 B D C B 97% 96% 89% Active Avg. # of Paths to Nodes each Dest B(k=7) 6. 5 D(k=5) 4. 78 C(k=5) 4. 44 Avg. # of Paths/k *100 C B D C 93% 96% 89% Flat OSPF Area, 3 Active-MPC nodes; Upto k-shortest, validated paths Rensselaer Polytechnic Institute 42 Shivkumar Kalyanaraman

Path Validation Algorithm q q Concept: A path is VALID only if its path suffixes are valid. Phase 1 (cont’d): q compute {k-shortest} paths for all other upgraded nodes, and 1 -shortest paths for non-upgraded nodes. q Sort computed paths by hopcount Phase 2: Validate paths starting from hopcount = 1. q All 1 -hop paths valid. q p-hop paths valid if the (p-1)-hop path suffix is valid q Throw out invalid paths as they are found Polynomial complexity to discover valid paths q Proof by mathematical induction Rensselaer Polytechnic Institute 43 Shivkumar Kalyanaraman

BANANAS TE: Explicit, Multi-Path Forwarding q Explicit source-directed routing: Not limited by the shortest path nature of IGP q Different Path. Ids => different next-hops (multi-paths) q No signaling required to set-up the paths Traffic mapping is decoupled from route discovery IP 0 Seattle IP 5 IP San Francisco (Ingress) 10 IP 36 5 New York (Egress) 4 4 18 27 q 3 1 IP 0 9 IP 27 Miami 5 IP Rensselaer Polytechnic Institute 44 Path. Id Shivkumar Kalyanaraman