bananas: an evolutionary framework for explicit and multipath routing in the internet

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


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


The Question Can we emulate a subset of MPLS properties without signaling?

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


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


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


Global Path Identifiers

Instead of using local path identifiers (labels in MPLS), consider the use of global path identifiers

10

Miami

Seattle

9

27


New York(Egress)

18

1

5

4

3

5

IP

IP PathId

4

IP 36

IP 27

IP 0


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.


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


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}


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


New York(Egress)

18

1

5

4

3

5

IP

IP PathId

4IP 5

IP 0

IP 36IP 27

IP 0


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


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)


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


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)


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


B 6.4D 6.9E 7.9P-MPC Nodes: #Paths

Avg. 6.9Max 15.5Min 2.7

A-MPC

Nodes


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


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


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


OSPF LSA Extensions


Linux/Zebra/Emulab Results

D

B

C

Active Nodes


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


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


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


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)


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


Index-Based Forwarding Example


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


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


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


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


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!!


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


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)


Putting It Together: Integrated OSPF/BGP Simulation


E-PathID Processing


Blow-up of AS2’s Internal Topology


FORWARDING Table in AS2 (node#5)

Corresponding Changes in Packet Headers


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

.

.

.


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


Eg: Multipath MPEG using Multi-band 802.11a/b Community Wireless Networks

“Fast” path

I

“Slow” path

P


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

bananas: an evolutionary framework for explicit and multipath routing in the internet

Documents