Fast recovery in IP networks using Multiple Routing Configurations

1
Fast recovery in IP networks using Multiple
Routing Configurations

• Amund Kvalbein
• Simula Research Laboratory

2
Motivation

• Increasing use of the Internet for applications
  with stringent performance requirements
• Telephony, videoconferencing, online games
• ISPs must adhere to tough SLAs
• The recovery mechanisms in the Internet are not
  designed for these requirements
• Many (most) failures are short lived
• Failures are advertised too widely!
• This gives slow reaction and fosters instability

3
Our approach

• Failure reaction should be local
• To avoid instability and overhead
• Challenge avoid loops
• Failure reaction should be proactive
• To reduce recovery times and packet loss
• Challenge minimize overhead

4
Outline

• Multiple Routing Configurations
• The basic idea
• Generating backup configurations
• Forwarding
• Evaluation
• Load balancing improvement
• Implementation issues
• Wrap up

5
Multiple Routing Configurations

• Guaranteed protection against single link, node
  or SRLG failures
• Same mechanism for both link and node failures
• Generally difficult to distinguish at neighbor
• A configuration is the graph and the weight
  function
• Different weight setting in each configuration

6
The general observation

• An unused link can fail without consequences
• So can a single-connected node
• Several links and/or nodes can be protected in
  one logical topology
• All nodes are still reachable
• Build topologies so that all elements are
  protected
• Few such topologies are needed to protect all
  elements!

7
Isolated links and nodes

• An isolated link has infinite weight
• A restricted link has a high weight wr
• wr is chosen so that the link is used only as a
  last resort
• A node is isolated when all attached links are
  either isolated or restricted

Traffic never goes through an isolated link or an
isolated node!
8
Building backup configurations
6
1
7
4
2
5
0
3
C0
9
Building backup configurations
6
6
6
1
1
1
7
7
7
4
4
4
2
2
2
5
5
5
0
0
0
3
3
3
C1
C2
C3
10
Forwarding
6
6
1
1
7
7
4
4
2
2
5
5
0
0
3
3
11
How many configurations are needed?
32
64
128
512
16
12
How long are the backup paths?
13
What about load distribution?
14
Why bother to avoid overload?- its only for
short while

• Motivation for fast rerouting
• Do not loose packets
• Increase stability
• FRR should not make it worse for unaffected
  traffic

15
Routing performance during FRR

• Given TM estimate What decides the load
  distribution?
• Link weights in C0
• Structure of backup configurations
• Link weights in backup configurations
• Three step approach
• Optimize link weights in C0
• Build backup configurations
• Optimize link weights in backup configurations

16
Building backup configurations

• Optimize C0 independently
• Identify the heaviest nodes (most traffic)
• Build configs with good connectivity for heavy
  nodes

17
Optimizing link weights

• Heavy optimization task
• Dependencies between configurations
• Local weight search heuristic
• Based on well known Fortz/Thorup method
• Optimize only for most severe link failures
• Take advantage of configuration structure
• A link failure only activates one or two backup
  configurations

18
Evaluation Max link load

• Real and synthetic network topologies
• Gravity model traffic demands

19
Evaluation Number of configurations
20
Implementation issues

• Representing backup configurations
• IETF Multi-Topology routing
• Can calculate independent shortest path trees in
  each topology
• Need ability to switch configuration in-flight
• Marking packets
• Same problem as in MT-routing
• Reuse of ToS/DSCP bits has been proposed

21
Summary

• MRC guarantees protection against any single link
  or node failure
• Modest state overhead
• Small path length stretch for recovered traffic
• Flexibility in how recovered traffic is routed
• Realistic to implement

22
Related work

• Failure Insensitive Routing (FIR)
• Relies on interface-specific routing tables to
  infer link failures
• Not-via addresses
• Calculates one configuration for each protected
  element

23
MRC extensions

• Multi-failure protection
• SRLG, uncorrelated failures
• Can guarantee protection against two independent
  failures (at a cost)
• Improved configuration construction
• Eliminate isolated links
• Use deflection in forwarding procedure
• Use in TE context
• Spread demands on several topologies
• Lab implementation
• Using Quagga routing software