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

1
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_at_networks.ecse.rpi.edu, shivkuma_at_ecse.rpi.edu
• http//www.ecse.rpi.edu/Homepages/shivkuma

Sponsors DARPA-NMS, NSF, Intel, ATT
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
Motivation Best-Effort Path Multiplicity
USB/802.11a/b
Phone modem
802.11a
Firewire/802.11a/b
WiFi (802.11b)
Ethernet
5
Multiplicity Flows, Paths, Exits/Interfaces
BANANAS A Single Abstract Framework To Exploit
These Forms of Multiplicity In the Internet and
Future Networks
6
Isnt 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 hasnt 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/semanti
  cs
• Different placement of functions (edge vs core)
• Tunneling/Label Stacking
• Geographic/Trajectory routing

8
Limits of Connectionless Traffic Engg (OSPF/BGP)

• State-of-the-art parameter tweaking
• OSPF, IS-IS Link weight tweaking or
• BGP-4 parameter (LOCAL_PREF, MED) tweaking
• Performance ultimately limited by the single
  path

9
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
Big Picture How does it fit?
12
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
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
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
Global Path Identifier (continued)

• Path i, w1, 1, w2, 2, , wk, k, wk1, , 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 (MD5CRC)
• Low collision (i.e. non-uniqueness) probability
• Note Different PathID encodings have different
  architectural implications

16
Abstract Forwarding Paradigm

• Forwarding table (Eg at Node k)
• Destination Prefix, ? Next-Hop,
• j, ? k1,

• Packet Header
• j, Hk, k1, , m-1 ?

j, Hk1, , m-1
17
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) Dijkstras 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
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
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
Big Picture How does it Fit
25
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
BGP Explicit-Exit Routing Details

• IBGP Table
• Dest-Prefix Exit-ASBR Next-Hop
• Dest-Prefix Default-Next-Hop

27
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
MITs Click Modular Router On Linux Forwarding
Plane
Modular
Router
Utahs 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 AS2s Internal Topology
32
E-PathID Processing
33
FORWARDING Table in AS2 (node5)
Corresponding Changes in Packet Headers
34
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 gt NO SIGNALING
• Control-plane route computation algos (partial
  upgrade constraints)
• Architectural Flexibility, incrementally
  deployable

35
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, ATT

38
Multiple Areas
Red nodes upgraded Green nodes regular

• PathID re-initialized after crossing area
  boundaries
• Source-routing notion similar to, but weaker than
  PNNI

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,
  ASes) 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)
75
13
3
9
6
53
4
21
45
51
83
3
7
4
1
2
93
38
67
51
5
67
5
8
10

• Part of table at node1 (PathID ?Link Weights,
  for simplicity)

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 (contd)
• 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
BANANAS TE Explicit, Multi-Path Forwarding

• Explicit source-directed routing Not limited by
  the shortest path nature of IGP
• Different PathIds gt 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