SafeGuard : Safe Forwarding during Route Changes

1. SafeGuard: Safe Forwarding during Route Changes Ang Li†, Xiaowei Yang†, and David Wetherall‡ †Duke University ‡UW/Intel Research

2. Real-time Applications Require High Network Availability • Even short periods of packet loss can degrade the service • Video pixelization • Poor voice quality • Slow gaming experience

3. Network Changes Lead to Massive Packet Losses Re-converge! No valid route Packet Loss! (Hundreds of ms~seconds) • TTL expiration • Link congestion • Packet Loss!

4. Network Changes Happen Frequently • Planned events • Maintenance, policy change, traffic engineering • Unplanned events • Fiber cut, router bug, configuration error • Sprint: median inter link failure time is only 3 minutes[Iannaccone02]

5. Problem • How to reduce forwarding disruption after network changes happen? • Intra-domain routing • SafeGuard goals • Simple • No new routing convergence protocols • Routers can update in parallel and independently • Effective • Minimize disruption period to the failure detection time • Efficient • Suitable for hardware implementation

6. Comparison with Related Work

7. Key Idea • Insight: a path’s cost encodes much valuable information in a concise form • Use cost as a Safeguard • Packets carry path costs to detect network changes • Routers use path costs to identify safe alternative paths IP Packet Dst Cost Src

8. Overview Forwarding Table: SV SV SV KA KA KA 639 3161 2795 Loop-free! Forwarding Table: Alternative Paths DB:

9. Challenges • How to encode the costs such that alternative paths can be uniquely identified? • Loops may occur if wrong paths are chosen • How to obtain the alternative paths prior to network changes? • How to forward packets efficiently? B 1 Loop! 1 A C 1 D D 1 A C 2

10. Enhance the Costs with Random Noises • Append a fixed length noise to each link cost • An enhanced path cost is the sum of enhanced link costs • Regular costs and noises are added separately • Different paths will have different enhanced path costs with high probability for practical scenarios Enhanced link cost …0110111000 1001101011 Regular link cost 10-bit random noise

11. Encode Costs in IP Packets • 32-bit label to encode an enhanced path cost • An extra escort bit to denote whether the packet is under protection • Potential places to store the cost label and the escort bit • MPLS label • IP Option • Overload unused header fields IP Packet 32-bit cost label src dst …0110111000 1001101011 0 10-bit random noise Escort bit

12. Pre-compute Alternative Paths • Compute the shortest path after removing each single component • Single component:a link, node, or SRLG • Stored in the Alternative Path Database (APD) • A mapping table from (dst, enhanced cost) to nexthop • Update APD after each topology change • Background computation B (1,4) (1,3) A C (1,7) (1,8) D C, (2,7)B

13. Add Costs to the Forwarding Table • Add the enhanced shortest path cost for each destination • Obtained from the normal shortest path computation with minimum overhead • Also add the enhanced shortest path cost from each of the nexthops to the destination • Used to update the outgoing packet costs

14. Forwarding Algorithm • Forward by comparing both cost and destination • Two modes of forwarding • Normal mode (escort bit == 0) • Packets can be forwarded along any of the ECMPs • Escort mode (escort bit == 1) • Packets are forwarded along the path uniquely identified by the packet cost

15. Normal Mode Forwarding • Each router ni only compares its own regular cost ni.cost with the packet’s regular cost pkt.cost • ni.cost == pkt.cost • Forward to any default nexthopni+1 • Update the packet cost using ni+1’s enhanced cost Incoming packet ni ni+1 D 0 S (cost,noise)

16. 2. Higher Local Cost • ni.cost > pkt.cost • Router is aware of a failure/unaware of a restoration • Default shortest paths are still safe • Forward to any default nexthopni+1 • Update the packet cost using the ni+1’s cost • Turn on the escort bit Incoming packet ni ni+1 D 0 S (cost,noise)

17. 3. Lower Local Cost • ni.cost < pkt.cost • Router is unaware of a failure/aware of a restoration • Default shortest path is no longer safe • Lookup an alternative nexthopn’i+1from the APD using the full packet cost (pkt.cost, pkt.noise) • Forward to the alternative nexthop • Turn on the escort bit Incoming packet ni n’i+1 D 0 S (cost,noise)

18. Escort Mode Forwarding • Always try to find a path with the exact enhanced packet cost • Default shortest path • Alternative path through APD lookup • If not found, drop the packet • To prevent loops in case multiple concurrent failures happen Incoming packet ni n’i+1 D 1 S (cost,noise)

19. Loop-free Forwarding with ECMPs (1,3) B (1,4) Loop-free! A C D D (1,8) (1,7) 1 A A C C 2 (2,7)

20. SafeGuard Properties • When network is steady, packets can reach their destinations through any of the ECMPs • After one network element changes its status, a packet can still reach its destination • Not considering failure detection time • Assume enhanced costs are distinct • A packet will not be trapped in a loop without being discarded

21. Evaluation • Router performance • A prototype using NetFPGA and Quagga • Forwarding overhead is only 48ns • Practical memory and computational overhead • Suitable for hardware implementation • Details are in paper • Network performance • Event-driven simulations under realistic settings • Comparison with the vanilla IP forwarding and a state-of-the-art IP fast restoration technique

22. SafeGuard Forwarding is Loop-Free Single link failure Two links failure 1 1 Cumulative Fraction Cumulative Fraction 0.8 0.8 0.6 0.6 SafeGuard + OSPF SafeGuard + OSPF IP Fast Restoration IP Fast Restoration 0.4 0.4 Vanilla IP + OSPF Vanilla IP + OSPF Flow Amplifying Factor 0.2 Flow Amplifying Factor 0.2 0 0 0 10 20 30 40 50 60 0 10 20 30 40 50 60 Sprint topology from Rocketfuel

23. SafeGuard Minimizes Disruption SafeGuard + OSPF IP Fast Restoration Single link failure Vanilla IP + OSPF 1 0.8 Packet Loss Rate 0.6 0.4 Failure happens 0.2 Failure detected (~200ms) 0 0 1.0 1.5 2.0 Time (s) 0.5

24. SafeGuard Does not Delay Convergence 2 SafeGuard/Vanilla IP + OSPF IP Fast Restoration Convergence Time (s) 1.5 1 0.5 0 link down link up node down node up 2 links down

25. Conclusion • SafeGuard • Minimize disruption after network changes • Does not modify routing convergence • Use costs as path hints • Detect network changes • Identify alternative paths • Simple, effective, and efficient

26. Thank You! http://www.cs.duke.edu/nds/wiki/safeguard Questions and comments: angl@cs.duke.edu

27. Noise Collision • Suppose c paths have the same normal cost and each noise has k-bits, the collision probability is: • The birthday probability • Try different noise if collision exists c=5

28. Simulation Parameters

29. Simulation Settings • Realistic topologies and link costs • Real and inferred topologies from Rocketfuel • A random topology with asymmetrical link costs • Practical OSPF configuration • Achieve fast convergence (sub-second) • Comparisons • No protection: OSPF + vanilla IP forwarding • State-of-the-art: Ordered FIB update (oFIB) + NotVia

30. Practical Memory and Computation Overhead • Protect all single link and node failures • On average |APD| < 3 * |FIB| • APD computation time < 100ms

31. SafeGuard Forwarding is Loop-Free 100 tests with the Sprint topology

32. SafeGuard does not Increase Convergence Time

33. 2 SafeGuard+OSPF IP Fast Restoration Convergence Time (s) 1.5 1 0.5 0 link down link up node down node up 2 links down