www.elsevier.com/locate/comcom

Computer Communications 29 (2006) 3900–3912

Multiple link failures survivability of optical networks withtraffic grooming capability

Chadi Assi a,*, Wei Huo a, Abdallah Shami b

a Concordia Institute for Information Systems Engineering (CIISE), Concordia University, Montreal, Que., Canadab Department of Electrical and Computer Engineering, The Univeristy of Western Ontario, London, Ont., Canada

Received 30 April 2006; received in revised form 30 June 2006; accepted 3 July 2006Available online 4 August 2006

Abstract

This paper investigates the problem of survivable traffic grooming (STG) in shared mesh optical networks and proposes different frame-works for improving the survivability of low speed demands against multiple near simultaneous failures. Spare capacity reprovisioning hasrecently been considered for improving the overall network restorability in the event of dual failures; here, after the recovery form the firstfailure, some connections in the network may become unprotected and exposed to new failures. Capacity reprovisioning then allocates pro-tection resources to unprotected and vulnerable connections so that the network can withstand a future failure. In this paper, we proposetwo different reprovisioning schemes (lightpath level reprovisioning, LLR, and connection level reprovisioning, CLR); they differ in thegranularity at which protection resources are reprovisioned. Further, each of these schemes is suitable for a different survivable groomingpolicy. While LLR provides collective reprovisioning of connections at the lightpath level, CLR reprovisions spare bandwidth for lowerspeed connections instead. We use simulation methods to study the performance of these schemes under two grooming policies (PALand PAC), and we show that while CLR reprovisions substantially many more connections than LLR (i.e., potentially more managementoverhead) CLR yields a much better network robustness to simultaneous failures due to its superior flexibility in using network resources.� 2006 Elsevier B.V. All rights reserved.

Keywords: Optical networks; Protection; Traffic grooming and routing; Simulations

1. Introduction

Over the past decade, research efforts have focused onimproving the survivability of optical networks using eitherproactive (i.e., protection using preplanned resources) orreactive (i.e., dynamic discovery of alternate resources)mechanisms [1–3]. Recent research has also focused onimproving the service availability of these networks againstmultiple simultaneous failures either through preplannedredundant capacity [4–6] or through capacity reprovision-ing [7–11] or further using p-cycle reconfiguration1 [12] in

0140-3664/$ - see front matter � 2006 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2006.07.005

* Corresponding author. Tel.: +1 514 848 2424; fax: +1 514 848 3171.E-mail addresses: assi@ciise.concordia.ca (C. Assi), w_huo@ciise.

concordia.ca (W. Huo), ashami@eng.uwo.ca (A. Shami).1 In this paper, the terms ‘‘reprovisioning’’ and ‘‘reconfiguration’’ are

used interchangeably. Reprovisioning does not mean a new capacity isplaced into the network.

mesh networks. Most, if not all, of these efforts haveassumed that every user demands a bandwidth equals tothe full wavelength capacity. Currently, the transmissionrate of a wavelength channel is STS-192 (10 Gbps) andexpected to grow to STS-768 (40 Gbps) in the near future.Bandwidth requirement of a typical connection requestvaries, however, from full wavelength capacity to as lowas STS-1 or lower. Hence, it is necessary to efficiently packthese lower speed demands (or connections) onto highcapacity light channels (also known as lightpaths) in orderto better utilize the network resources. This problem hasemerged lately and is known as the traffic grooming prob-lem [13–16]. Traffic grooming refers to the problem of effi-ciently packing low-speed connections onto high-capacitylightpaths in order to better utilize the network resources[13] and has been studied extensively over the past yearsboth for SONET/WDM ring networks [17,18] as well asin optical mesh networks [13–16].

2 A lightpath layer or logical layer is the set of lightpaths currently in thenetwork.

C. Assi et al. / Computer Communications 29 (2006) 3900–3912 3901

Now, how to efficiently groom such low-speed connec-tions while satisfying their protection requirements is bestknown as survivable traffic grooming (STG) problem andpresently is attracting some considerable research efforts[19,20]. The authors of [19] have proposed different frame-works for protecting low-speed connections against singlelink failures in optical mesh networks and have shown thatproviding collective protection of connections at lightpathlevel (PAL) achieves better performance than protectingat the connection level (PAC) while it also requires a small-er number of grooming ports. To make connections surviv-able under various failures, such as fiber cut and duct cut,the authors of [20] studied the static STG problem underthe general shared risk link group diverse routing con-straints where protection is provided at the lightpath level.In this paper, we revisit the STG problem in mesh networksand we study the survivability of connections against multi-ple concurrent failures where concurrent implies that thenew failure occurs before the previous failure has beenrepaired. We focus on mesh networks that are onlydesigned to withstand all single link failures either throughlightpath level protection or through connection level pro-tection with shared backup resources. To combat the effectof multiple failures, we propose to use capacity reconfigu-ration after the occurrence of the first failure in order toreprovision new protection capacity for unprotected or vul-nerable demands. Namely, when a link failure occurs, alldemands routed through that link will fail and are reroutedto their protection connections. These demands and otherdemands whose protection paths were originally routedthrough the failed link become unprotected. Moreover,when a demand is restored onto its protection, the protec-tion capacity is now activated and can no longer be shared;hence other connections sharing the protection resourcesbecome vulnerable. Therefore, one needs to identify theseunprotected and vulnerable connections/lightpaths andassigns/reprovisions for them new protection capacity inorder to improve their robustness.

We present lightpath and connection level reprovision-ing as complementary approaches for STG to achievebetter service robustness against multiple failures. Notethat when connections are protected at the lightpath level,the process of reprovisioning takes place at that level(thereafter referred to as lightpath level reprovisioning,LLR); in other words, only the lightpaths that becomeunprotected/vulnerable need to be reprovisioned. Alterna-tively, if connections are protected at the connectionlevel, reprovisioning takes place at connection level (con-nection level reprovisioning, CLR). One critical differencebetween the two schemes is the granularity at whichbackup bandwidth is reprovisioned and the number ofconnections to be reprovisioned. While in LLR, light-paths (whose number is substantially much smaller thanthe number of connections they carry) are reprovisioned,individual connections are reprovisioned in CLR. Onedrawback of LLR is that when a lightpath remainsunprotected after reprovisioning, all the connections rout-

ed through this light-path are unprotected. Moreover, alightpath is reprovisioned by requesting or searching forresources on the physical layer although protectionresources may be available at the lightpath layer.2 CLRon the other hand reprovisions unprotected/vulnerableconnections first at the logical layer instead and then atthe physical layer. We compare the performance of thesetwo schemes and present some simulation results on therobustness of the network under both reprovisioningframeworks. Our results show that connection level rep-rovisioning substantially outperforms the lightpath levelreprovisioning. The rest of the paper is organized as fol-lows. Section 2 presents an overview of the survivabletraffic grooming problem and we present some simpleheuristics and compare their performance. Section 3 pre-sents a detailed study of the reprovisioning approachesand we quantify their performances in Section 4. Finally,we conclude in Section 5.

2. Survivable traffic grooming

2.1. Background

