I. INTRODUCTION

Elastic optical networks (EONs) have emerged as a highly adaptable solution for core network infrastructures, marked by their ability to allocate resources and precisely assign spectrum dynamically. Unlike traditional fixed-grid networks, EONs adjust bandwidth and spectrum with a finer level of granularity [1]. This capability is achieved through the use of frequency slots (FSs), typically 12.5 GHz each, enabling precise and efficient spectrum utilization [2].

Survivability is an important aspect of EONs. Survivability strategies can be divided into protection and recovery [3]. Protection aims to reserve backup resources to prepare for network failures. As a pre-failure approach, it allows for immediate reaction to network failures with minimal service disruption. However, it requires maintaining redundant backup resources for all potential failures. Protection strategies are typically divided into dedicated backup protection (DPP) and shared backup protection (SBPP). There has been a large amount of work on protection in EONs (e.g., [4]- [7]). For dedicated backup protection, in [4] an integer linear programming(ILP) mode and a heuristic algorithm is proposed for routing and spectrum assignment with DPP. In [6], the authors proposed an SBPP algorithm with an ILP model to minimize the required spare capacity with consideration of transponder tunability and bandwidth-squeezed restoration. In [7], a hybrid protection algorithm is proposed for providing shared or dedicated backup path protection to minimize spectrum utilization. In [5], a pcycle design is proposed for protection in EONs with spectrum sharing and defragmentation consideration. In our previous work [8], we proposed a p-cycle approach for translucent EONs to minimize the protection bandwidth by using regenerators.

Protection requires the provisioning of significant redundant resources and is usually designed for common failures such as one or two nodes/links or shared risk groups [6]. Compared to protection, recovery or restoration is a post-failure strategy that aims to find available resources in the damaged network after the failure [9]- [11]. In [12], a novel data center provider services recovery strategy is designed with resource-driven demand matching, but it is not designed for EONs. In [13], the authors proposed a network recovery algorithm to maximize the routed traffic demand after the disaster. However, it mainly focuses on repairing the failed network components instead of service recovery. In [14], a heuristic traffic recovery algorithm is proposed for EONs, incorporating a genetic operator to optimize the service restoration sequence for failed services. In [15], the authors propose a capacity-constrained, maximally spatially-disjoint lightpath algorithm for EONs, specifically to address the provisioning and restoration of disrupted lightpaths in a post-disaster scenario. Still, the bandwidth recovery with degradation is not considered in the above two works.

Clearly, protection cannot be an efficient solution for disaster survivability because of a disaster's potential for extensive network damage and the need for an inordinate amount of redundant resources that have a low probability of ever being activated. Post-disaster recovery using the undamaged part of the network is naturally a better approach. Nevertheless, networks in practice would have to use a combination of protection and recovery -protection for common failures and recovery for unanticipated large-scale network damage, such as disasters. Despite the existence of an extensive amount of research separately on protection and recovery, we are not aware of any work that leverages the backup resources in protected EONs in disaster recovery.

In this paper, we introduce a novel recovery algorithm for protected and transparent EONs called DRAMA-PRO. Our recovery approach is based on the mitigation zone concept introduced in our previous work [16], [17]. The mitigation zone is an area immediately surrounding the disaster zone that aids in disaster recovery by allowing lightpaths within that zone to be recovered with degraded service in the network damaged by a disaster. The idea behind this concept is that it is more acceptable for a service closer to a disaster to be recovered in a degraded fashion rather than degrading a service far away from the disaster. The mitigation zone can be flexibly deployed by network operators to strike a balance between acceptable service degradation and recovery. The effectiveness of the mitigation zone has been demonstrated in [16], [17]. In this paper, we consider multi-class traffic that includes a mix of unprotected and protected connections. DRAMA-PRO aims to retain the protection for protected lightpaths in the damaged network, while also recovering the unprotected lightpaths. This work is different from our previous work in [16]- [18]. In [16] we first proposed the mitigation zone concept and presented a disaster recovery algorithm for uprotected transparent EONs. In [17] we extended the previous work to translucent but unprotected EONs, and in [18] we proposed a recovery algorithm for service function chain requests in data center EONs. None of these papers considered protected EONS, which is the focus of this paper.

The rest of the paper is organized as follows. The problem statement, network model, and penalty model are presented in Section II. The DRAMA-PRO algorithm is presented in Section III. This is followed by simulation results in Section IV, and the paper is concluded in Section V.

