1 / 44

BANANAS: An Evolutionary Framework for Explicit and Multipath Routing in the Internet

5. 3. 5. 2. 1. 2. 3. 1. 2. 2. 1. A. B. C. F. E. D. BANANAS: An Evolutionary Framework for Explicit and Multipath Routing in the Internet. Hema T. Kaur, S. Kalyanaraman, A. Weiss, S. Kanwar, A. Gandhi Rensselaer Polytechnic Institute

elma
Download Presentation

BANANAS: An Evolutionary Framework for Explicit and Multipath Routing in the Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 5 3 5 2 1 2 3 1 2 2 1 A B C F E D BANANAS: An Evolutionary Framework for Explicit and Multipath Routing in the Internet 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

  2. In case you were wondering… BANANAS is not an acronym Just something to remember this by…

  3. Outline • Motivation: Best-effort path multiplicity • BANANAS: Data-plane • BANANAS: Control-plane • BANANAS: Mapping to BGP • Performance Results

  4. ISP-1 Internet . . . AS1 ISP-n Motivation: Best-EffortPath Multiplicity Phone modem USB/802.11a/b 802.11a Firewire/802.11a/b WiFi (802.11b) Ethernet

  5. Multiple E2E 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 specifying intra-domain paths Multiplicity: Flows, Paths, Exits/Interfaces BANANAS: A Single Abstract Framework To Exploit These Forms of Multiplicity In the Internet and Future Networks

  6. Isn’t multi-path routing an old subject? • Lots of old work: • 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: • Traffic engineering (reliability, availability, survivability, re-route): • Separation of traffic trunking from route selection • Packet level or aggregate (micro-flow or macro-flow level) • Security • Best-effort e2e service composition… Why hasn’t it happened after 2 decades of work?

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

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

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

  10. Outline • Motivation: Best-effort path multiplicity • BANANAS: Data-plane • BANANAS: Control-plane • BANANAS: Mapping to BGP • Performance Results

  11. Multi-paths within a routing domain Big Picture: How does it fit?

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

  13. Seattle 5 New York (Egress) 4 4 18 IP 27 3 10 San Francisco (Ingress) 1 9 Miami 5 IP IP IP IP 27 36 0 PathId Global Path Identifiers? • Instead of using local path identifiers (labels in MPLS), consider the use of “global” path identifiers • 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!

  14. IP IP PathId(i,j) PathId(1,j) Global Path Identifier: Key Ideas j 2 k wm w2 i w1 m-1 1 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

  15. j 2 wm w2 i w1 m-1 1 k Path suffix Global Path Identifier (continued) • Path = {i, w1, 1, w2, 2, …, wk, k, wk+1, … , wm, j} • Sequence of globally known node IDs & Link weights • Global PathID: hash of this sequence: computable w/o signaling! • Canonical method: MD5 hashing of the subsequence of nodeIDs followed by a CRC-32 to get a 32-bit hash value (MD5+CRC) • Low collision (i.e. non-uniqueness) probability • Note: Different PathID encodings have different architectural implications

  16. PathID SuffixPathID H{k, k+1, … , m-1} H{k+1, … , m-1} j 2 wm w2 i w1 m-1 1 k Path suffix Abstract Forwarding Paradigm • Forwarding table (Eg; at Node k): • [Destination Prefix, ]  [Next-Hop, ] • [j, ]  [k+1, ] • Packet Header: [j, H{k, k+1, … , m-1} ]  [j, H{k+1, … , m-1} ]

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

  18. Outline • Motivation: Best-effort path multiplicity • BANANAS: Data-plane • BANANAS: Control-plane • BANANAS: Mapping to BGP • Performance Results

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

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

  21. Implementation: OSPF LSA Extensions

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

  23. Outline • Motivation: Best-effort path multiplicity • BANANAS: Data-plane • BANANAS: Control-plane • BANANAS: Mapping to BGP • Performance Results

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

  25. AS2 ASBR1 ASBR4 AS4 Dest. d ABR2 ASBR2 ABR1 AS3 ASBR3 AS1 Explicit-Exit Routing: Concept • 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)

  26. When a packet matches the explicit route (policy definable): • Push destination address • Replace with Exit-ASBR address. • Exit-ASBR pops destination address • 1-levellabel-stacking (a.k.a connectionlesstunneling) • Note: address stacking/tunneling is a different realization of the BANANAS hashing concept BGP Explicit-Exit Routing: Details • IBGP Table: • Dest-Prefix Exit-ASBR Next-Hop • Dest-Prefix Default-Next-Hop

  27. AS0 AS2 ASBR1 AS4 Dest. d ASBR2 AS3 AS1 ASBR3 Inter-AS Explicit AS-Path Choice Caveat: this requires more coordination across ISPs and control traffic (control-plane penalty)!

  28. Outline • Motivation: Best-effort path multiplicity • BANANAS: Data-plane • BANANAS: Control-plane • BANANAS: Mapping to BGP • Performance Results

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

  30. Putting It Together: Integrated OSPF/BGP Simulation

  31. Blow-up of AS2’s Internal Topology

  32. E-PathID Processing

  33. FORWARDING Table in AS2 (node#5) Corresponding Changes in Packet Headers

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

  35. Multiple E2E 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 specifying intra-domain paths Multiplicity: Take-Home Message…

  36. EXTRA SLIDES

  37. Acknowledgements • Biplab Sikdar (faculty colleague) • Mehul Doshi (MS) • Niharika Mateti (MS) • Also thanks to: • Satish Raghunath (PhD) • Jayasri Akella (PhD) • Hemang Nagar (MS) • Work funded in part by DARPA-ITO, NMS Program. Contract number: F30602-00-2-0537, Intel, AT&T

  38. Area 1 Area 2 5 Area 0 1 1 3 2 5 5 4 1 2 3 1 7 4 A H D G J B C I ABR1 ABR3 ABR4 ABR2 ABR5 2 1 7 2 2 2 2 1 1 4 1 4 2 Multiple Areas • PathID re-initialized after crossing area boundaries • Source-routing notion similar to, but weaker than PNNI Red nodes: upgraded Green nodes: regular

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

  40. Path Multiplicity • Internet routing protocols designed for “best-effort” reachability, has implicitly meant “single end-to-end path” • Why cannot the concept of “best-effort” allow path-multiplicity ? • Internet topology (level of hosts, routers, AS’es) is not a tree: multi-homing and multi-path availability • Path multiplicity available in several contexts: • 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 • 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)

  41. Zebra/Click Implementation on Linux (Tested on Utah Emulab) • Part of table at node1: (PathID= Link Weights, for simplicity) 75 13 3 9 6 21 4 53 45 51 83 3 4 1 2 7 93 38 67 51 5 67 5 10 8

  42. Linux/Zebra/Emulab Results B D C Flat OSPF Area, 3 Active-MPC nodes; Upto k-shortest, validated paths

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

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

More Related