Grooming connections while still satisfying their pro-tection requirements is known as survivable traffic groom-ing, STG [19,20]. Different schemes have been proposedfor protecting connections, namely protection at lightpathlevel (PAL), mixed, and separate protection at connectionlevel (MPAC and SPAC). Under PAL, a connection istypically routed through a sequence of protected light-paths (p-lightpaths), where a p-lightpath is a pair of work-ing and link-disjoint backup lightpaths. A workinglightpath consumes one grooming add port and one dropport and wavelengths along the route of a lightpath arereserved and configured. Resources for a protection light-path, on the other hand, are only reserved and they aresetup after the failure. Hence, a protection lightpath doesnot consume any grooming add/drop ports. Normally, ademand is routed over a multihop route (sequence ofp-lightpaths) if there is no direct lightpath with enoughcapacity connecting the source and the destination ofthe demand. In case of a failure along the working light-path, the carried traffic (i.e., the set of connections routedthrough this lightpath) is restored onto the protectionlightpath; only the end (and intermediate) nodes of thelightpath are aware of the switching and the end nodesof the failed connections are oblivious to this protectionswitching.

Fig. 1a shows an illustrative example of 4 p-lightpaths.A demand, d1, between nodes A and F can be routedthrough lightpaths (l1–l2), where l1 and l2 are protectedby b1 and b2 respectively. Note that under PAL twop-lightpaths can share wavelengths along their protection

a b

Fig. 1. Illustrative examples of STG.

3902 C. Assi et al. / Computer Communications 29 (2006) 3900–3912

lightpaths if their corresponding working lightpaths arelink disjoint. For example, l2 and l3 can share the sameprotection wavelength along link (D–E) since they arelink disjoints.

Alternatively, PAC provides end to end protection atthe connection level and has two variants (SPAC andMPAC) that differ in the way connections are protected[19]. In SPAC, a connection is routed via a link-disjointworking and backup routes. The working traverses asequence of lightpaths and the backup traverses a sequenceof wavelength links, where each wavelength link consumesa pair of grooming ports, add and drop, at each end of thelink. Under MPAC, a demand is routed via link-disjointworking and backup paths each traversing a sequence oflightpaths. Each lightpath consumes a pair of groomingports, one add at the source and one drop at the destina-tion. Every lightpath traversed by a working connectionreserves a fixed amount of bandwidth to carry the traffic.A lightpath that is traversed by a backup connection corre-spondingly reserves a fixed amount of its capacity to pro-tect against the failure of the working connection. In thispaper, we will only use MPAC and we use the term PACto refer to this grooming policy.

A working connection fails when any of the lightpathsthat it traverses fails. Upon the failure, the source nodeof the failed demand switches traffic from the working intoits corresponding backup. Bandwidth sharing is achievedunder MPAC when two demands have their correspondingworking connections physically end-to-end link-disjointand their backup connections traverse the same light-path(s). Fig. 1b shows an example of PAC grooming.The figure shows a set of existing lightpaths; when a newdemand d1 arrives (e.g., between nodes C and H anddemanding a bandwidth of STS-12), it is routed throughl5 and l2 and is protected by lightpaths l6, l4, and l1. Ademand, d2, between nodes D and E and bandwidth2 · STS-12 can be routed through l3 and protected by l4.Here, d1 and d2 are both end-to-end link-disjoint and bothshare the same lightpath l4, hence they can both share theprotection bandwidth reserved along l4 and the new protec-tion bandwidth reserved along l4 becomes 2 · STS-12.When a link fails, the lightpaths routed through that linkwill fail and hence the connections routed through everyfailed lightpath will also fail.

2.2. Comparison between PAL and PAC

These schemes differ in the routing and the backupbandwidth sharing. In terms of routing, PAL providesend to end protection at the lightpath level whereas PACprovides end to end protection at the connection level. InPAL, after the failure of a link, the end nodes of a failedlightpath configures the protection lightpath and switchthe traffic into it and the end nodes of the connectionsare unaware of this process. Alternatively, in PAC theend nodes of the failed connections configure their backuppaths and restore the traffic. Under PAL, only working andprotection paths of a p-lightpath must be link disjoint and aconnection routed through a sequence of p-lightpaths isnormally protected against any single link failure (that isthe working and protection path of a demand need notbe end to end link-disjoint). In PAC, however, the workingand backup routes of a demand must be end to end linkdisjoint; when a demand spans multiple lightpaths, itbecomes difficult to find a protection path.

With respect to backup sharing, protection wavelengthlinks are the resources that can be shared in PAL. Namely,two p-lightpaths can share the same protection wavelengthlink if their working lightpaths are link disjoint and theirprotection lightpaths traverse through that same protectionwavelength. Hence, all working connections traversing thesep-lightpaths are said to be sharing that protection wave-length link. However, under PAC (i.e., MPAC) the sharingunit is a lightpath (or the backup bandwidth reserved in alight-path). Hence, two demands (d1 and d2) under PACcan share protection bandwidth in a lightpath l if (1) theircorresponding working connections are end to end diverselyrouted and (2) their protection connections traverse light-path l. Then the backup bandwidth required on l ismax(bw1,bw2) where bw1 and bw2 are the bandwidth require-ments of demands d1 and d2, respectively. Clearly, since alightpath may traverse multiple physical links and a connec-tion is routed through multiple lightpaths, it is less likely thatconditions (1) and (2) are together satisfied and hence band-width sharing is hard to achieve. All these reasons makePAC algorithm less attractive than PAL; the authors of[19] have evaluated using simulations the performance dif-ferences between PAL, SPAC, and MPAC. Overall resultsshowed that PAL achieves best performance when the

C. Assi et al. / Computer Communications 29 (2006) 3900–3912 3903

number of grooming ports is either small or moderate.Moreover, as mentioned earlier, under PAL only the work-ing lightpath consumes add/drop grooming ports whereasunder PAC every lightpath consumes add/drop groomingports (note in SPAC every wavelength link along the protec-tion route consumes one pair of add/drop ports). PAC, onthe other hand, allows both working and protection connec-tions of different demands to be routed through the samelightpath, a flexibility that does not exist under PAL.

2.3. STG grooming heuristics

Clearly, while PAL trades the flexibility in grooming forthe freedom of backup sharing, PAC allows working andbackup connections of different demands to be groomedon the same lightpath. However, one major drawback forPAC is the difficulty in sharing backup bandwidth betweenthe demands. Unlike PAL where wavelength links areshared between p-lightpaths, in PAC two demands canshare backup bandwidth if the two conditions of the previ-ous section are both satisfied. Since, every lightpath tra-verses a sequence of wavelength links, these twoconditions are difficult to meet due to the conflict in findinglink disjoint working routes for demands whose protectionroutes share the same lightpath. This conflict is furtherexacerbated as the physical hop count of lightpaths getslarger. However, due to the flexibility of PAC, we proposesome simple modifications to improve the efficiency ofbackup bandwidth sharing. We note first that if the physi-cal hop count of every lightpath is limited to one, then interms of backup sharing MPAC becomes similar to SPAC;further, since MPAC allows protection and working capac-ity to be groomed on the same lightpath, then this newMPAC-1 (1 means a lightpath is limited to one hop)achieves both high flexibility and better bandwidth sharing.However, the grooming capacity requirement could beexcessive. Therefore, we propose to limit the length of alightpath in order to improve the backup bandwidth shar-ing while still maintaining the flexibility of routing. Thisnew version of PAC is referred to as PAC-HCL, whereHCL refers to Hop count limit and HCL P 1.

