1 / 27

XL: An Efficient Network Routing Algorithm

XL: An Efficient Network Routing Algorithm. Kirill Levchenko Geoffrey M. Voelker, Ramamohan Paturi, and Stefan Savage University of California San Diego. presented by Pierre-Élie Fauché. 1. Routing. Getting from point A to point B Need to know some state of the network

yasuo
Télécharger la présentation

XL: An Efficient Network Routing Algorithm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XL: An Efficient NetworkRouting Algorithm • Kirill Levchenko • Geoffrey M. Voelker, Ramamohan Paturi, and Stefan Savage • University of California San Diego presented by Pierre-Élie Fauché 1

  2. Routing • Getting from point A to point B • Need to know some state of the network • Today we do this by flooding 2

  3. link changes here everyone gets update anyway does notneed toknow Flooding 3

  4. 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

  5. Outline • Selective flooding • XL update propagation rules • Simulation results • Conclusion 5

  6. 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

  7. Reducing UpdatesIdea B: Bound Radius • Idea: limit update scope by distance • Drawback: not always correct • Distant links may be important • Greatly delays convergence 7

  8. Goals • Automatically limit update scope • Formal correctness • Loop-free routing • All destinations reachable • Bounded stretch 8

  9. 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

  10. Propagation Rules • Always propagate a link cost increase. • Neighbor should know best cost to destination if it is the next hop. • Ensures distance estimate decreases along forwarding path • Path cost finite → no long-term loops 10

  11. Propagation Rules • Propagate update if it significantly improves some route. • 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) 11

  12. Applying the Rules • Different link state tables (external views) for each neighbor • Internal view consists of most recent information from neighbors’ external views 12

  13. Applying the Rules • Compute forwarding table using internal view 13

  14. Applying the Rules • Propagate update to neighbor’s view if: • The link cost increases • Link cost decreased and neighbor is next hop to link • Cost decreased and new route much better 14

  15. Examplestretch 1.5 Rule S1 (link increase must be propagated) {CD: 1 → ∞} 15

  16. ☺ Examplestretch 1.5 No rules apply: update suppressed Rule C1 (significant improvement) {CD: ∞ → 1} A-B-C-D: 3 (actual path) 16

  17. Goals • Loop-free routing • All destinations reachable • Bounded stretch 17

  18. 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

  19. 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

  20. 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

  21. Updates per DayPoisson failure model □ Relative to Link State Crown64 H. 16 × 16 Q. 16 × 16 Abilene AS 1221 AS 1239 21

  22. Updates per DayFlapping failure model □ Relative to Link State 10x Crown64 H. 16 × 16 Q. 16 × 16 Abilene AS 1221 AS 1239 22

  23. Transient Loop DurationPoisson failure model □ Relative to Link State Crown64 H. 16 × 16 Q. 16 × 16 Abilene AS 1221 AS 1239 23

  24. Time to Find New PathPoisson failure model □ Relative to Link State Crown64 H. 16 × 16 Q. 16 × 16 Abilene AS 1221 AS 1239 24

  25. Actual Stretch Poisson link failure model Average (over all pairs of nodes) Maximum (over all pairs of nodes) Crown64 H. 16 × 16 median 1.0 Q. 16 × 16 Abilene AS 1221 AS 1239 1.0 1.5 25

  26. 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

  27. Conclusion • Provable correctness • Bounded (user-specified) stretch • Up to 3-10x fewer updates • Compatible with the favorite link-state protocol — OSPF 27

More Related