II. NETWORK MODEL AND PROBLEM STATEMENT

A. Network and traffic model

The disaster recovery problem is defined within a network G(N, E), where N represents the node set and E represents the set of links. Each link consists of a pair of fibers in opposite directions. At the time of the disaster, there is a set of active lightpaths denoted as T . A lightpath request is represented as t(s, d, w, θ), where s and d are the source and destination nodes respectively, and w indicates the data rate. θ is the class of the request. We assume that there are two types of lightpath requests: first-class and normal-class. A first-class request requires a working path and a protection path, while a normal-class request only needs a working path and is not required to be protected. We assume that firstclass requests are protected using dedicated path protection and the working path and protection path do not share any common link or node. All working and protection paths are routed and assigned with spectrum continuity and contiguity requirements. Multiple modulation formats are available, each having different distance limitations and offering different levels of spectrum efficiency. All the lightpaths are assigned the highest feasible modulation format based on their physical distance.

During the recovery after a disaster, for a first-class lightpath request, the protection path of the request should also be recovered or re-accommodated. If the working path is affected but the protection path is not affected, the protection path will be directly used as the working path after the disaster without any data rate degradation. This protection deployment is done right after the disaster and before the recovery starts.

B. Disaster model and mitigation zone

We assume that the disaster zone D(C d , R d ) is defined as the circular area centered at C d with a radius of R d . Any node and any link with at least one endpoint within this area is failed by the disaster. If there is no viable path between a request's source and destination node, or if either the source or destination node fails, the lightpath is regarded as unrecoverable. The mitigation zone M (C d , R m ) is defined as the annulus between the outer edge of the disaster zone and an additional circle centered at the disaster center. These zones are depicted in Fig. 1. The area outside both the mitigation and disaster zones is designated as U .

Each lightpath request t from the set T is classified according to the zones of its source and destination nodes. If either source or destination node is within D, then t belongs to D and is unrecoverable. If both nodes are outside D but one or both are within M , then t is placed in M . Otherwise, t belongs to U . 1Based on the motivation of the mitigation zone, we assume that the unaffected lightpath request inside the mitigation zone could be re-accommodated with a degraded data rate to alleviate the bottleneck problem caused by the disaster. Service degradation is allowed for all lightpath requests during recovery, but re-routing is only allowed for a lightpath that is directly affected by the disaster or inside the mitigation zone. Service degradation leads to a penalty, and according to the motivation for the mitigation zone concept, the penalty inside the mitigation zone is kept lower than the penalty outside the mitigation zone to discourage the degradation of a service far away from the disaster. The next subsection presents more details.

Examples of lightpaths are shown in Fig 1 . t 1 is an example of a first-class request and t w 1 and t p 1 are the working path and protection path, respectively, before the disaster. Since t 1 ∈ U and its working path is affected by the disaster, the lightpath request will directly use the unaffected protection path t p 1 as the working path after the disaster. During the recovery, we will look for a new protection path to keep the request protected. The normal-class request t 2 is an example of a lightpath outside the mitigation zone but not affected by the disaster. In this case, t 2 is a candidate for degraded service with the same path as before the disaster. If the lightpath request is inside the mitigation zone, for both first-class request and normalclass request, no matter whether it is affected or not, it will be recovered or re-accommodated (e.g., t 3 ). If the lightpath request is unrecoverable, the lightpath is dropped (e.g., t 4 ).

C. Penalty model

To evaluate recovery efficiency with data rate degradation on lightpaths, we use penalty functions to quantify the service level degradation. The penalty function design is proposed and validated in [16], [17]. In this paper, We assume that each lightpath contributes revenue to the network, which is assumed for simplicity to be equivalent to the data rate of the lightpath. For a first-class lightpath request, the working path and the protection path have the same revenue that equals the data rate of the lightpath request, while the revenue of a normal-class lightpath only comes from its working path. If the data rate of a lightpath is degraded after disaster recovery, there is an incurred penalty. The definition of the mitigation zone implies that the penalty for the same level of degradation should be higher outside the mitigation zone than inside the mitigation zone. While our algorithm can work with any penalty function, in this paper, we use the two penalty functions shown in Fig. 2 and defined in (1) and (2).