Next, we explain the STG heuristic; in response to a newconnection request, PAC-HCL first computes two link dis-joint paths from source to destination using Dijkstra Algo-rithm in the existing logical topology. Every lightpathalong the working path must have enough bandwidth tocarry the new demand. Along the protection path, band-width sharing is used. Every lightpath (l) reserves backupbandwidth (vl) to protect all the connections whose protec-tion paths traverse through this lightpath. Note,vl ¼ max8e02Efve0

l g, where ve0l is the amount of bandwidth

reserved on lightpath l to protect against the failure of linke (0 6 ve0

l 6 OC-192) and E is the set of all links in the net-work. When a new connection of bandwidth w is protectedby l, the additional backup bandwidth reserved on l is al

and is determined as follows: al ¼ maxfvnewl � vl; 0g, where

vl ¼ max8e02Efve0;newl g and ve0;new

l ¼ ve0l þ w if the working

connection of the new demand traverses through e 0, other-wise ve0 ;new

l ¼ ve0l In case there is no enough bandwidth to

route and/or protect the demand on the logical layer, thennew a lightpath(s) is setup on the physical layer for eitherthe working or protection or both paths.

At the physical layer, the source node computes theshortest path route to the destination (s�x1�x2�� � ��xn�d).The source will select a node xi from the shortest path thatis HCL hops away and check whether there is a direct light-path already setup with enough capacity (or with enoughsharable capacity in case of a protection connection). Ifthere is not, the source node checks for a node that isHCL-1 hops away from the source node and so on untila lightpath is found. If a node (xi) is found, the same pro-cedure as before is run again between xi and the destina-tion. Let xt(xt = s if there is no direct lightpath between s

and any node on its shortest path that is at most HCL hopsaway from s) be the node after which there is no outgoinglightpath(s) to any node along the shortest path to d. Atthis point, the algorithm tries to ‘‘setup’’ a new lightpathfrom xt to a node that is HCL hops away. If that fails, thena node that is HCL-1 hops away is checked and so on untila lightpath is setup. If a lightpath is found, then the sameprocedure is repeated until a route is established all theway to the destination. At any step, if a lightpath couldnot be setup, the request is dropped and all allocatedresources are released. With regards to PAL, the samealgorithm as in [19] is implemented.

Algorithm 1. Pseudo code of the provisioning in PAC-HCL

Input: A network represented as a directed graphG = (V, E,k,P), where V is a set of nodes, E is the setof unidirectional physical links, k specifies the number ofwavelengths on each link, and P specifies the number ofgrooming ports at each node. The logical topology of thisnetwork is represented as a graph G 0 = (E,L), where L isthe set of lightpaths.

Output: Link-disjoint working and backup paths, orNULL if fails.

1. Compute a pair of shortest and physically link-disjointlogical paths (i.e., a working path with enough band-width and a protection path with enough sharable band-width) from src to des; if successful, return the twopaths, otherwise compute the shortest physical workingpath wroute = (src�x1�x2�� � ��xn�des). The sourcewill select a node xi and go to step 2.

2. The node s (s = wroute[0]) will check whether there is anexisting direct lightpath to a node along the path whichis HCL hops away and has enough capacity; if there isnot, check for a lightpath with HCL-1 hops from thesource node and so on until a lightpath is found. If thereis such a lightpath (assume its destination node is xt),then wroute ‹ (xt � xt+1 � � � � � des) and repeat step 2on wroute. If a working path has been found to the des-tination, go to step 4, otherwise, go to step 3.

3904 C. Assi et al. / Computer Communications 29 (2006) 3900–3912

3. Let xt be the node after which there is no outgoing light-path(s) to any node along wroute. Then, try to establish anew lightpath from xt to a node that is HCL hops away.If this fails, then a node that is HCL-1 hops away ischecked and so on until a new lightpath is setup. If alightpath is setup and assume its destination node isxt0 , then wroute ðxt0 � xt0þ1 � � � � � desÞ and go to step3. If a working path has been found to the destination,go to step 4; otherwise, return NULL.

4. Eliminate the working path in graph G, find the shortestphysical path broute from src to des; repeat the sameprocedure in steps 3 and 4 on broute to provision thebackup path (backup sharing as explained in Section2.3 is considered). If the backup path can be provisionedsuccessfully, return working and backup paths; other-wise, release the resources reserved along the workingpath and return NULL.

3. Connection and lightpath level reprovisioning

Various research efforts [4–6] have addressed the prob-lem of routing connections under dual-failure assump-tions, and findings show that designs offering completedual-failure restorability require more than double theamount of spare capacity. In order to avoid this excessivedeployment of extra spare capacity in the network, capac-ity reprovisioning or reconfiguration after the occurrenceof and recovery from the first failure has been proposed[7–12]. This problem has recently been studied for meshnetworks where every request is considered to consumethe full wavelength capacity. After the occurrence of thefirst failure, the failed lightpaths are restored from theirworking paths into their protection paths. These recov-ered lightpaths and other lightpaths that were originallyprotected by protection resources on the failed link nowbecome unprotected and exposed to a second failure.Moreover, protection wavelength links along recoveredlightpaths are now active and hence can no longer beshared with other demands. As a result, all demands thatwere not directly affected by the failure but their protec-tion paths can no longer share backup resources becomevulnerable to new failures.

Spare capacity reconfiguration provides a mechanismby which one can find and allocate new protection capac-ities for these newly-unprotected lightpaths without a pri-ori knowledge of the location of the second failure. Weassume multiple near simultaneous link failures, where asecond failure occurs after the first failure is recoveredfrom, but before it is physically repaired. In this sectionwe consider low-speed connection requests and proposetwo frameworks for improving their survivability againstmultiple failures. The first scheme is lightpath level repro-visioning (LLR) that relies on PAL and the second is con-nection level reprovisioning (CLR) which rather relies onPAC.

3.1. LLR

As mentioned before, under PAL a connection traversesa sequence of p-lightpaths. The working route of a connec-tion traverses the sequence of working lightpaths and isprotected by the sequence of corresponding protectionlightpaths. Consider every link in the network to be associ-ated with a conflict set to identify the sharing potentialbetween protection lightpaths [19,21]. The conflict set ve

for link e can be represented as an integer set,fve0

e j8e0 2 E; 0 6 ve0e 6 kðeÞg, where ve0

e is the number ofworking lightpaths that traverse link e 0 and are protectedby link e, E is the set of all links in the network, and k(e)is the number of wavelengths per link e. Then, the numberof protection wavelengths reserved on link e to protectagainst the failure of any other link in the network is givenby v�e ¼ max8e02Efve0

e g.When a link (e.g., f) fails, all lightpaths routed through

that link also fails and accordingly all the connections car-ried by these lightpaths fail. The failed lightpaths are rero-uted onto their corresponding protection lightpaths andconsequently become unprotected and exposed to a newfailure. For example, when link (G–H) in Fig. 1a fails, thenlightpath l3 fails and is restored into its protection lightpathb3. All connections routed through l3 will fail and will berestored to b3. Note that b3 and the restored connectionsare all exposed to a new failure. Moreover, all the demandsthat were originally protected by link f have lost their pro-tection resources and become unprotected. For example,all connections traversing l4 now become unprotectedbecause the backup path b4 has lost its protection wave-length on the failed link (G–H).

Upon the recovery of the failed lightpaths to their pro-tection routes, some backup wavelengths on a link, say e,may be activated if at least one of these protection light-paths traverses through link e. Hence, the number of newavailable protection wavelengths on link e is va

e ¼ v�e � vfe

