1. Resolving a Question about Span Restoration: Do Loopbacks Involve a Capacity Penalty? Wayne D. Grover TRLabs and Dept. of Electrical and Computer Engineering, University of Alberta Matthias Scheffel Munich University of Technology, Institute of Communication Networks (Prof. Eberspaecher)

2. Motivation / Background Span restoration (equivalently, pre-planned span protection) is one of the most longstanding options for survivable mesh networking. Every year or so, a proposal comes forward (or a new patent) having invented span restoration with “loopback elimination.” –It is assumed obvious that such loopback elimination must save a great amount of spare capacity. To our knowledge, however, that assumption has never been quantitatively tested. –Moreover, a qualitative argument has been published saying why loopback elimination is probably insignificant. So, the Question is:  Do loopbacks actually use excess spare capacity in a span restorable mesh network, or not !?

3. Span Restoration Principle Alternative path segments restore all working channels of the failed span –Local restoration between the end nodes of the failed span –Multiple restoration routes are possible per span –Restoration path segments for different spans can share spare capacity –Mechanisms equivalent to max flow or ksp re-routing

4. Occurrence of Loopbacks The end-to-end working path is the same except for the local restoration path segment substituting the working link on the failed span Working path and restoration segment may thus have common spans (or/and transit nodes) + Working paths Span restoration paths Example: Span restoration view

5. Occurrence of Loopbacks Span restoration is not aware of the end-to-end working paths –In this regard, it is like the mesh correspondent to BLSR rings. The occurrence of loopbacks depends on the assignment of restoration paths to affected working links Restoration without loopbacksRestoration with loopbacks At first glance, the left restoration configuration seems to be more efficient than the right one Example: End to end path view

6. The Recurring Idea of “Loopback Elimination” Nodes along the restoration path may check whether the restoration path and the working path belonging to the affected working link traverse a common span If so, the node cross-connects the restoration path and the remainder working path Knowledge about the assignment of restoration paths to working links and the working route requires additional signaling Loopback configurationWith loopback elimination

7. Loopback Elimination However, the loopback capacity cannot necessarily be released from the network Optimal span restoration minimizes the spare (and working) resources in the network Spare capacity used to form loopbacks for one span failure is required in order to recover from other span failures, too Our hypothesis: What appears as loopback capacity for one failure is almost always required in a non loopback way for at least one other failure scenario. Span failure C-F: 10 capacity units appear to be wasted by the loopback Span failure E-H: 10 capacity units are fully utilized by restoration paths

8. Forcer-Based Reasoning and Analysis Forcer concept –In span restoration, each span s with non-zero spare capacity c has a forcer span f whose failure yields restoration paths on s that utilize the entire spare capacity c –An optimal span restoration design usually involves more than one forcer f (co-forcers) for each span s Failure scenario f1 is a forcer of span s if in the optimal design, its restoration requires use of every spare channel on span s

9. Forcer-Based Analysis Conditions under which loopback capacity can be released –The failure of each forcer f of span s must have a loopback on s, i.e. there must be at least one working path that traverses spans f and s  One spare capacity unit can be released on s If there exists only one forcer f for which no working path exists that crosses both spans f and s, no spare capacity can be released

10. Assessing the Loopback-Revised Spare Capacity Step 1: Determine the number of protection paths p s,f that traverse span s in case of span failure f for all span pairs (s,f), s≠f Step 2: Determine the number of working paths w s,f that traverse spans s and f for all span pairs (s,f), s≠f Step 3: Calculate the number of loopbacks l s,f on span s in case of span failure f by: l s,f = Minimum(p s,f, w s,f ) for all span pairs pairs (s,f), s≠f Step 4: The loopback-revised protection capacity on span s is: c s = Maximum(p s,f1 – l s,f1, p s,f2 - l s,f2, …) over all spans f 1, f 2, … except span s

11. Test-Case Studies Optimal integer linear program based design of span restoration by joint optimization of working and protection routing Calculation of loopback capacity that can be released Network scenarios: se pa sn sa bo li ho at wa pr it pi an ur Seattle Salt Lake City San Diego Palo Alto Boulder Houston Lincoln Atlanta Washington D.C. Princeton Ithaca Pittsburgh Ann Arbor Urbana ha no be hn br do es co le fr ma ka st ul mu nu du Hamburg Norden Bremen Hanover Berlin Leipzig Dortmund Essen Duesseldorf Cologne Frankfurt Mannheim Karlsruhe Stuttgart UlmMunich Nuremberg European network German networkUS network

12. Results: “US Network” 44.6% of all restoration paths involve loopbacks 1.1% spare capacity reduction in the US network

13. Results: “German network” 50.2% of all restoration paths involve loopbacks There is no capacity penalty due to loopbacks

14. Results: “European network” 74.1% of all restoration paths involve loopbacks 0.1% spare capacity reduction is possible by loopback elimination

15. Concluding Discussion Span restoration provides alternative path segments at the end nodes of failed working links –Loopbacks arise if the end-to-end working paths and the assigned protection segment have common spans –Results show loopbacks do occur frequently A Forcer-based analysis was used to calculate the net capacity penalty due to loopbacks –There are none or only extremely small capacity savings when eliminating loopbacks –Slight changes to working capacity values can make the savings strictly vanish as well. What is the explanation? –As postulated, it does seem that “what is loopback capacity for one failure scenario is almost invariably needed capacity under one or more other failure scenarios.” –The “forcing” failures in the design will need all the spare capacity present in a non-loopbacked way.