presented by Pierre-Élie Fauché1

XL: An Efficient Network

Routing AlgorithmKirill Levchenko

Geoffrey M. Voelker, Ramamohan Paturi, and Stefan Savage

University of California San Diego

Routing

• Getting from point A to point B

• Need to know some state of the network

• Today we do this by flooding

2

Floodinglink changes

here

everyone gets update anyway

does notneed toknow

3

Flooding

• Number of updates per node grows with the number of links

• Slowest link or node effectively limits sustainable size of an AS network

• Is flooding inherent to routing?

4

Outline

• Selective flooding

• XL update propagation rules

• Simulation results

• Conclusion

5

Selective FloodingIdea A: Artificial

Hierarchy• Manually restrict scope of updates

• Example: OSPF areas

• “Considered harmful”

• Results in sub-optimal routing

• Hard to adapt to growth

6

Reducing UpdatesIdea B: Bound

Radius• Idea: limit update scope by distance

• Drawback: not always correct

• Distant links may be important

• Greatly delays convergence

7

Goals

•Automatically limit update scope

•Formal correctness

• Loop-free routing

• All destinations reachable

• Bounded stretch

8

Reducing UpdatesIdea XL: Selective

Updates

• Idea: Link state with selective update propagation

• Need to know which updates are necessary and which can be suppressed

9

Propagation Rules

• Ensures distance estimate decreases along forwarding path

• Path cost finite → no long-term loops

S Always propagate a link cost increase.

S Neighbor should know best cost to destination if it is the next hop.

10

Propagation Rules

• Guarantees all connected nodes are reachable and stretch is bounded

• Bonus: stretch can be set per-destination or in response to network load

• Under “normal” conditions set stretch to 1.0 (optimal)

C Propagate update if it significantly improves some route.

11

Applying the Rules

• Different link state tables (external views) for each neighbor

• Internal view consists of most recent information from neighbors’ external views

12

Applying the Rules

• Compute forwarding table using internal view

13

Applying the Rules

• Propagate update to neighbor’s view if:

S The link cost increases

S Link cost decreased and neighbor is next hop to link

C Cost decreased and new route much better

14

Examplestretch 1.5

Rule S1 (link increase must be propagated)

{CD: 1 → ∞}

15

Examplestretch 1.5

Rule C1 (significant improvement)No rules apply: update suppressed

{CD: ∞ → 1}

☺

A-B-C-D: 3(actual path)

16

Goals

✓Loop-free routing

✓All destinations reachable

✓Bounded stretch

17

Simulation Model• No traffic or propagation delays

• Poisson failure model

• 1 day mean time to failure

• 1 hour mean time to recovery

• Flapping failure model

• 2 days mean time to failure

• High probability of repeat failure

18

Simulation Networks• Crown64 — crown-like ring (192

nodes)

• H. 16 × 16 — honeycomb grid (289 nodes)

• Q. 16 × 16 — square grid (576 nodes)

• Abilene — Abilene backbone (11 nodes)

• AS 1221 — Telstra (104 nodes)

• AS 1239 — Sprint (315 nodes)19

Simulated Algorithms

•Distance Vector (e.g. RIP)

•Link State (e.g. OSPF)

•Distance Vector with Parent Pointer

• fixes “counting-to-infinity” by sending shortest-path tree in addition to distances

•Link Vector

• SPT-based like Distance Vector with Parent Pointer

20

Updates per DayPoisson failure model □ Relative to

Link State

Crown64 H. 16 × 16 Q. 16 × 16 Abilene AS 1221 AS 123921

Updates per DayFlapping failure model □ Relative to

Link State

Crown64 H. 16 × 16 Q. 16 × 16 Abilene AS 1221 AS 1239

10x

22

Transient Loop Duration

Poisson failure model □ Relative to Link State

Crown64 H. 16 × 16 Q. 16 × 16 Abilene AS 1221 AS 123923

Time to Find New Path

Poisson failure model □ Relative to Link State

Crown64 H. 16 × 16 Q. 16 × 16 Abilene AS 1221 AS 123924

Crown64

H. 16 × 16

Q. 16 × 16

Abilene

AS 1221

AS 1239

Actual StretchPoisson link failure

modelAverage

(over all pairs of nodes)Maximum

(over all pairs of nodes)

1.0 1.5

median1.0

25

OSPF Compatibility

• Observation: classic link state algorithm is a “special case” of the XL algorithm

• OSPF satisfies the XL rules

• XL could be mixed with OSPF for incremental deployment

26

Conclusion

• Provable correctness

• Bounded (user-specified) stretch

• Up to 3-10x fewer updates

• Compatible with the favorite link-state protocol — OSPF

27