and the number of protection wavelengths on link erequired to protect against a future link failure in the net-work is vnew

e ¼ max8e02E�f fvee0g. If vnew

e > vae , then some of

the existing lightpaths that were not directly affected bythe failure are vulnerable to a new failure because link e

does not have enough protection capacity. For example,before the failure, link (D–E) reserves only one wavelength(v�DE ¼ 1) to protect l2 and l3. When l3 is rerouted to b3 afterthe failure, va

DE ¼ 0 and vnewDE ¼ 1, hence l2 is vulnerable to a

new failure.Let e1,e2, . . . ,eF be the set of links traversed by some

active protection light-paths after the first failure; thenthe set of all vulnerable lightpaths can be identified. A con-nection that traverses an unprotected p-lightpath is unpro-tected and similarly a connection that traverses avulnerable p-lightpath is also vulnerable. In LLR, theresources along the failed lightpaths are released, and everyunprotected lightpath that is identified is reprovisioned bycomputing and allocating new protection capacity for thislightpath. On the other hand, some of the vulnerable

C. Assi et al. / Computer Communications 29 (2006) 3900–3912 3905

lightpaths need to be reprovisioned in order to reduce thevulnerability of the network to a second failure. When avulnerable light-path is reprovisioned, some other vulnera-ble lightpaths may become protected [9,10] if they wereoriginally contending with the reprovisioned lightpath forthe same protection wavelength on a particular link.Hence, a vulnerable light-path l becomes protected afterthe reprovisioning of another lightpath, when for every link(e) along the backup of l we have va

e P max8e02E�f fvee0g.

Each time a new vulnerable lightpath is reprovisioned,the set of remaining vulnerable lightpaths is identified; thisprocedure continues until all vulnerable lightpaths are rep-rovisioned or no more reprovisioning is possible. Note thatthere are many policies [9] for selecting a vulnerable light-path from the set, for simplicity we select a vulnerablelightpath randomly.

3.2. CLR

CLR is used when connections are protected at the con-nection level. Recall that a connection traverses a sequenceof lightpaths and is also protected by a sequence of link dis-joint lightpaths. The backup sharing between two connec-tions is at the lightpath level, see Section 2. Let Ae0

l be theset of all connections ci (i = 1, . . . ,M) each with bandwidthwi traversing physical link e 0 and protected by lightpath l.The bandwidth reserved on lightpath l to protect againstthe failure of link e 0 is ve0

l ¼PM

i¼1ðwiÞ; 0 6 ve0l 6 STS-192.

The total amount of backup bandwidth reserved on light-path l to protect against the failure of any link e 0 in the net-work is v�l ¼ max8e02Efve

l0g.

Algorithm 2. Pseudo code of LLR

1. Identify a set Lu composed by unprotected lightpaths(lu

1; lu2; . . . ; lu

m), then release unavailable resources alongthese unprotected lightpaths and reprovision them byallocating new protection wavelength(s) in the physicaltopology, as explained before. If an unprotected light-path lu

i cannot be reprovisioned, move it to another setLu

after.2. Identify a set Lv composed by vulnerable lightpaths

(lv1; l

v2; . . . ; lv

m). For each vulnerable lightpath li, reprovi-sion it using the same method as in step 1. If not success-ful, move li to another set Lv

after; otherwise, remove lifrom Lv and reidentify other vulnerable lightpaths inLv and Lv

after, then repeat step 2 until there are no vulner-able lightpaths or no more reprovisioning is possible.

When a link f fails, all lightpaths traversing link f failand accordingly all connections routed through these light-paths will also fail. These connections will be rerouted ontotheir protection routes and become unprotected and henceexposed to new failures. For example, a connection c1 ofbandwidth 2 · STS-l between nodes C and H is routedthrough working path (l5–l2) and protected by (l6–l4–l1),see Fig. 1b. When link (C–G) fails, the connection is

restored to its end to end backup path and after recovery,the connection becomes exposed. Similarly, all connectionsthat were originally protected by any light-path traversinglink f also become unprotected. For example, a connection(c2) between nodes C and E whose working is (l6, l4) can beprotected by l5. Hence, when (C–G) fails, l5 fails and theconnection c2 loses its protection bandwidth and becomesunprotected. Now, when a connection is restored into itsprotection route, the backup bandwidth reserved on anylightpath along the protection route for this connection isactivated and can no longer be shared. Hence, a lightpathl will have va

l ¼ v�l � vfl available protection capacity to pro-

tect against a new failure. The protection capacity required,however, on lightpath l to protect against the future failureof any link is vnew

l ¼ max8e02E�ffve0l g. For example, if a con-

nection c3 (4 · STS-l) between nodes D and E (Fig. 1b) hasits working traversing l3 and protected by l4; this connec-tion can share protection bandwidth along l4 with connec-tion c1 since the working paths of these two connections arelink disjoint. Hence, l4 reserves max(2 · STS-l, 4 · STS-l) = 4 · STS-l to protect these two connections. When link(C–G) fails, the available backup bandwidth on l4 becomes4 · STS-1 � 2 · STS-l = 2 · STS-l, which is not sufficientto protect c3. Hence, c3 becomes vulnerable to a newfailure.

Let Cl be the total capacity of a lightpath, Rl be theresidual capacity, Al be the bandwidth used by workingand active backup connections; hence, Rl ¼ Cl � Al � va

l .Let D = {l1, l2, . . . , l1} be the set of all lightpaths on whichfailed connections are rerouted. If for every li (i = 1, . . . ,L),(1) va

liP vnew

li, then there will be no vulnerable connections

in the network; or (2) valiþ Rli P vnew

li, then the lightpath li

has enough available capacity (and should be reserved) thatcan protect against the failure of any link in the network.Hence, the backup capacity reserved along li becomesvnew

li¼ max8e02E�f fve0

lig. In this case, only unprotected con-

nections as mentioned earlier need to be reprovisioned.Alternatively, when (1) and (2) are not satisfied for at leastone lightpath li, then some connections in the network arevulnerable to a new failure. In this case, the set of all vul-nerable connections is identified (as in LLR); a vulnerableconnection is reprovisioned by allocating new protectioncapacity on its backup route. The set D is updated and con-ditions (1) and (2) are checked again for vulnerable connec-tions. The same procedure is repeated until there are nomore vulnerable connections or no more reprovisioning ispossible.

Algorithm 3. Pseudo code of CLR

1. Identify a set U of unprotected connectionsCU

1 ;CU2 ; . . . ;CU

m .2. Reprovision each connection CU

i . If not successful,move CU

i from U to another set Uafter (which storesthe unprotected connections after reprovisioning).Repeat step 2 until U is empty or no more reprovision-ing is possible.

3906 C. Assi et al. / Computer Communications 29 (2006) 3900–3912

3. Initialize a set V composed by vulnerable connectionsCV

1 ;CV2 ; . . . ;CV

m, which are identified by the modeldescribed in Section 3.2.

4. Reprovision connection CVj . If successful, remove CV

j

from V; otherwise, move CVj to a set Vafter and in both

cases re-evaluate the remaining vulnerable connectionsin the network (i.e., two sets V and Vafter) for vulnerabil-ity; those that become protected are removed from thetwo sets. Repeat step 4 until V is empty and exit. Allconnections in Vafter are vulnerable and exposed forfuture failures.

3 This flat capacity networks is artificial and is unrealistic of realnetworks. It is only used as a suitable test case for research purposes.

