Title: BANANAS: An Evolutionary Framework for Explicit and Multipath Routing in the Internet
1BANANAS 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
2In case you were wondering BANANAS is not an
acronym Just something to remember this by
3Outline
- Motivation Best-effort path multiplicity
- BANANAS Data-plane
- BANANAS Control-plane
- BANANAS Mapping to BGP
- Performance Results
4Motivation Best-Effort Path Multiplicity
USB/802.11a/b
Phone modem
802.11a
Firewire/802.11a/b
WiFi (802.11b)
Ethernet
5Multiplicity Flows, Paths, Exits/Interfaces
BANANAS A Single Abstract Framework To Exploit
These Forms of Multiplicity In the Internet and
Future Networks
6Isnt 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?
7Missing 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
8Limits 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
9The 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
10Outline
- Motivation Best-effort path multiplicity
- BANANAS Data-plane
- BANANAS Control-plane
- BANANAS Mapping to BGP
- Performance Results
11Big Picture How does it fit?
12Detour 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
13Global 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!
14Global 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
15Global 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
16Abstract 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
17BANANAS 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
18Outline
- Motivation Best-effort path multiplicity
- BANANAS Data-plane
- BANANAS Control-plane
- BANANAS Mapping to BGP
- Performance Results
19Baseline 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!
20Route 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
21Implementation OSPF LSA Extensions
22Architectural 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
23Outline
- Motivation Best-effort path multiplicity
- BANANAS Data-plane
- BANANAS Control-plane
- BANANAS Mapping to BGP
- Performance Results
24Big Picture How does it Fit
25Explicit-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)
26BGP Explicit-Exit Routing Details
- IBGP Table
- Dest-Prefix Exit-ASBR Next-Hop
- Dest-Prefix Default-Next-Hop
27Inter-AS Explicit AS-Path Choice
Caveat this requires more coordination across
ISPs and control traffic (control-plane penalty)!
28Outline
- Motivation Best-effort path multiplicity
- BANANAS Data-plane
- BANANAS Control-plane
- BANANAS Mapping to BGP
- Performance Results
29Simulation/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
30Putting It Together Integrated OSPF/BGP
Simulation
31Blow-up of AS2s Internal Topology
32E-PathID Processing
33FORWARDING Table in AS2 (node5)
Corresponding Changes in Packet Headers
34Summary
- 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
35Multiplicity Take-Home Message
36EXTRA SLIDES
37Acknowledgements
- 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
38Multiple Areas
Red nodes upgraded Green nodes regular
- PathID re-initialized after crossing area
boundaries - Source-routing notion similar to, but weaker than
PNNI
39Why 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
40Path 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)
41Zebra/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)
Destination PathID NextHop SuffixPathID
4 260 2 177 (260 83)
4 98 3 0 ( 98 98)
4 51 4 0 ( 51 51)
4 160 5 0 (160 160)
42Linux/Zebra/Emulab Results
Active Nodes Avg. of Paths to each Dest
B(k3) 2.94
D(k3) 2.94
C(k3) 2.79
Avg. of Paths/k 100 Avg. of Paths/k 100
B 98
D 98
C 93
Active Nodes Avg. of Paths to each Dest
B(k5) 4.83
D(k5) 4.78
C(k5) 4.44
Avg. of Paths/k 100 Avg. of Paths/k 100
B 97
D 96
C 89
B
Active Nodes Avg. of Paths to each Dest
B(k7) 6.5
D(k5) 4.78
C(k5) 4.44
Avg. of Paths/k 100 Avg. of Paths/k 100
B 93
D 96
C 89
D
C
Flat OSPF Area, 3 Active-MPC nodes Upto
k-shortest, validated paths
43Path 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
44BANANAS 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