Date post: | 19-Jan-2016 |
Category: |
Documents |
Upload: | tyler-anderson |
View: | 212 times |
Download: | 0 times |
Shivkumar KalyanaramanRensselaer Polytechnic Institute 1
BANANAS: An Evolutionary Framework for Explicit and Multipath Routing in the Internet
Hema T. Kaur, Shiv Kalyanaraman, Andreas Weiss, Shifalika Kanwar, Ayesha Gandhi
Rensselaer Polytechnic [email protected], [email protected]
http://www.ecse.rpi.edu/Homepages/shivkuma
A
ED
CB
F
2
2
1
3
1
1
2
53
5
2
Shivkumar KalyanaramanRensselaer Polytechnic Institute 2
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 Intel Corp and DARPA-ITO, NMS Program. Contract number: F30602-00-2-0537
Shivkumar KalyanaramanRensselaer Polytechnic Institute 3
The Question Can we emulate a subset of MPLS properties without signaling
in existing connectionless routing protocols?
Key: Can we do source routing ? without signaling without variable (and large) per-packet overhead being backward compatible with OSPF & BGP allowing incremental network upgrades
Shortest Path MPLS…
BANANAS-TE
Signaled TE
TE Spectrum
Shivkumar KalyanaramanRensselaer Polytechnic Institute 4
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
A
B
C
D
1
1 2
1
E
2
Can not do this with OSPFA
B
C
D
1
1 2
1
E
2
Links AB and BD are overloaded
A
B
C
D
1
1 2
4
E
2
Links AC and CD are overloaded
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
Shivkumar KalyanaramanRensselaer Polytechnic Institute 5
MPLS Signaling and Forwarding Model
Miami
Seattle
SanFrancisco(Ingress)
New York(Egress)
MPLS label is swapped at each hop along the LSP Labels = LOCAL IDENTIFIERS …
Signaling maps global identifiers (addresses, path spec) to local identifiers
1321
5
120
IP 1321
IP 120
IP 0
IPLabe
l
Shivkumar KalyanaramanRensselaer Polytechnic Institute 6
Global Path Identifiers
Instead of using local path identifiers (labels in MPLS), consider the use of global path identifiers
10
Miami
Seattle
9
27
SanFrancisco(Ingress)
New York(Egress)
18
1
5
4
3
5
IP
IP PathId
4
IP 36
IP 27
IP 0
Shivkumar KalyanaramanRensselaer Polytechnic Institute 7
Global Path Identifier: Key Ideas
ik j
m-11
2w1
w2
wm
IP PathId(i,j)
IP PathId(1,j)
Key ideas: 1. Swap/process global pathids hop-by-hop instead of local labels!2. Avoid inefficient encoding (IP) or signaling (MPLS)3. Only upgraded nodes need to locally compute a subset of valid PathIDs.
Shivkumar KalyanaramanRensselaer Polytechnic Institute 8
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 (eg: LIRA), 32-bit CRC etc… 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) probabilityDifferent PathID encodings have different architectural implications
i
k
j
m-11
2w1
w2
wm
Path su
ffix
Shivkumar KalyanaramanRensselaer Polytechnic Institute 9
Abstract Forwarding Paradigm Forwarding table (Eg; at Node k):
[Destination Prefix, ] [Next-Hop, ] [j, ] [k+1, ]
i
k
j
m-1
1
2w1
w2
wm
Path su
ffix
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 = 0No signaling because of globally meaningful pathIDs!
PathID SuffixPathID
H{k, k+1, … , m-1} H{k+1, … , m-1}
Shivkumar KalyanaramanRensselaer Polytechnic Institute 10
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
10
Miami
Seattle
9
27
SanFrancisco(Ingress)
New York(Egress)
18
1
5
4
3
5
IP
IP PathId
4IP 5
IP 0
IP 36IP 27
IP 0
Shivkumar KalyanaramanRensselaer Polytechnic Institute 11
BANANAS TE: Partial Deployment Only “red” routers are upgraded
Non-upgraded routers forward everything on the shortest path (default path): forming a “virtual hop”
10
Miami
Seattle
9SanFrancisco(Ingress)
New York(Egress)
28
1
5
4
30
1
IP
4IP 5
IP 0
IP 27
IP 0
27
1
3
2
IP 27
IP 27
X
Shivkumar KalyanaramanRensselaer Polytechnic Institute 12
Simplistic Route Computation Strategy: All-Paths Under Partial Upgrades
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)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 13
Simulation/Implementation/Testing Platforms
Utah’s Emulab Testbed: Experiments with
Linux/Zebra/Click implementation
MIT’s Click Modular RouterOn Linux:
Forwarding Plane
SSFnet Simulation for OSPF/BGP Dynamics
Modular Router
Shivkumar KalyanaramanRensselaer Polytechnic Institute 14
Zebra/Click Implementation on Linux (Tested on Utah Emulab)
Part of table at node1: (PathID= Link Weights, for simplicity)
3 9 6
74
5 8
1 2
10
53
13 75
4
5145
83
21
3
6793
5 67
38
51
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)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 15
A
C
B
ED
A-MPC
Nodes
Avg. # of Paths to each Dest
A 6.3B 5.7D 5.6P-MPC Nodes: #Paths
Avg. 7.7Max 13.1Min 2.8
A-MPC
Nodes
Avg. # of Paths to each Dest
B 6.4D 6.9E 7.9P-MPC Nodes: #Paths
Avg. 6.9Max 15.5Min 2.7
A-MPC
Nodes
Avg. # of Paths to each Dest
B 6.7C 9.4D 6.2P-MPC Nodes: #Paths
Avg. 7.2Max 13.9Min 2.8
SSFnet Simulation Results
Flat OSPF Area, 19 Nodes; Only 3 Active-MPC nodes
Shivkumar KalyanaramanRensselaer Polytechnic Institute 16
Refinement 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!
A
ED
CB
F
2
21
3
1
1
2
53
5
2
Shivkumar KalyanaramanRensselaer Polytechnic Institute 17
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
Shivkumar KalyanaramanRensselaer Polytechnic Institute 18
OSPF LSA Extensions
Shivkumar KalyanaramanRensselaer Polytechnic Institute 19
Linux/Zebra/Emulab Results
D
B
C
Active Nodes
Avg. # of Paths to each Dest
B(k=3) 2.94D(k=3) 2.94C(k=3) 2.79Avg. # of Paths/k *100
B 98%D 98%C 93%
Active Nodes
Avg. # of Paths to each Dest
B(k=7) 6.5
D(k=5) 4.78C(k=5) 4.44Avg. # of Paths/k *100
B 93%D 96%C 89%
Active Nodes
Avg. # of Paths to each Dest
B(k=5) 4.83D(k=5) 4.78C(k=5) 4.44Avg. # of Paths/k *100
B 97%D 96%C 89%
Flat OSPF Area, 3 Active-MPC nodes; Upto k-shortest, validated paths
Shivkumar KalyanaramanRensselaer Polytechnic Institute 20
Refinement 2: Index-based PathID Encoding Issue: increase in computation/storage complexity at upgraded nodes Question: Can we move complexity to the network “edges” and simplify “core”
nodes ? Ans: YES!
The key is to consider an alternative, global PathID encoding
PathID = concatenation of well-known local link ID hashes
Globally-known link IDs can be locally hashed using a well-known function (eg: link ID index)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 21
Why is the Index-based Encoding Interesting?
Ans: Architectural flexibility and simplification
Core (interior) nodes: Forwarding function dramatically simplified Minimal state (only the index table) No control-plane computation complexity at interior nodes
Edge nodes: Path validation dramatically simplified Edge-nodes can store an arbitrary subset of validated paths Heterogeneous route computation algorithms can be used
Shivkumar KalyanaramanRensselaer Polytechnic Institute 22
Index-Based Forwarding Example
Shivkumar KalyanaramanRensselaer Polytechnic Institute 23
Multiple Areas
PathID re-initialized after crossing area boundaries Eg: From node A (area 1) to node I (area 2)
Available paths: A-B-C-ABR1-area2, A-B-C-ABR2-area2 etc When the packet reaches area2, ABR3 may choose one of many paths to
reach I. Eg: ABR3-H-I, ABR3-J-I, ABR3-H-G-I etc Source-routing notion similar to, but weaker than PNNI
Red nodes: upgradedGreen nodes: regular
A
ABR2
D
CB
ABR12
2
1
3
1
4
11
5
2
G 53
ABR3
ABR4
ABR5
IH
J
15
2
4 12
1
2 21
4 2
4
Area 1
Area 0
Area 2
77
Shivkumar KalyanaramanRensselaer Polytechnic Institute 24
Inter-domain TE Outbound TE:
Multi-exit (or Explicit-exit) routing Useful to manage peering vs transit costsGoal: fine-grained traffic engineering policy
BANANAS 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
Shivkumar KalyanaramanRensselaer Polytechnic Institute 25
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
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
Shivkumar KalyanaramanRensselaer Polytechnic Institute 26
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
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-level label-stacking (I.e. tunneling)
Exit-ASBR simply swaps back the destination address, before regular IP lookup => popping the stack
Shivkumar KalyanaramanRensselaer Polytechnic Institute 27
Explicit-Exit Routing Example
AS1
AS2
AS3
AS4 Dest. d
ABR1
ASBR2
ASBR3
ASBR4ASBR1
ABR2
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!!
Shivkumar KalyanaramanRensselaer Polytechnic Institute 28
Inter-AS Explicit AS-Path Choice
AS0
AS1
AS2
AS3
AS4 Dest. d
ASBR1
ASBR2
ASBR3
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
Shivkumar KalyanaramanRensselaer Polytechnic Institute 29
Re-advertisements of Multi-AS-Paths
AS2
AS1
AS0
AS3
AS4 Dest. d
AS5
ASBR1ASBR2
iBG-1 iBG-3
3 AS-paths to “d”(0 4) (0 3 4) (0 5 4)
1 AS-path or3 AS-paths to “d”??
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)
Shivkumar KalyanaramanRensselaer Polytechnic Institute 30
Putting It Together: Integrated OSPF/BGP Simulation
Shivkumar KalyanaramanRensselaer Polytechnic Institute 31
E-PathID Processing
Shivkumar KalyanaramanRensselaer Polytechnic Institute 32
Blow-up of AS2’s Internal Topology
Shivkumar KalyanaramanRensselaer Polytechnic Institute 33
FORWARDING Table in AS2 (node#5)
Corresponding Changes in Packet Headers
Shivkumar KalyanaramanRensselaer Polytechnic Institute 34
Future: Exploiting Multiplicity In The Internet
EthernetWiFi (802.11b)802.11a
USB/802.11a/b
Firewire/802.11a/b
Phone modem
InternetAS1
ISP-1
ISP-n
.
.
.
Shivkumar KalyanaramanRensselaer Polytechnic Institute 35
Exploiting Multiplicity… Unlike telephony, data networking can get statistical multiplexing
gains from simultaneously using: Multiple transmission modes (802.11a/b, 3G etc) Multiple exits (USB, Firewire, Ethernet, modem) Multiple paths (routes)
Lightweight distributed QoS on each path Eg: OverQoS (UCB) or Closed-loop QoS (Dave Harrison’s
work)
Scavenge performance from this path diversity to meet requirements of high-quality multimedia apps! BANANAS concepts are generic Can be applied for intra-domain, inter-domain, overlay routing,
or ad-hoc peer-to-peer routing
Shivkumar KalyanaramanRensselaer Polytechnic Institute 36
Eg: Multipath MPEG using Multi-band 802.11a/b Community Wireless Networks
“Fast” path
I
“Slow” path
P
Shivkumar KalyanaramanRensselaer Polytechnic Institute 37
Summary TE: “Towards Better routing performance”:
Key: Decoupling route availability and 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
Applicable to OSPF, BGP, geographical routing, large-scale overlay networks; tested on Emulab, SSFnet
Currently deploying BANANAS on Planetlab, a community wireless network in Troy, NY and in p2p streaming/videoconferencing
TE spectrumShortest Path MPLS…
BANANAS-TE
Signaled TE