where d is the degradation factor, defined as the percentage of the data rate degraded (the reduction percentage of the data rate). There are two different penalty functions: P 1 (d) is for a lightpath inside the mitigation zone, and P 2 (d) is for a lightpath outside the mitigation zone. The penalty functions describe how the degradation factor correlates with the percentage of revenue lost. The absolute value of the penalty is the value of the penalty function times the total revenue of the lightpath. In addition, we set up two balance factors: α and β to measure the penalty more reasonably. α is used to quantify the relative penalty for the protection path of the first-class request (relative to the working path of a first-class request), while β is used to quantify the relative penalty for the normal-class request. The actual penalty for these two types of lightpath equals the actual penalty given by the penalty function times the corresponding factor. In this paper, both α and β are set to 0.7. Again, this is a choice that can be set by the network operator, and the algorithm can work with any given choice.

The goal of the disaster recovery problem with protection is to recover the two different classes of affected traffic requests and re-accommodate the unaffected requests with appropriate routing, degradation, and protection, while minimizing the total penalty.

III. DRAMA-PRO

In this section, we present the DRAMA-PRO algorithm. Lightpaths are recovered one by one in a sequence in DRAMA-PRO. First, the recovery order of the recoverable lightpath requests is determined. Then we perform the recovery or re-accommodation with degradation factor selection for each working and protection path of the lightpath requests. The pseudocode of the recovery algorithm is presented in Algorithm 1.

In lines 1 to 2, we initialize an empty request set W and release all the spectrum in the damaged network. 2 From line 3 to line 9, if the working path is affected but the protection path is not affected, we directly use the protection path as the new working path after the disaster. From lines 11 to 14, we add all the recoverable requests to W . if t is first-class then 5:

if t w is affected and t p is not affected then 6:

Assign t with the t p as the working path

7: end if 8: end if 9: end for 10: for each t ∈ T do 11: if t / ∈ D (i.e., t is recoverable) then 12: Add t to W 13: end if 14: end for 15: Calculate the shortest path for each t in W 16: Sort all t ∈ W in non-increasing order of PRE 17: for each t ∈ W do 18: if t w is affected and t p is not affected then 19: Working path is the protection path before the disaster 20: else 21: if t ∈ M or t is affected then 22: Calculate the working path with the CR algorithm 23: else 24: Select the same working path as before the disaster 25: end if 26: Calculate the degradation option for the working path 27: Assign the working path with the selected path and degradation option 28: end if 29: if t is first-class then 30: if t ∈ M or t is affected then 31: Calculate the protection path with the CR algorithm 32: else 33: Select the same protection path as before the disaster 34: end if 35: Calculate the degradation option for the protection path 36: Assign the protection path with the selected path and degradation option 37: end if 38: end for

A. Order of recovery

In lines 15 to 16, we calculate the order of recovery. All the recoverable lightpath requests are sorted in terms of their Potential Revenue Efficiency (PRE) in non-increasing order. The PRE is defined as the ratio of the actual revenue of the lightpath to the number of FSs needed if the lightpath is routed with the shortest path. The PRE of a first-class lightpath request is the sum of the actual revenue of the working path and protection path to the sum of the number of FSs needed. The actual revenue is designed as the revenue factor of the lightpath request times the original revenue (equal to the data rate). The actual revenue of the lightpath shows how much revenue we can maintain. The number of FSs shows the general cost of this recovery or re-accommodation. Even though we may not use the shortest path to re-assign the lightpath eventually, the shortest path is an estimation of the spectrum cost.

B. Routing

Once we have the order, we start to recover the requests one by one. In lines 17 to 25 we calculate the working path. For each lightpath request inside the mitigation zone or affected by the disaster, we calculate the working path by using the Cost-Routing algorithm (CR) as follows. In the CR algorithm, we calculate the cost of each path in the K shortest path pool and select the path with the lowest cost. The cost of a path is defined as

where H is the number of hops and M is the modulation factor of the path. The modulation factor for each lightpath is determined based on the physical distance of the path, with the highest feasible modulation format being selected. For modulation formats BPSK, QPSK, 8QAM, and 16QAM, the spectrum efficiencies are 1, 2, 3, and 4 bps/Hz, respectively. Consequently, the corresponding modulation factors are set at 1, 0.5, 0.34, and 0.25. γ is a large constant number used to make H × M dominate the value of cost. ν F is the number of FSs needed without degradation and ν A is the number of available FSs on the path with spectrum continuity constraint, while ν L is the size of the largest spectrum fragment on the path. In case the value of ν A is 0, the path is dropped from the pool. The value of H × M is used to measure the spectrum cost of the path, which dominates the routing selection, to save spectrum as much as possible. For two paths with the same spectrum cost, ν F /ν A and ν F /ν L are used to evaluate the load balance of the paths. The path that has more available FSs has a lower cost and is encouraged to be selected. If there is no working path available, we directly block the request.

