fast recovery in ip networks using multiple routing configurations amund kvalbein simula research...

Fast recovery in IP networks using

Multiple Routing Configurations

Amund KvalbeinSimula Research Laboratory

Sept 19 2007 GaTech networking seminar 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


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


Outline

• Multiple Routing Configurations– The basic idea– Generating backup configurations– Forwarding

• Evaluation

• Load balancing improvement

• Implementation issues

• Wrap up


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


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!


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!


Building backup configurations

4

6

7

5

30

1

2

C0


4

6

7

5

30

1

2

4

6

7

5

30

1

2

4

6

7

5

30

1

2

C1 C2 C3



Forwarding

4

6

7

5

30

1

2

4

6

7

5

30

1

2


How many configurations are needed?

16 32 64 128 512


How long are the backup paths?


What about load distribution?


Why bother to avoid overload?- it’s only for short while…

• Motivation for fast rerouting– Do not loose packets– Increase stability

• FRR should not make it worse for unaffected traffic


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



• Optimize C0 independently

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

nodes


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


Evaluation – Max link load

• Real and synthetic network topologies• Gravity model traffic demands

Network Failure free

MRC n=5

MRC n=10

OSPF

Geant 0.68 1.01 1.08 1.20

Cost239 0.66 0.99 0.99 0.99

Sprint US (POP)

0.64 1.10 1.10 1.10

German Telecom

0.66 1.02 1.02 1.17


Evaluation – Number of configurations


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


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


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


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

fast recovery in ip networks using multiple routing configurations amund kvalbein simula research...

Documents