1 / 39

BANANAS: A Connectionless Approach to Intra- and Inter-Domain Traffic Engineering

BANANAS: A Connectionless Approach to Intra- and Inter-Domain Traffic Engineering. Hema T. Kaur, Shiv Kalyanaraman, Rensselaer Polytechnic Institute hema@networks.ecse.rpi.edu , shivkuma@ecse.rpi.edu http://www.ecse.rpi.edu/Homepages/shivkuma. Acknowledgements.

jonah
Télécharger la présentation

BANANAS: A Connectionless Approach to Intra- and Inter-Domain Traffic Engineering

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. BANANAS: A Connectionless Approach to Intra- and Inter-Domain Traffic Engineering Hema T. Kaur, Shiv Kalyanaraman, Rensselaer Polytechnic Institute hema@networks.ecse.rpi.edu, shivkuma@ecse.rpi.edu http://www.ecse.rpi.edu/Homepages/shivkuma

  2. Acknowledgements • Biplab Sikdar (faculty colleague) • Andreas Weiss (MS) • Shifalika Kanwar (MS) • Mehul Doshi (MS) • Ayesha Gandhi (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

  3. TE Spectrum … Shortest Path MPLS Signaled TE BANANAS-TE The Question • Can we emulate a subset of MPLS properties without signaling? • Key: Can we do source routing ? • without signaling • without variable per-packet overhead • being backward compatible with OSPF & BGP • allowing incremental network upgrades

  4. 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 OSPF 1 2 A C C Why cannot we do it today? • Connectionless TE today uses a parametric approach: • Eg: changing link weights in OSPF, IS-IS or parameters of BGP-4 (LOCAL_PREF, MED etc) • Performance limited by the single shortest/policy path • Alt: Connection-oriented/signaled approach (eg: MPLS) • Complex to extend MPLS-TE across multiple areas. • Not a solution for inter-AS issues. • MPLS also needs the support of all the nodes along the path

  5. IP IP IP IP Label 0 120 1321 MPLS Signaling and Forwarding Model • MPLS label is swapped at each hop along the LSP • Labels = LOCAL IDENTIFIERS … • Signaling maps global identifiers (addresses, path spec) to local identifiers Seattle New York (Egress) 5 San Francisco (Ingress) 1321 120 Miami

  6. 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), we propose the use of global path identifiers

  7. 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: 1. Swap global pathids instead of local labels! 2. Unlike source-routing that is simple (IP) or signaled (MPLS), upgraded intermediate nodes need to locally compute the valid PathIDs.

  8. 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 Path ID is a hash of this sequence => locally computable without the need for signaling! • Potential hash functions: • [j, { h(1) + h(2) + …+h(k)+ … +h(m-1)} mod 2b ]: node ID sum • MD5 one-way hash, XOR, 32-bit CRC etc… • We propose the use of MD5 hashing of the subsequence of nodeIDs followed by a CRC-32 to get a 32-bit hash value • Very low collision (i.e. non-uniqueness) probability

  9. 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, ] • Incoming Packet Hdr: Destination address (j) & PathID = H{k, k+1, … , m-1} • Outgoing Packet Hdr: [j, PathID =H{k+1, … , m-1} ] • Longest prefix match + exact label match + label swap! • PathID mismatch => map to shortest (default) path, and set PathID = 0 • No signaling because of globally meaningful pathIDs!

  10. 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 splitting is decoupled from route computation Seattle 5 New York (Egress) 4 4 18 IP 3 10 San Francisco (Ingress) 1 9 Miami 5

  11. IP IP IP IP IP IP 27 27 27 0 0 5 BANANAS TE: Partial Deployment • Only “red” routers are upgraded • Non-upgraded routers forward everything on the shortest path (default path): forming a “virtual hop” Seattle 5 New York (Egress) 4 4 28 IP 27 30 10 San Francisco (Ingress) 1 9 1 X 2 Miami 3 1

  12. Route Computation: All-Paths Under Partial Upgrades (AP-PU) • Assume 1-bit in LSA’s to advertise that an upgraded router is “multi-path capable” (MPC) • Two phase algorithm: (assume m upgraded nodes) • 1. (N-m) Dijkstra’s for non-upgraded nodes or one all-pairs shortest path (Floyd Warshall) • 2. DFS to discover valid paths to destinations. • Explore all neighbors of upgraded nodes • Explore only shortest-path next-hop of non-upgraded nodes • Visited bit set to avoid loops • Computes all possible valid paths under PU constraints in a fully distributed manner (global consistency)

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

  14. SSFnet Simulation Results A B E C D Flat OSPF Area, 19 Nodes; Only 3 Active-MPC nodes

  15. 5 3 5 2 1 2 3 A D F B C E 1 2 2 1 Heterogeneous Route Computation • Goal: Upgraded nodes (eg: A, D, E) can use any route computation algorithm, so long as it computes the shortest (default) path! • Eg: k shortest-paths from a given source s to each vertex in the graph, in total time O(E + V log V + kV): lower complexity than AP-PU • Issue: Forwarding for k-shortest paths may not exist • Need to validate the forwarding availability for paths!

  16. Two-Phase Path Validation Algorithm • Concept: Forwarding for path exists only if the forwarding for each of its suffixes exists. • 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 all valid paths in the network & validation can be done in the background • Validation algorithm correct by mathematical induction

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

  18. Inter-domain TE • Outbound TE: • Multi-exit (or Explicit-exit) routing • Useful to manage peering vs transit costs • Hash = (Exit ASBR, destination address) • Forwarding paradigm: Connectionless tunneling thru the AS • Inbound TE: • NOT ADDRESSED DIRECTLY • Multi-AS-Path or Explicit AS-Path routing: • Framework similar to IGP: e-PathID concept

  19. Upgrade selected EBGP and IBGP routers • All BGP routers synchronize on the default policy route to every destination prefix (as usual) • Only upgraded IBGP routers and EBGP routers synchronize on a set of exits for chosen prefixes • Upgraded IBGP routers can independently choose any exit without further synchronization with other BGP nodes BGP Explicit-Exit Routing: Route Selection • Explicit-Exit routing is easier than Explicit-Path Routing • Only the “source” and “exit” nodes need upgrades ! • Explicit exit routing easily extended to “multi-exit” routing

  20. When a packet matches the explicit route (policy definable): • Push its destination address into an Address Stack field • Replace destination address with Exit-ASBR address. • Emulates 1-levellabel-stacking (I.e. tunneling) • Exit-ASBR simply swaps back the destination address, before regular IP lookup => popping the stack BGP Explicit-Exit Routing: Forwarding • IBGP locally installs explicit & default exits for chosen prefix • Dest-Prefix Exit-ASBR Next-Hop • Dest-Prefix Default-Next-Hop • Next-hop refers to the IGP next hop to reach Exit-ASBR • Default-Next-Hop: regular IBGP function

  21. AS2 ASBR1 ASBR4 AS4 Dest. d ABR2 ASBR2 ABR1 AS3 ASBR3 AS1 Explicit-Exit Routing Example • Default (AS Path , Exit) to d = (1-3-4, ASBR3) • Now, ABR1 can have explicit exits ASBR4 (implied ASPath = 1-2-4), ASBR2 (implied ASPath =1-3-4) as well!!

  22. AS0 AS2 ASBR1 AS4 Dest. d ASBR2 AS3 AS1 ASBR3 Inter-AS Explicit AS-Path Choice • Allow AS0 to explicitly choose an AS-PATH: e.g. 0-1-2-4 or 0-1-3-4, • Explicit AS-Path choice encoded as an e-PathID= Hash{1,2,4} • e-PathID is updated only when the packet leaves the AS at Exit border routers. • At ASBR1, this explicit AS-path choice is mapped to an exit ASBR. • Within an upgraded AS, the packet is tunneled using the routing header as explained earlier. • Only selected EBGP nodes need be upgraded & synchronized

  23. AS5 3 AS-paths to “d” (0 4) (0 3 4) (0 5 4) AS2 AS0 ASBR2 ASBR1 AS4 Dest. d 1 AS-path or 3 AS-paths to “d”?? AS1 AS3 iBG-1 iBG-3 Re-advertisements of Multi-AS-Paths • Issue: in path-vector algorithms, without re-advertisements (of a subset of paths), remote AS’s cannot see the availability of multiple paths • But, re-advertisements adds control traffic overhead • An AS may choose to re-advertise only, and not support multi-path forwarding (I.e. interpreting e-PathID or Address Stack fields)

  24. Signaled TE BANANAS-TE Summary • TE: “TowardsBetter routing performance”: • Key: Decoupling route availabilityand setup issues from traffic mapping issues, without signaling • BANANAS-TE can leverage the rich interconnectivity and multi-homed nature of the Internet, with manageable increase in complexity TE spectrum … Shortest Path MPLS

  25. Extra Slides

  26. BGP Explicit Exit: SSFnet Simulation Example

  27. AS 4 0.0.0.56/29 2 1 3 2 1 0.0.0.0/27 AS 2 4 0.0.0.32/28 2 0.0.0.48/29 1 2 AS 3 AS 5 1 3

  28. AS 2 Outgoing Packet from AS2 router 1 18/32 3 14//32 17/32 12/32 94/32 2 1 1/32 10/32 2/32 16/32 4 Forwarding Table@ AS2 (Router 1) Dest address is pushed to stack @ AS2 (1); like MPLS => tunneling emulation!

  29. 3 14//32 18/32 17/32 2 12/32 Outgoing packet from AS2 router 2 1 16/32 1/32 10/32 2/32 94/32 4 42/32 2 AS 2 90/32 33/32 1 Forwarding Table@ AS2 (Router 2) 38/32 AS 3 Destination address is popped back from Address Stack at AS2 (2)

  30. AS 4 0.0.0.56/29 AS1-AS2-AS4-AS3-AS5 2 1 0.0.0.64/29 1 AS 1 3 2 0.0.0.0/27 1 AS 2 4 2 1 0.0.0.48/29 2 AS 3 1 AS 5 3 0.0.0.32/28

  31. AS1-AS2-AS4-AS3-AS5 AS 1 1 Outgoing Packet at 1 of AS1 Upgraded 3 Upgraded AS 2 18/32 14//32 5/32 2 1 94/32 11/32 22/32 16/32 1/32 2/32 10/32 4 Forwarding Table at Router 1 ofAS1

  32. AS1-AS2-AS4-AS3-AS5 AS 1 1 Outgoing Packet at 1 of AS2 Upgraded 3 Upgraded 18/32 14//32 5/32 2 12/32 1 94/32 11/32 22/32 16/32 1/32 2/32 10/32 AS 2 4 Forwarding Table at Router 1 of AS2

  33. AS1-AS2-AS4-AS3-AS5 0.0.0.56/29 *-- ePathID = Hash(3-5 )instead of 4-3-5 *Alternatively -- ePathID = 0 81/32 2 1 83/32 86/32 Non Upgraded Outgoing Packet at 3 of AS2 AS 4 3 Upgraded 18/32 14//32 5/32 2 12/32 17//32 1 94/32 11/32 22/32 16/32 1/32 2/32 10/32 AS 2 Forwarding Table at Router 3 of AS2

  34. AS1-AS2-AS4-AS3-AS5 2 87/32 81/32 42/32 1 90/32 83/32 33/32 1 AS 4 37/32 AS 3 Non Upgraded 38/32 3 Upgraded *Outgoing Packet from router 1 & 2 of AS4 *No change in ePathID Forwarding Table at Router 1 of AS4 Forwarding Table at Router 2 of AS4

  35. AS1-AS2-AS4-AS3-AS5 2 0.0.0.32/28 0.0.0.48/29 2 42/32 85/32 58/32 90/32 33/32 77/32 1 1 37/32 AS 5 38/32 AS 3 Non Upgraded 3 Upgraded Incoming and Outgoing Packet from Router 2 of AS3 Forwarding Table at Router 2 of AS3

  36. AS1-AS2-AS4-AS3-AS5 0.0.0.32/28 2 0.0.0.48/29 2 42/32 85/32 58/32 90/32 33/32 1 77/32 1 37/32 AS 5 38/32 AS 3 Non Upgraded 3 Upgraded Outgoing Packet from Router 3 of AS3 Forwarding Table at Router 3 of AS3

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

  38. Managing Complexity: Active/Passive MPC Routers • Issue: DFS computation complexity and number of paths grow exponentially as a function of MPC nodes • Solution 1: • Divide upgraded routers into two sets: Passive MPC routers (P-MPC) and Active MPC (A-MPC) • Only A-MPC routers set the MPC bit in LSAs • Effectivemaximum number of MPC routers “seen” = Number of A-MPC routers + 1 • Even a few A-MPC routers makes appreciable number of paths available in the network! • P-MPCs (eg: edge-routers) could act as “sources”

  39. Router LSA Modifications MPC-Bit: Unused Bit #7 of options ki value used at router i: Unused 8 Bits after Router Type (reproduced from John Moy’s OSPF book)

More Related