3.3. LLR vs. CLR

Both of these schemes rely on spare capacity reprovi-sioning after the first failure in order to improve the net-work survivability against a new failure. However, thetwo schemes present some critical differences.

The first difference between the two schemes pertainsto the granularity at which each scheme reprovisions pro-tection bandwidth for its demands. In LLR, unprotectedand vulnerable lightpaths are identified after a link fail-ure; all unprotected lightpaths are reprovisioned andsome of those that are vulnerable are reprovisioned inorder to resolve the conflict between lightpaths sharingthe same protection resource and reduce the network vul-nerability to future failures. Hence, the end nodes of thedemands are not aware of this re provisioning process.The source node of a failed p-lightpath reconfiguresnew backup resources without the intervention of endnodes of the connections it carries. Therefore, when anunprotected or vulnerable lightpath is successfully repro-visioned, then all demands traversing this lightpathbecomes protected conversely, if the lightpath could notbe reprovisioned, then all the demands it carries areunprotected. Thus, LLR provides collective reprovision-ing for low speed connections. On the other hand, inCLR connections are reprovisioned at a smaller granular-ity. Here, the number of connections that are unprotect-ed or vulnerable is substantially much more than thenumber of unprotected or vulnerable lightpaths (althoughthe number of unprotected or vulnerable connections inboth cases may be the same). In CLR, the end node ofevery unprotected/vulnerable connection needs to repro-vision new protection capacity; hence, the managementoverhead may be excessive.

A second difference between LLR and CLR pertains tothe method of reprovisioning. In LLR, all lightpaths arereprovisioned by setting up new protection resources onthe physical layer. If resources are not available, then thereprovisioning fails and the lightpath remain unprotected.Alternatively, under CLR, unprotected connections arereprovisioned first on the logical layer; that is, the algo-rithm first attempts to allocate protection resources onalready existing lightpaths. If this fails, then the physicallayer is requested to setup new lightpaths. Hence, althoughthe number of unprotected connections to be reprovisioned

(under CLR) is much larger than the number of unprotect-ed lightpaths (under LLR), CLR enjoys more flexibility forcapacity reprovisioning. This is particularly advantageouswhen CLR is implemented with PAC-HCL since this latterhas better flexibility and more efficient bandwidth sharingthan PAC.

4. Performance evaluation

This section presents quantitative comparisons betweenPAL, PAC, and PAC-HCL (HCL = 3 throughout the sim-ulations) presented in Section 2 and it also compares theperformance of LLR and CLR presented in Section 3.We simulate a dynamic network environment where con-nection requests are uniformly distributed between allsource–destination pairs and their arrival process is Pois-son. The connection holding time of each connection fol-lows a negative exponential distribution. The capacity ofeach wavelength is STS-192; the number of the connectionrequests follows the distribution: STS-1:STS-3c:STS-12c:STS-48c = 12:5:2:1. The load (in Erlangs) is definedas the arrival rate of connection requests times averageholding time times a connections average bandwidth nor-malized in the unit of STS-192. The network we simulatedconsists of 24 nodes and 43 bi-directional links [9,19] andthe number of wavelengths per link is W = 8.3 Our exper-imental work is divided into two parts; the provisioningor grooming performance and the reprovisioningperformance.

4.1. Provisioning results

We compare PAL, PAC, and PAC-HCL using the fol-lowing metrics: bandwidth blocking probability (BBP),length of working and backup paths, impact of groomingcapacity, and efficiency of backup sharing.

Fig. 2 shows the BBP for the different groomingschemes; the number of grooming ports is 16 (16 addand 16 drop) per node. The BBP is defined as the amountof bandwidth blocked over the amount of bandwidthrequested. The figure shows that PAL and PAC-HCLhave comparable performance with PAC-HCL slightlyoutperforming PAL; while PAC on the other hand isexhibiting worse performance than the other schemes.The reasons are as follows. First, under PAC, a connec-tion traverses a sequence of lightpaths and is protectedby another physically disjoint sequence of lightpaths.When a lightpath traverses more hops (i.e., is longer),finding two sets of lightpaths that are end to end physical-ly disjoint becomes more difficult (physical disjoint con-straint). Second, sharing of backup bandwidth underPAC is end to end; that is, as mentioned in Section 2,two connections must be link-disjoint themselves and

12 24 36 48 6010

10

10

100

Load (Erlangs)

Ban

dwid

th B

lock

ing

Pro

babi

lity

PAC vs. PAL

PAC

PAL

Fig. 2. Bandwidth blocking probability.

C. Assi et al. / Computer Communications 29 (2006) 3900–3912 3907

should have their protection paths traversing the samelightpath in order for them to share protection bandwidthon that lightpath. This is difficult to achieve under PACdue to the physical disjoint constraint particularly whenlightpaths may traverse more physical hops. Third, inPAC although the bandwidth on the existing lightpathsmay be available for carrying new connections, the phys-ical disjoint constraint prevents some of these connectionsfrom being routed on the logical topology and insteadthey are routed on the physical topology by setting upnew lightpaths and therefore consuming new wavelengths.And fourth, since a connection when successfully routedmay traverse more physical hops, it essentially consumesmore bandwidth resources and therefore increases thebandwidth blocking probability.

Alternatively, in PAL, a connection traversing p-light-paths does not necessarily have to be end to end disjoint;only the working and protection lightpaths of a p-light-

path need to be. Moreover, backup sharing is not endto end between connections and it is at the p-lightpath

level.4 That is, two connections can share protectionbandwidth although they are not end to end link-disjointthemselves. It is sufficient that they both traverse a pair ofp-lightpaths where the working of these p-lightpaths aredisjoint and their protection share a common wavelengthlink. PAC-HCL, on the other hand, outperforms PALsince it allows the grooming of protection and workingbandwidths on the same lightpath. It also outperformsPAC since restricting the hop count of a lightpath yieldsbetter flexibility in finding disjoint routes on the logicaltopology and furthermore backup bandwidth sharing isbetter exploited.

4 In a sense, PAL behaves like link protection of a mesh networkwhereas PAC behaves like path protection.

Fig. 3 shows the physical hop count for working andprotection connections in all three schemes. We have twofindings here. First, connections under PAL are routedthrough longer routes than the connections under PAC,PAC-HCL. Note that PAL allows this because ‘‘backupsharing’’ condition and ‘‘physically link-disjoint’’ conditionare not end-to-end and rather they are only at the lightpathlevel. Second, as the load increases, physical hops of work-ing/backup paths in all schemes decrease because longerlightpaths are blocked and connections tend to traverseshorter routes under higher loads. As expected, by limitingthe hop count of lightpaths in PAC-HCL connections tendto traverse shorter hops and hence consume less bandwidthresources; this is one of the reasons that PAC-HCL outper-forms other schemes.

