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

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

Crown64H. 16 × 16Q. 16 × 16

AbileneAS 1221AS 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