Resolving a Question about Span Restoration Do Loopbacks

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

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 !?

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

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) Example: Span restoration view Working paths Span restoration paths +

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 Example: End to end path view Restoration without loopbacks Restoration with loopbacks • At first glance, the left restoration configuration seems to be more efficient than the right one

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 configuration With loopback elimination

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: Span failure E-H: 10 capacity units appear to be 10 capacity units are fully utilized by wasted by the loopback restoration paths

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 f 1 is a forcer of span s if in the optimal design, its restoration requires use of every spare channel on span s

Assessing the Loopback-Revised Spare Capacity • Step 1: Determine the number of protection paths ps, 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 ws, f that traverse spans s and f for all span pairs (s, f), s≠f • Step 3: Calculate the number of loopbacks ls, f on span s in case of span failure f by: ls, f = Minimum(ps, f, ws, f) for all span pairs (s, f), s≠f • Step 4: The loopback-revised protection capacity on span s is: cs = Maximum(ps, f 1 – ls, f 1, ps, f 2 - ls, f 2, …) over all spans f 1, f 2, … except span s

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: US network European network German network Oslo os Glasgow no Norden se br Bremen Seattle Ithaca it Ann Arbor an sa bo Salt Lake City Boulder li Lincoln ur Urbana pa Palo Alto pi Pittsburgh Duesseldorf pr wa Princeton Washington D. C. Essen es du Hanover hn do Dortmund co Cologne Berlin be le Leipzig Frankfurt fr at Atlanta sn San Diego ho Houston Mannheim ma nu Nuremberg Copenhagen co Dublin du Amsterdam Hamburg Berlin Warsaw ha am bl wa London lo Frankfurt Brussels br fr Prague Strasbourg Paris pa pr sr mu vi Zurich bu Budapest Munich zu Vienna Bordeaux bo Lyon ly mi za be Belgrade Milan Zagreb ba Karlsruhe ka st Stuttgart ul Ulm st Stockholm gl ha Hamburg ma Madrid mu Munich Barcelona ro Rome Athens at

Results: “US Network” • 44. 6% of all restoration paths involve loopbacks • 1. 1% spare capacity reduction in the US network

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

Results: “European network” • 74. 1% of all restoration paths involve loopbacks • 0. 1% spare capacity reduction is possible by loopback elimination

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.