So far, we have neglected the effects of the networkgrooming capacity on the performance of the groomingschemes. Fig. 4 shows the BBP vs. grooming capacity whenthe network load is 24 Erlangs. The figure shows when thenumber of grooming add/drop ports is smaller, PAL out-performs PAC and PAC-HCL. That is expected since aprotection lightpath in a p-lightpath under PAL does notconsume any grooming ports. Unlike PAL, all lightpathsare setup under PAC and PAC-HCL and each consumesone pair of add/drop grooming ports. Therefore, when thisnumber is small, the poor performance of both schemes ofPAC is evident (64–73% blocking). However, as the num-ber of grooming ports increases, the performance graduallyimproves. One notable observation is that PAC-HCL out-performs PAC, which is different than one would expect;that is, the shorter is the lightpath, the more groomingports one needs to consume. The reason PAC-HCL showsbetter performance than PAC is due to the four reasonsmentioned before. The bandwidth in the logical topologyis more judiciously used due to the increased routing flexi-bility and better bandwidth sharing. Therefore, fewer light-paths are setup and hence fewer grooming ports areconsumed. Note that when the number of grooming portsis increased to 16, PAC-HCL slightly outperforms PAL.This is consistent with Fig. 2 and can be explained by sim-ilar reasons. It is important to mention here that the aver-age nodal degree of the network studied is 3.74.

Next, we study the sharing efficiency of backup band-width under PAC and PAC-HCL. We do not considerPAL, since sharing is not end to end and is done betweenp-lightpaths at the wavelength level (i.e., PAL normallyhas better sharing). We measure the total amount ofbackup bandwidth reserved at a particular load (e.g., 48Erlangs) throughout the simulation time for both schemes.The base of comparison is the dedicated protection, inwhich no bandwidth sharing is allowed. Here, if the setof connections protected by a particular lightpath isci(i = 1, . . . ,n) with wi bandwidth per demand, then theamount of backup bandwidth reserved on that lightpathto protect those demands is

Pni¼1ðwiÞ If sharing is allowed,

then the backup bandwidth reserved on a lightpath l isv�l ¼ max8e02Efve0

l g, where ve0l is the bandwidth reserved on

12 24 36 48 603.5

4

4.5

5

5.5

6

6.5

7

Load (Erlangs)

Phy

sica

l Hop

s of

Wor

king

Pat

hsPAC

PAL

a

12 24 36 48 605

5.5

6

6.5

7

7.5

8

8.5

9

9.5

10

Load (Erlangs)

Phy

sica

l Hop

s of

Bac

kup

Pat

h

PALPAC

b

Fig. 3. Average hop count of connections.

4 8 12 160

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

Number of Grooming Ports

Ban

dwid

th B

lock

ing

Pro

babi

lity

Load = 24 (Erlangs)

PAC

PAL

Fig. 4. BBP vs. grooming capacity.

Simulation Time (%)

0 20 40 60 80 1000

1000

2000

3000

4000

5000

6000

7000

8000

9000

PAC

Fig. 5. Backup bandwidth sharing performance.

5 The total number of connections in the network when the link fails inPAC is smaller than PAC-HCL and the latter is slightly smaller than thatunder PAL. Example, 2191 vs. 2340 vs. 2390 at 60 Erlangs loads.

3908 C. Assi et al. / Computer Communications 29 (2006) 3900–3912

l to protect against the failure of link e 0 in the network;ve0

l ¼PM

i¼1ðwiÞ; 0 6 ve0l 6 STS-192.

We calculate the saving that bandwidth sharing yieldsover the dedicated protection case under both schemes;e.g., the saving per lightpath l is

Pni¼1ðwiÞ � v�l . Clearly,

as Fig. 5 shows, the saving under PAC-HCL is more thanthat of PAC which means that backup bandwidth sharingis more efficient under PAC-HCL. The figure shows a max-imum bandwidth of almost 3000 STS-1 that PAC-HCL canadditionally save over the savings achieved by PAC. Onaverage this additional saving is 1772 STS-1. We shouldalso note here that under PAC-HCL, more demands areadmitted into the network (11.57% more than PAC) andthat the bandwidth reserved to protect the connections ison average 463 STS-1 less than that of PAC. So, comparedwith PAC, PAC-HCL protects more demands by using lessresources.

4.2. Reprovisioning results

In this section, we compare the performance of LLRand CLR in improving the network robustness againstmultiple failures. We simulate the failure of one unidirec-tional link and we calculate the percentage of unprotect-ed/vulnerable connections in the network before andafter reprovisioning for the two schemes.

Fig. 6 shows the percentage of unprotected connec-tions.5 Clearly, under PAL the percentage of unprotectedconnections before reprovisioning is more than PAC andPAC-HCL. To understand the reason, we note here thatthe set of unprotected connections include (1) connectionsthat directly fail and (2) connections that become unpro-

12 24 36 48 60

0

0.05

0.1

0.15

0.2

0.25

Load (Erlangs)

Per

cent

age

of U

npro

tect

ed C

onne

ctio

ns

PAC, before CLRPAC, after CLR

PAL, before LLRPAL, after LLR

Fig. 6. Unprotected connections.

Table 1PAC-HCL

Loads A B C D

12 85 85 0 024 170 160 9 136 342 309 30 348 374 305 65 460 461 360 79 22

Table 2PAC

Loads A B C D

12 115 114 1 024 230 215 5 1036 319 290 12 1748 516 431 56 2960 594 473 55 66

C. Assi et al. / Computer Communications 29 (2006) 3900–3912 3909

tected because they lost their protection connections. Since,generally more connections are admitted into the networkunder PAL, normally more connections in category (1)become unprotected. However, our simulation results showthat there is a slight higher number of admitted connec-tions to the network in PAL than PAC and PAC-HCL.Therefore, this higher percentage shown in Fig. 6 is mainlycoming from category (2). To elaborate, note the fact thatPAL has a better backup bandwidth sharing than PAC andPAC-HCL; hence, a large number of connections directlylose their protection paths when a link fails and thisexplains the higher percentage of unprotected connections.Further, note that under PAL the percentage decreases asthe load increases (e.g., from 21% to 15% as the load variesbetween 12 Erlangs and 60 Erlangs). Although the percent-age of unprotected connections decreases, it does notnecessarily mean that the number of unprotected connec-tions at higher load is lower in the network. The reasonis that at a higher load, the total number of connectionsadmitted into the network becomes large and hence whena link fails, the fraction of unprotected demands is higherin comparison with the fraction at lower loads althoughthe percentage is lower. PAC and PAC-HCL on the otherhand shows similar results; the percentage of unprotectedconnections under PAC-HCL is slightly smaller, howeverthe total number of unprotected connections between thetwo schemes is very close.

Now after reprovisioning, LLR yields a large number ofunprotected connections by comparison with CLR. Thereason that LLR does not have good performance is dueto the granularity at which LLR reprovisions connections;here, only unprotected lightpaths are reprovisioned,instead of unprotected connections, by requesting resourc-es from the physical layer. This means, although resourcesmay be available at the lightpath layer, they cannot beexploited. Moreover, when LLR fails to reprovision alightpath, all connections traversing that lightpath remain