C. Degradation selection

In line 26, once the working path is found, we select the degradation option for the working path. The modulation format is determined by the physical length of the lightpath, and we calculate the number of FSs required to maintain service without degradation. For each potential degradation option, we compute the Potential Penalty (PP), which is the sum of the Current Penalty (CP) and Future Penalty (FP). The degradation option with the lowest PP is then chosen for the lightpath.

CP is the actual penalty of the current degradation option, calculated with the penalty function. FP is calculated based on the consequence if the LP is assigned with a degradation option:

, where ν W and ν ′ F are the amount of maintained data rate and FSs of the given degradation option, ν A is the number of available FSs as used in the CR algorithm, and p ′ and p are the number of requests that have already been recovered and the number of total recoverable requests. ν W is the amount of data rate that the algorithm gives to this request. ν ′ F /ν A is designed as the factor to measure the spectrum utilization; a larger value means the more FSs are used and the higher FP we will have. p ′ /p is used to account for the progress in the recovery procedure. As the algorithm proceeds towards the end of the recovery process, we may have a limited number of available FSs, and these must be judiciously spread over the remaining lightpaths yet to be recovered. The FP is accordingly scaled up so that it becomes more dominant than the CP.

In line 27, once the degradation of the working path is selected, we assign the working path first. From lines 29 to 37, if the request is a first-class request, we then find the dedicated protection path and its degradation. We first remove the path that has a joint node or link with the working path from the K shortest path pool, and then we keep using the CR algorithm to find the dedicated protection path. The degradation of the protection path is also selected with PP, CP, and FP, similar to the working path. Note that during the degradation selection of the protection path, the recovered protection bandwidth should not be larger than the recovered working bandwidth, but it could end up being smaller.

The time complexity of the CR routing algorithm is O(K • F • N ), as the number of hops in a path is N . After that, for the degradation selection, the time complexity is O(F • N ). Therefore, the time complexity of DRAMA-PRO is O(K • F • N ).

IV. SIMULATION RESULTS

We now present some simulation results. The NSF network (14 nodes and 22 links, shown in Fig. 3) topology is used for testing. Each fiber has 352 FSs. To thoroughly evaluate the performance of DRAMA-PRO, two typical disasters are tested, shown as red circles in Fig. 3. D 1 happens at the center of the network and D 2 happens near the edge of the network. In addition, we also show the average performance for random disasters. The examples of the mitigation zones of D 1 are shown in Fig. 3 as M s , M m , and M L for the small, medium, and large mitigation zones. We also test recovery with the no mitigation zone and the all mitigation zone, i.e., when the whole network outside D is the mitigation zone.

For the pre-disaster scenario, a set of lightpath requests is generated with source and destination nodes selected uniformly at random. The data rates for these lightpaths are set at 40 Gbps, 100 Gbps, and 400 Gbps, assigned with probabilities of 0.2, 0.5, and 0.3, respectively. We utilize four modulation formats: BPSK, QPSK, 8-QAM, and 16-QAM. The physical distance limitations and the number of required FSs for each data rate adhere to the parameters previously established in [17].

Before the disaster happens, 1000 lightpath requests are generated. These lightpaths are assigned in random order with the shortest path in the number of hops and first fit spectrum assignment. A lightpath is blocked if the selected path does not have available slots. For a first-class request, if a protection path cannot be found due to insufficient slots, the lightpath request is not established (both the working path and the protection path will not be assigned).

In the simulation, 50 different lightpath request sets are generated and average results are presented. As there are no existing algorithms in the literature for this problem, we evaluate the performance of DRAMA-PRO with algorithms in which one or more of the three performance-optimizing features of DRAMA-PRO is disabled. The three features are (a) order of recovery using PRE sorting, (b) CR routing, and (c) degradation selection. The baseline algorithms use either sorted recovery (SR) order or random recovery (RR) order, shortest path (SP) or CR routing (CR), and degradation (D) or no degradation (ND). For example, RR-SP-ND is the most basic baseline algorithm in which the requests are recovered with RR order, SP routing, and no degradation. As another example, SR-SP-ND uses SR recovery but with SP routing and no degradation. All the shown penalty values consider the protection lightpath factor α and normal-class lightpath factor β, both of which are set to 0.7.

