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

transcript

Shivkumar KalyanaramanRensselaer Polytechnic Institute 1

Hema T. Kaur, S. Kalyanaraman, A. Weiss, S. Kanwar, A. Gandhi

Rensselaer Polytechnic Institute

hema@networks.ecse.rpi.edu, shivkuma@ecse.rpi.edu

http://www.ecse.rpi.edu/Homepages/shivkuma

Sponsors: DARPA-NMS, NSF, Intel, AT&T

In case you were wondering…

BANANAS is not an acronym

Just something to remember this by…

Outline

Motivation: Best-effort path multiplicity

BANANAS: Data-plane

BANANAS: Control-plane

BANANAS: Mapping to BGP

Performance Results

Motivation: Best-Effort Path Multiplicity

EthernetWiFi (802.11b)802.11a

USB/802.11a/b

Firewire/802.11a/b

Phone modem

InternetAS1

Multiplicity: Flows, Paths, Exits/Interfaces

Multi-paths withina routing domain

Multi-AS-paths across domainsW/o specifying intra-domain paths Multiple exits from an AS

w/o specifying intra-domain paths

Multiple E2E Flows

Multi-homed interfaces & ISP/AS peers

BANANAS: A Single Abstract Framework To Exploit These Forms of Multiplicity In the Internet and Future Networks

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,

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?

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/semantics: Different placement of functions (edge vs core) Tunneling/Label Stacking Geographic/Trajectory routing

Limits of Connectionless Traffic Engg (OSPF/BGP)

Can not do this with SP routing!A

Links AB and BD are overloaded

Links AC and CD are overloaded

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

The Questions Can we do multi-path & explicit routing ?

without signaling (I.e. in a connectionless context)without variable (and large) per-packet overheadbeing backward compatible with OSPF & BGP allowing incremental network upgrades

Non-Goals: Monitoring, Traffic trunking/mapping

Shortest Path MPLS…

BANANAS-TE

Signaled TE

Traffic Engineering (TE) Spectrum

Outline

BANANAS: Data-plane

Performance Results

Big Picture: How does it fit?

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

SanFrancisco(Ingress)

New York(Egress)

IP 1321

IP 120

IPLabe

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 PathId

Global Path Identifier: Key Ideas

IP PathId(i,j)

IP PathId(1,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

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

Path su

Abstract Forwarding Paradigm Forwarding table (Eg; at Node k):

[Destination Prefix, ] [Next-Hop, ] [j, ] [k+1, ]

Path su

Packet Header:

[j, H{k, k+1, … , m-1} ]

PathID SuffixPathID

H{k, k+1, … , m-1} H{k+1, … , m-1}

[j, H{k+1, … , m-1} ]

BANANAS TE: Partial Deployment Only red nodes are upgraded

“Virtual hop” between upgraded nodes Black nodes compute single-shortest-path

Seattle

9SanFrancisco(Ingress)

New York(Egress)

Outline

BANANAS: Data-plane

Performance Results

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!

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

Implementation: OSPF LSA Extensions

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 IndicesPathID = concatenation

of link indexesPathID processing:

bit shifting!

Outline

BANANAS: Data-plane

Performance Results

Big Picture: How does it Fit

Explicit-Exit Routing: Concept

AS4 Dest. d

ASBR4ASBR1

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)

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

Inter-AS Explicit AS-Path Choice

AS4 Dest. d

Caveat: this requires more coordination across ISPsand control traffic (control-plane penalty)!

Outline

BANANAS: Data-plane

Performance Results

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

Putting It Together: Integrated OSPF/BGP Simulation

Blow-up of AS2’s Internal Topology

E-PathID Processing

FORWARDING Table in AS2 (node#5)

Corresponding Changes in Packet Headers

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

Shortest Path MPLS…

BANANAS-TE

Signaled TE

Traffic Engineering

Multiplicity: Take-Home Message…

Multiple E2E Flows

Multi-homed interfaces & ISP/AS peers

EXTRA SLIDES

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

Multiple Areas

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

Red nodes: upgradedGreen nodes: regular

Area 1

Area 0

Area 2

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

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, AS’es) 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)

Zebra/Click Implementation on Linux (Tested on Utah Emulab)

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)

Linux/Zebra/Emulab Results

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

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

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

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

Seattle

New York(Egress)

IP PathId

IP 36IP 27

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

Documents