exposed to a new failure. Alternatively, CLR reprovisionsconnections at a finer granularity than LLR; every unpro-tected connection is identified and an attempt is made toprotect that connection. CLR exploits resources at the log-ical (or lightpath) layer to find sufficient protection resourc-es. When this fails, it requests resources from the physicallayer to setup new lightpaths in order to protect exposedconnections. Accordingly, CLR shows a much better per-formance than LLR. Our simulation showed that morethan 80% of the unprotected connections are successfullyreprovisioned using CLR at the logical layer whereas onlyless than 20% of connections are reprovisioned by settingnew lightpaths at the physical layer. Fig. 6 also shows thatalthough PAC and PAC-HCL both use CLR, PAC-HCLyields a slightly lower percentage of unprotected connec-tions after reprovisioning. This is due to the fact that underPAC, a connection traverses a longer path (i.e., largerphysical hop count) and hence consumes more networkresources than PAC-HCL. Moreover, when PAC-HCL isused, the physical layer has more resources than PAC.Tables 1 and 2 show our simulation results that presentthe numbers of connections to be reprovisioned in physi-cal/logical topology under PAC and PAC-HCL; columnsA–D represent the number of unprotected and vulnerableconnections before reprovisioning, the number of connec-tions successfully reprovisioned in the logical topology,the number of connections successfully reprovisioned inthe physical topology and the number of unprotected con-nections left after reprovisioning (note that, a vulnerableconnection becomes unprotected if it cannot be reprovi-sioned) respectively. Clearly, the results show that usingCLR, 80% of the connections (i.e., column C) which areleft to be reprovisioned at the physical layer (i.e., columnsC and D) can be successfully reprovisioned under PAC-HCL and this is mainly due to higher resource availability

12 24 36 48 600

0.05

0.1

0.15

0.2

0.25

Load (Erlangs)

Per

cent

age

of V

ulne

rabl

e C

onne

ctio

ns

PAC, before CLRPAC, after CLR

PAL, before LLRPAL, after LLR

Fig. 7. Vulnerable connections.

3910 C. Assi et al. / Computer Communications 29 (2006) 3900–3912

at the physical layer. Whereas, under PAC, over 50% getsblocked and hence they remain unprotected.

Fig. 7 shows the connection vulnerability before andafter reprovisioning. Clearly, the higher is the shareabilityof protection resources, the more would be the vulnerabil-ity of connections after the first failure. The figure showsthat PAL has always higher vulnerability before and afterreprovisioning. We also observe that the vulnerabilityincreases as the load increases which is due to the fact thatthe sharing potential gets higher at higher loads. Similar tobefore, since the granularity of LLR is a lightpath, when avulnerable light-path fails to be reprovisioned, all connec-tions carried by this lightpath remain vulnerable (andhence unprotected). Therefore, PAL shows higher connec-tion vulnerability after LLR reprovisioning. CLR, on theother hand, reduces the vulnerability of connectionsgroomed using either PAC or PAC-HCL due to its finergranularity substantially. We similarly notice that themajority of vulnerable connections are reprovisioned atthe lightpath layer.

Network robustness is another important performancemetric used to compare LLR and CLR. Robustness isdefined as the capability of the network to maintain highrestorability6 of its connections (e.g., 95% or above) whena pair of links randomly fail (one after the other) [10].We measure the robustness before and after reprovisioningand for different add/drop grooming ports per node (8 or16). Our evaluation is based upon measuring the percent-age of links in the network that yields higher dual failurerestorability after the first failure. In other words, therobustness is measured by first taking a link down and thenmeasuring the restorability of the connections when anoth-er link fails from the remaining links. We then measure the

6 The restorability, R(i, j),of a double failure (i, j)is defined as the portionof all working paths wi + wj on links i and j that are simultaneouslyaffected and survive the failures [5,22].

percentage of links that result in a particular restorabilityvalue. This experiment is repeated for all links in the net-work and then we average all the results. Hence, the largerthe fraction of network links that yield higher connectionrestorability, the better is the overall robustness. That is,given equal failure probability on all links, if dual failurerestorability is kept at a desirable level for the majorityof these links, then the network is said to be more robust.Fig. 8 shows a comparison of the network robustnessbefore and after reprovisioning at a load of 24 Erlangs. Itshows 10 different intervals for the restorability rangingfrom 0% to 100%. Namely, one large interval is chosento cover a relatively low restorability range 0–55% andthe remaining intervals are chosen in increments of 5% tocover higher ranges above 55%. The figure showsthe robustness of the network as the probability of havingthe restorability (R) within a certain interval. Forexample as Fig. 8a shows, the 90% restorability ofPAC is defined as Pr(R P 90%) = Pr(R2[95% � 100%]) +Pr(R2[90% � 95%]) = 0.22. After reprovisioning, this val-ue increases to 0.96 (see Fig. 8b).

First, LLR improves the robustness of PAL; beforereprovisioning Pr(R P 90%) = 0.35 (Fig. 8(a)) and afterreprovisioning this value becomes 0.6 (Fig. 8b). This isjustified from Figs. 6 and 7, where we showed that thepercentage of unprotected connections drops from 18%to 6% (at a load of 24 Erlangs) and the percentage of vul-nerable connections drops from 18% to 8% before andafter reprovisioning correspondingly. Alternatively, therobustness (e.g., Pr(R P 90%)) of PAC (PAC-HCL)improves from 22% (48%) before reprovisioning to almost96% using CLR (Fig. 8a and b). This shows a substantialimprovement of CLR over LLR; this is clearly explainedin the previous discussions and from Figs. 6 and 7 whereafter reprovisioning only a very small percentage ofunprotected and vulnerable connections exist in thenetwork. CLR performance is equal for PAC andPAC-HCL (e.g., at higher restorability) due to the smallpercentage of vulnerable and unprotected connectionsremaining in the network.

Another observation is with regards to the impact ofgrooming capacity on the network robustness. We studythe robustness when the grooming capacity is 8 and 16add/drop ports per node. As mentioned earlier, the groom-ing capacity has minor impact on PAL (see Fig. 4) andhence on LLR. This is due to the fact that under PAL pro-tection lightpaths do not consume any add/drop ports.However, the grooming capacity has direct effect on PACand PAC-HCL and hence on CLR. For example, beforereprovisioning when we increase the grooming capacityfrom 8 (Fig. 8a) to 16 (Fig. 8c), the robustness (e.g.,Pr(R P 90%)) changes from 22% and 48% to 43% and51% for PAC and PAC-HCL correspondingly. After repro-visioning, the robustness of PAC and PAC-HCL changesfrom around 96% to almost 100% after reprovisioning(Fig. 8b–d). We find that when the grooming capacityincreases, small gain is achieved by the reprovisioning

95~100 90~95 85~90 80~85 75~80 70~75 65~70 60~65 55~60 0~550

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

Restoration Intervals (%)

Per

cent

age

of N

etw

ork

Link

s

PAC

PAL

a

95~100 90~95 85~90 80~85 75~80 70~75 65~70 60~75 55~60 0~550

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Per

cent

age

of N

etw

ork

Link

s

PAC, CLR

LLR

b

95~100 90~95 85~90 80~85 75~80 70~75 65~70 60~75 55~60 0~550

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

Restorability Intervals (%)

Per

cent

age

of N

etw

ork

Link

s

PAC

PAL

c

95~100 90~95 85~90 80~85 75~80 70~75 65~70 60~65 55~60 0~550

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Restorability Intervals (%)

Restorability Intervals (%)

Per

cent

age

of N

etw

ork

Link

sPAC, CLR

LLR

d

Fig. 8. Network robustness.

C. Assi et al. / Computer Communications 29 (2006) 3900–3912 3911

algorithm (in terms of robustness). Although as shown inFig. 4, the BBP reduces substantially and hence more con-nections are admitted into the network.

5. Conclusion

In this paper, we considered the problem of protectinglow speed connections in optical networks against multiplenear simultaneous failures. These low speed connectionsare groomed together either using PAL or using PAC sur-vivable grooming policies. To improve the survivability ofthese connections, we proposed to use spare capacity rep-rovisioning after the first failure in order to allocate protec-tion resources and protect exposed and vulnerableconnections. We proposed two different reprovisioningschemes, LLR and CLR, and studied their performances.

