Transcript IP: Addresses and Forwarding

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
[email protected], [email protected]
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

Motivation: Best-effort path multiplicity

BANANAS: Data-plane

BANANAS: Control-plane

BANANAS: Mapping to BGP

Performance Results
Rensselaer Polytechnic Institute
3
Shivkumar Kalyanaraman
Motivation: Best-Effort Path Multiplicity
Phone modem
USB/802.11a/b
802.11a
WiFi (802.11b)
Ethernet
Firewire/802.11a/b
ISP-1
AS1
Internet
.
.
.
ISP-n
Rensselaer Polytechnic Institute
4
Shivkumar Kalyanaraman
Multiplicity: Flows, Paths, Exits/Interfaces
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/oTo
specifying
paths
BANANAS: A Single Abstract Framework
Exploit intra-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?

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?
Rensselaer Polytechnic Institute
6
Shivkumar Kalyanaraman
Missing Architectural Concepts

An evolutionary partial deployment strategy




Abstract enough to be applicable to other scenarios:


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)
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
Rensselaer Polytechnic Institute
7
Shivkumar Kalyanaraman
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

1
B
B
1
2
1
A
A
1
2
C
D
1
4
A
E
B
1
2
D
E
2
D
E
1
2
1
2
Links AB and
overloaded
C BD are
Links
AC Cand CD
Can
arenot
overloaded
do this with SP routing!
Rensselaer Polytechnic Institute
8
Shivkumar Kalyanaraman
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

Traffic Engineering (TE) Spectrum
Shortest Path
…
MPLS
BANANAS-TE
Signaled TE
Rensselaer Polytechnic Institute
9
Shivkumar Kalyanaraman
Outline

Motivation: Best-effort path multiplicity

BANANAS: Data-plane

BANANAS: Control-plane

BANANAS: Mapping to BGP

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 ?

MPLS label = Path identifier at each hop
 Labels is a local identifier…
 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?

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!
Seattle
New York
(Egress)
IP
San
Francisco
(Ingress)
IP 36
IP 0
IP 27
Miami
IP
Rensselaer Polytechnic Institute
13
PathId
Shivkumar Kalyanaraman
Global Path Identifier: Key Ideas
IP
i
2
w2
w1
PathId(1,j)
k
1
IP
wm
j
m-1
PathId(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
w2
w1
2
wm
j
m-1
1
k

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
Rensselaer Polytechnic Institute
15
Shivkumar Kalyanaraman
Abstract Forwarding Paradigm


Forwarding table (Eg; at Node k):
 [Destination Prefix, PathID ]  [Next-Hop, SuffixPathID ]
 [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
w2
w1
wm
2
j
m-1
1
k
Rensselaer Polytechnic Institute
16
Shivkumar Kalyanaraman
BANANAS TE: Partial Deployment

Only red nodes are upgraded
 “Virtual hop” between upgraded nodes
 Black nodes compute single-shortest-path
Seattle
New York
(Egress)
IP
San
Francisco
(Ingress)
27
IP 27
IP
0
X
Miami
IP
IP 27
Rensselaer Polytechnic Institute
17
27
Shivkumar Kalyanaraman
Outline

Motivation: Best-effort path multiplicity

BANANAS: Data-plane

BANANAS: Control-plane

BANANAS: Mapping to BGP

Performance Results
Rensselaer Polytechnic Institute
18
Shivkumar Kalyanaraman
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!
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

Eg: k shortest-paths instead of DFS

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
Rensselaer Polytechnic Institute
20
( complexity)
Shivkumar Kalyanaraman
Implementation: OSPF LSA Extensions
Rensselaer Polytechnic Institute
21
Shivkumar Kalyanaraman
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
Link Indices
Rensselaer Polytechnic Institute
PathID = concatenation
of link indexes
22
PathID processing:
bit shifting!
Shivkumar Kalyanaraman
Outline

Motivation: Best-effort path multiplicity

BANANAS: Data-plane

BANANAS: Control-plane

BANANAS: Mapping to BGP

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
AS2
ASBR1
ASBR4
AS4
ABR2
ASBR2
ABR1
Dest. d
AS3
ASBR3
AS1



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


IBGP Table:
 Dest-Prefix Exit-ASBR Next-Hop
 Dest-Prefix
Default-Next-Hop
When a packet matches the explicit route (policy definable):

Push destination address

Replace with Exit-ASBR address.

Exit-ASBR pops destination address

1-level label-stacking (a.k.a connectionless tunneling)
Note: address stacking/tunneling is a different realization of the
BANANAS hashing concept

Rensselaer Polytechnic Institute
26
Shivkumar Kalyanaraman
Inter-AS Explicit AS-Path Choice
AS0
AS2
ASBR1
ASBR2
AS1
AS4
Dest. d
AS3
ASBR3
Caveat: this requires more coordination across ISPs
and control traffic (control-plane penalty)!
Rensselaer Polytechnic Institute
27
Shivkumar Kalyanaraman
Outline

Motivation: Best-effort path multiplicity

BANANAS: Data-plane

BANANAS: Control-plane

BANANAS: Mapping to BGP

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 AS2’s Internal Topology
Rensselaer Polytechnic Institute
31
Shivkumar Kalyanaraman
E-PathID Processing
Rensselaer Polytechnic Institute
32
Shivkumar Kalyanaraman
FORWARDING Table in
AS2 (node#5)
Corresponding
Changes in
Packet
Headers
Rensselaer Polytechnic Institute
33
Shivkumar Kalyanaraman
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
Traffic Engineering
Shortest Path
…
MPLS
BANANAS-TE
Signaled TE
Rensselaer Polytechnic Institute
34
Shivkumar Kalyanaraman
Multiplicity: Take-Home Message…
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
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)
 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
Rensselaer Polytechnic Institute
37
Shivkumar Kalyanaraman
Multiple Areas
Area 1
Area 2
5
B
1
C
2
1
7
2
D
1
ABR1
4
3
ABR4
1
2
A
Red nodes: upgraded
Green nodes: regular
Area 0
1
2
ABR2 4
G
5
1
2
3
4
7
1
H
2
4
2 ABR3
5
2
J
I
1
ABR5


PathID 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?

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
Rensselaer Polytechnic Institute
39
Shivkumar Kalyanaraman
Path Multiplicity

Internet routing protocols designed for “best-effort”
reachability, has implicitly meant “single end-to-end path”



Internet topology (level of hosts, routers, AS’es) is not a tree: 
multi-homing and multi-path availability
Path multiplicity available in several contexts:



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


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
3
9
53
6
21
45
51
4
83
3
1
2
38
5
5

7
93
67
4
51
67
1
0
8
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)
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%
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




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
Rensselaer Polytechnic Institute
43
Shivkumar Kalyanaraman
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
IP 0
Seattle
IP
San
Francisco
(Ingress)
New York
(Egress)
IP 5
IP 36
IP 0
IP 27
Miami
IP
Rensselaer Polytechnic Institute
44
PathId
Shivkumar Kalyanaraman