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

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 Institute
• hema_at_networks.ecse.rpi.edu, shivkuma_at_ecse.rpi.edu
• http//www.ecse.rpi.edu/Homepages/shivkuma

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

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

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

• 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

5
MPLS Signaling and Forwarding Model

• MPLS label is swapped at each hop along the LSP
• Labels LOCAL IDENTIFIERS
• Signaling maps global identifiers (addresses,
  path spec) to local identifiers

Seattle
New York (Egress)
San Francisco (Ingress)
5
1321
120
Miami
6
Global Path Identifiers

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

7
Global Path Identifier Key Ideas
j
2
k
wm
w2
i
w1
m-1
1
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.
8
Global Path Identifier (continued)

• Path i, w1, 1, w2, 2, , wk, k, wk1, , wm,
  j
• Sequence of globally known node IDs Link
  weights
• Global Path ID is a hash of this sequence gt
  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 (MD5CRC)
• Low collision (i.e. non-uniqueness) probability
• Different PathID encodings have different
  architectural implications

9
Abstract Forwarding Paradigm

• Forwarding table (Eg at Node k)
• Destination Prefix, ? Next-Hop,
• j, ? k1,

• Incoming Packet Hdr Destination address (j)
  PathID Hk, k1, , m-1
• Outgoing Packet Hdr j, PathID Hk1, ,
  m-1
• Longest prefix match exact label match label
  swap!
• PathID mismatch gt map to shortest (default)
  path, and set PathID 0
• No signaling because of globally meaningful
  pathIDs!

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

Seattle
5
New York (Egress)
4
4
28
IP
27
30
10
San Francisco (Ingress)
1
9
1
X
2
Miami
3
1
12
Simplistic Route Computation Strategy All-Paths
Under Partial Upgrades

• Assume 1-bit in LSAs to advertise that an
  upgraded router is multi-path capable (MPC)
• Two phase algorithm (assume m upgraded nodes)
• 1. (N-m) Dijkstras 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)

13
Simulation/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
14
Zebra/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)

15
SSFnet Simulation Results
A
B
E
C
D
Flat OSPF Area, 19 Nodes Only 3 Active-MPC nodes
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!

17
Two-Phase Path Validation Algorithm

• Concept Forwarding for path exists only if the
  forwarding for each of its suffixes exists.
• 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 all valid paths
  in the network validation can be done in the
  background
• Validation algorithm correct by mathematical
  induction

18
OSPF LSA Extensions
19
Linux/Zebra/Emulab Results
B
D
C
Flat OSPF Area, 3 Active-MPC nodes Upto
k-shortest, validated paths
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

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

22
Index-Based Forwarding Example
23
Multiple Areas
Red nodes upgraded Green nodes regular

• 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

24
Inter-domain TE

• Outbound TE
• Multi-exit (or Explicit-exit) routing
• Useful to manage peering vs transit costs
• Goal 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

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

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

27
Explicit-Exit Routing Example

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

28
Inter-AS Explicit AS-Path Choice

• 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
  Hash1,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

29
Re-advertisements of Multi-AS-Paths

• Issue in path-vector algorithms, without
  re-advertisements (of a subset of paths), remote
  ASs 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)

30
Putting It Together Integrated OSPF/BGP
Simulation
31
E-PathID Processing
32
Blow-up of AS2s Internal Topology
33
FORWARDING Table in AS2 (node5)
Corresponding Changes in Packet Headers
34
Future Exploiting Multiplicity In The Internet
USB/802.11a/b
Phone modem
802.11a
Firewire/802.11a/b
WiFi (802.11b)
Ethernet
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
  Harrisons 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

36
Eg Multipath MPEG using Multi-band 802.11a/b
Community Wireless Networks
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 spectrum

Shortest Path
MPLS