The two schemes differ in the granularity at which theyreprovision spare resources and which grooming policythey each require. For example, LLR uses PAL and oper-ates at the lightpath level; on the other hand, CLR usesPAC and operates at a finer granularity (connection level).We have shown that CLR substantially outperforms LLRdue to the increased flexibility that it enjoys. In addition,CLR reuses the available capacity at the lightpath levelto protect exposed or vulnerable connections beforerequesting resources from the physical layer. Our resultshave shown that 80% of the unprotected/vulnerable con-nections are accommodated at the lightpath layer. LLRon the other hand only reprovisions at the physical layeralthough resources may be available in the existing light-paths. We have measured the robustness of the networkagainst dual failures and have shown that a network

3912 C. Assi et al. / Computer Communications 29 (2006) 3900–3912

deploying CLR with PAC as a grooming policy achieves avery high robustness by comparison to LLR under PAL.

Since, CLR deals with a larger number of connections,the management overhead may be excessive as opposedto the smaller number of lightpaths that LLR deals with.Hence, we intend in the future to assess the overheadresulting from CLR and how this could impact the robust-ness of the network when CLR is implemented in a distrib-uted environment.

References

[1] W. Grover, Mesh-Based Survivable Networks: Options and Strategiesfor Optical, MPLS, SONET and ATM Networking, Prentice Hall,Englewood Cliffs, NJ, 2003.

[2] J. Labourdette, Shared Mesh Restoration in Optical Networks, Proc.OFC’04, February 2004.

[3] S. Ramamurthy, B. Mukherjee, Survivable WDM mesh networks,Part II – Restoration, IEEE ICC 1999.

[4] H. Choi, S. Subramaniam, H. Choi, On double-link failure recoveryin WDM optical networks, IEEE INFOCOM, 2002.

[5] M. Clouqueur, W.D. Grover, Availability analysis of span-restorablemesh networks, IEEE JSAC 20 (4) (2002) 810–821.

[6] W. He, A. Somani, Path-based protection for surviving double-linkfailures in mesh-restorable optical networks, Proc. IEEE Globecom2003 (2003).

[7] S. Kim, S. Lumetta, Evaluation of Protection Reconfiguration forMultiple Failures in WDM Mesh Networks, Proc. OFC03, March2003.

[8] R. Ramamurthy, A. Akyamac, J.-F. Labourdette, S. Chaudhuri, Pre-Emptive Reprovisioning in Mesh Optical Networks, Proc. OFC03,March 2003.

[9] J. Zhang, K. Zhu, B. Mukherjee, A Comprehensive Study onBackup Reprovisioning to Remedy the Effect of Multiple-LinkFailures in WDM Mesh Networks, ICC04, Paris, June 20–24,2004.

[10] C. Assi, W. Huo, A. Shami, N. Ghani, Analysis of capacityreprovisioning in optical mesh networks, IEEE Comm. Lett. 9 (7)(2005) 658–660.

[11] D. Schupke, R. Prinz, Performance of Path Protection and Reroutingfor WDM Networks Subject to Dual Failures, Proc. OFC03, March2003.

[12] D.A. Schupke, W.D. Grover, M. Clouqueur, Strategies for EnhancedDual Failure Restorability with Static or Reconfigurable p-CycleNetworks, ICC’04, Paris, June 20–24, 2004.

[13] K. Zhu, B. Mukherjee, Traffic grooming in an optical WDM meshnetwork, IEEE JSAC 20 (2002) 122133.

[14] E. Modiano, P.J. Lin, Traffic grooming in WDM networks, IEEECommun. Mag. 39 (2001) 124129.

[15] B. Mukherjee, C. Ou, H. Zhu, K. Zhu, N. Singhal, S. Yao, Trafficgrooming for mesh optical networks, OFC 2004, 2004.

[16] Hongyue Zhu, Hui Zang, Keyao Zhu, Biswanath Mukherjee, A.Novel, Generic graph model for traffic grooming in heterogeneousWDM mesh networks, IEEE/ACM Trans. Networking 11 (2) (2003)285–299.

[17] O. Gerstel, R. Ramaswami, G.H. Sasaki, Cost-effective trafficgrooming in WDM rings, IEEE/ACM Trans. Networking 8 (2000)618630.

[18] X. Zhang, C. Qiao, An effective and comprehensive approach fortraffic grooming and wavelength assignment in SONET/WDM rings,IEEE/ACM Trans. Networking 8 (2000) 608617.

[19] Canhui Ou, Keyao Zhu, Hui Zang, Laxman H. Sahasrabuddhe,Biswanath Mukherjee, Traffic grooming for survivable WDMnetworks – shared protection, IEEE JSAC 21 (9) (2003) 1367–1383.

[20] Wang Yao, Byrav Ramamurthy, Survivable Traffic Grooming inWDM Mesh Networks Under SRLG Constraints, ICC05, Seoul,Korea, 2005.

[21] D. Xu, C. Qiao, Y. Xiong, An Ultra-fast Shared Path ProtectionScheme – Distributed Partial Information Management, Part II,ICNP’02, Paris, 2002, pp. 344–353.

[22] M. Clouqueur, W.D. Grover, Mesh-Restorable Networks withComplete Dual Failure Restorability and with Selectively EnhancedDual-Failure Restorability Properties, SPIE OPTICOMM, Boston,MA, 2002.

Chadi M. Assi received the B.S. degree in engi-neering from the Lebanese University, Beirut,Lebanon, in 1997 and the Ph.D. degree from theGraduate Center, City University of New York,New York, in April 2003. He was a VisitingResearcher at Nokia Research Center, Boston,MA, from September 2002 to August 2003,working on quality-of-service in optical accessnetworks. He joined the Concordia Institute forInformation Systems Engineering (CIISE), Con-cordia University, Montreal, QC, Canada, in

August 2003 as an Assistant Professor. Dr. Assi received the Mina ReesDissertation Award from the City University of New York in August 2002

for his research on wavelength-division-multiplexing optical networks. Hiscurrent research interests are in the areas of provisioning and restorationof optical networks, wireless and ad hoc networks, and security.

Wei Huo received his Bachelor and Masterdegrees of Computer Science from Xi0an Jiao-tong University, Xi’an (China) in 1997 and 2000respectively. He also finished his Master’s in theDepartment of Electrical and Computer Engi-neering in 2005 from Concordia University,Montreal, Canada. From year 2000 to 2003, hewas a software engineer at Lucent Technologiesin Shanghai, China. Currently, he is working as aSoftware Quality Assurance engineer inMontreal.

Abdallah Shami received the B.E. degree in elec-trical and computer engineering from the Leba-nese University, Beirut, Lebanon, in 1997, andthe Ph.D. degree in electrical engineering fromthe Graduate School and University Center, CityUniversity of New York, New York, in Septem-ber 2002. In September 2002, he joined theDepartment of Electrical Engineering at Lake-head University, ON, Canada, as an AssistantProfessor. Since July 2004, he has been with theUniversity of Western Ontario, London, ON,

Canada, where he is currently an Assistant Professor in the Department ofElectrical and Computer Engineering. His current research interests are in

the area of wireless/optical networking, EPON, WIMAX, and WLANs.Dr. Shami held the Irving Hochberg Dissertation Fellowship Award at theCity University of New York and a GTF Teaching Fellowship.