First, we show the performance results for different mitigation zones of D 1 with the percentage of first-class requests set to 50%. In Fig. 4, we can see that the total penalty of DRAMA-PRO decreases as the size of the mitigation zone increases, which shows that the mitigation zone can benefit recovery and solve the bottleneck problem. We can also observe that the

TABLE I: Recovery of normal and first-class requests for D 1 . |T f | |Tn| |R f | |Rn| BW w f BW p f BWn P w f P p f Pn P total RR-SP-ND 173.7 (158.9) 364.7 (314.6) 150.7 (94.8%) 264.1 (83.9%) 132.1 86.5 125.9 979.3 5608.7 4615.6 11203.7 SR-SP-ND 152.9 (96.2%) 263.7 (83.8%) 133.1 93.8 124.2 860.2 4973.9 5117.4 10951.6 RR-CR-ND 153.5 (96.5%) 269.4 (85.6%) 133.8 87.5 125.9 722.4 5425.8 4334.7 10482.9 RR-SP-D 153.7 (96.6%) 275.3 (87.4%) 133.1 87.1 125.6 711.9 5406.2 4029.6 10147.8 DRAMA-PRO 157.8 (99.3%) 289.2 (91.9%) 135.1 93.4 126.9 396.5 4859.9 4120.2 9376.7 with large mitigation zone. Gbps) of the first-class requests' working path and protection path, and the normal request lightpath, respectively. P w f , P p f , and P n are the average penalty for the three different lightpath types. P total is the total penalty. We can see that DRAMA-PRO can recover more requests and the average bandwidth is generally higher than for baseline algorithms. We note that the penalty improvement for DRAMA-PRO is much more than the bandwidth improvement, because the penalty is weighted differently for different types of lightpaths and DRAMA-PRO is able to take this into account during recovery.

In Fig. 5, we show results for different ratios of first-class to normal-class requests. We note that DRAMA-PRO continues to perform better than the other algorithms for all ratios, but the overall penalty sharply decreases as the ratio of first-class requests becomes high. The reason is that the total number of requests before the disaster is lower when the percentage of first-class requests is high and the total revenue is also lower. In the 20% case, the penalty of DRAMA-PRO is reduced by 30%, 18%, 28%, and 21% over RR-SP-ND, SR-SP-ND, RR-CR-ND, and RR-SP-D. We can see that the penalty reduction between DRAMA-PRO and baseline algorithms decreases for high percentages of first-class requests. This is because much of the spectrum is occupied after protection is "activated" before the recovery, so the flexibility due to the mitigation zone is limited.

In Fig. 6, we show performance results when the disaster is D 2 . We again see that DRAMA-PRO always has the lowest penalty; for instance, when the entire network is the mitigation zone, the penalty is reduced by 30%, 27%, 28%, and 15% over RR-SP-ND, SR-SP-ND, RR-CR-ND, and RR-SP-D. Interestingly, compared to the D 1 disaster scenario, the total penalty values are lower because the bottleneck problem is more severe in D 1 because D 2 occurs at the edge of the network. Both D 1 and D 2 cause one failed node, so the number of recoverable requests is the same on average. However, the penalty decrease percentage of DRAMA-PRO over the baseline algorithms is We show performance results for random disasters in Fig. 6. In this case, one node is randomly selected as the center of the disaster, while the size of the disaster is uniformly distributed in the range [100, 400] km. Results are the average of 10 distinct disasters. We can see that DRAMA-PRO has the lowest penalty and the penalty decreases as the mitigation zone size increases. When the size of the mitigation zone is all, the penalty of DRAMA-PRO is reduced by 17%, 15%, 14%, and 11% over baseline algorithms.

V. CONCLUSION Disaster management is an important problem in EONs. EONs typically have a mix of protected and unprotected lightpaths, but protection is designed for common failures such as one or two links/nodes. In this paper, we introduce DRAMA-PRO, which leverages the backup resources of the protected lightpaths in disaster recovery. DRAMA-PRO also uses the concept of the mitigation zone to recover or reassign multi-class lightpath requests with degraded service. Our results demonstrate that DRAMA-PRO outperforms baseline algorithms across various scenarios and highlights the effectiveness of the mitigation zone in enhancing disaster recovery efforts.