DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0035] In this patent document, a mesh telecommunications network (also often called a “transport” network or “optical network”) is a telecommunications network formed from plural nodes connected by plural spans. In this patent document, the word “comprising” is used in its non-limiting sense to mean that items following the word in the sentence are included and that items not specifically mentioned are not excluded. The use of the indefinite article “a” in the claims before an element means that one of the elements is specified, but does not specifically exclude others of the elements being present, unless the context clearly requires that there be one and only one of the elements.

[0036] FIG. 1 ( a ) shows a conventional span-protecting p-cycle according to the prior art, with nodes numbered 0, 1, 2, . . . , 10, in which the connecting spans of the network T are referred to as (i, k), where i is the beginning node and k is the terminating node, and paths are referred to as (i, j, k), where i is the beginning node, j is the intermediate section and may refer to more than one node, and k is the terminating node. Paths may also be referred to in abbreviated form by (i-k). The spans ( 0 , 2 ), ( 2 , 3 ), ( 3 , 5 ), ( 5 , 6 ), ( 6 , 8 ), and ( 8 , 0 ) are on-cycle spans of the p-cycle R shown. The span ( 0 , 5 ) is not on the cycle, but its two end nodes are, making it a straddling span. A p-cycle can offer one protection path for the failure of any on-cycle span and two protection paths for the failure of any (of possibly several) disjoint straddling spans (one failure at a time). For example, if span ( 5 , 6 ) fails, the route ( 5 , 3 , 2 , 0 , 8 , 6 ) on cycle R offers one protection path to restore the failed span, in exactly the way a BLSR operates. But if span ( 0 , 5 ) fails, paths ( 0 , 2 , 3 , 5 ) and ( 0 , 8 , 6 , 5 ) are both (simultaneously) available to provide protection paths. In either type of failure only two nodes do any switching in real time, and it is effectively identical to a preplanned BLSR switching reaction. In contrast a ring (or any form of cycle cover) only protects on-cycle spans. An example of protection against node failure can also be seen in this example. A failure of intermediate node 7 can break the flows between node pairs ( 1 , 10 ) and ( 4 , 9 ). While a span-protecting p-cycle cannot restore these affected transit flows, under the flow p-cycle in FIG. 1 ( b ), the flows that transit node 7 can be recovered by the cycle. Note, however that any demands being added or dropped at node 7 cannot be handled by the same flow p-cycle. The flow must be unchanged in its composition between the nodes where it intersects the flow p-cycle.

[0037] As is known in the art, it is the admission of straddling span protection relationships that dramatically reduces the total design redundancy relative to ring-based networks, to the point of near-equivalence with a span-restorable mesh network. Note, however, in FIG. 1 ( a ) that spans ( 6 , 7 ) and ( 7 , 2 ), and several others, of the basic p-cycle are close to being straddling spans but cannot actually be span-protected by the cycle shown. However, a path segment that crosses both spans ( 6 , 7 ) and ( 7 , 2 ), as shown in FIG. 1 ( b ), can be considered in isolation (when taking a path-level view) to straddle the cycle as if it was on its own virtual direct span that is a chord to the p-cycle. More specifically the path segment ( 6 , 7 , 2 ) can be considered to straddle cycle R, between the nodes 6 and 7 , and is labeled as a straddling flow, as well as the path segment ( 6 , 7 , 0 ). This simple observation is the starting point for the fully general concept. To develop this we must now take an explicit view of the service paths S 1 , S 2 , and S 3 crossing the network and how they relate to the p-cycles we may use for protection. FIG. 1 ( b ), which has flows along paths ( 9 , 6 , 7 , 2 , 4 ) labeled S 1 , ( 10 , 6 , 7 , 0 , 1 ) labeled S 2 , and ( 9 , 6 , 5 , 3 , 4 ) labeled S 3 , shows this more highly resolved viewpoint in which we can design a flow p-cycle protected network. For convenience let us define a flow as any single contiguous segment of a working end-to-end path. Thus, the entire path, each span on the path, and any sequence of several spans along the path are flow segments that could be protected by flow-protecting p-cycles. Note that this can refer to a segment of a lightpath, an OC-n path, or an MPLS path. Contiguous means that the multiplexed demand composition of the respective lightpath, OC-n, or MPLS path is not altered by add/drop of constituent lower-rate payloads at any node of the segment. This situation is commonly referred to by saying that with respect to any intermediate nodes in the segment, the flow is an express flow.

[0038] Clearly flow p-cycle designs can access more opportunities for spare-capacity-sharing than the span p-cycle method. Any flow segment that intersects a flow p-cycle can be protected, not simply spans directly on or straddling the cycle. For example, if spans ( 2 , 7 ) and ( 6 , 7 ) in FIG. 1 ( a ) incur failures, they cannot be restored by the span-protecting p-cycle Rs. But, under the flow p-cycle shown in FIG. 1 ( b ), the contiguous flows that traverse spans ( 2 , 7 ) and ( 6 , 7 ) can be restored by the cycle Rf. Note, however that any demands being added or dropped at node 7 cannot be handled by the same flow p-cycle. The flow must be unchanged in its composition, or contiguous, between the nodes where it intersects the flow p-cycle. A similar situation is encountered if node 7 were to fail, where the span protecting p-cycle Rs cannot restore flows, while the flow protecting p-cycle can, except for demands being added or dropped at node 7 . In this disclosure, it will be understood that a segment that is protected implies that the segment is protected against failure of any of its spans or nodes. Similarly, any reference to a span failure within a segment can equally be considered a node failure within the segment, unless, it is obvious from the context that the failure must be a span.

[0039] Flow p-cycles can be categorized as the p-cycle equivalent to path restoration with failure-specific stub-reuse. This is an intermediate between completely general stub release and the complete prohibition against re-use of stub capacity that is built into the recent shared backup path protection scheme. In stub re-use the surviving path up to the protected segment is always part of the end to end path in the restored state. In other words the surviving stub path segments are always re-used in a failure specific way by the same path that used that capacity before the failure. Unlike stub release, which can permit the same or any other simultaneously failed path to exploit released stub capacity of failed paths, the stub re-use that is implicit in flow p-cycles requires no explicit real time actions to effect it.

[0040] Determining Flow-Protection Relationships

[0041] Given a cycle that is a candidate to be a flow p-cycle in a network design, the relation of any given path to the cycle can be either intersecting or non-intersecting. Only intersecting paths are relevant to the consideration of each candidate cycle. A path intersects a cycle if the two have at least two common nodes (which may include the source and destination nodes of the path). These are called intersection nodes. For example, the paths between nodes ( 4 , 9 ) and ( 1 , 10 ) in FIG. 1 ( b ) both intersect the cycle shown and are relevant to the consideration of that cycle as a possible flow p-cycle. By inspection, that cycle would provide straddling-type protection to the two segments ( 6 , 7 , 2 ) and ( 0 , 7 , 6 ) and on-cycle protection to an example flow such as ( 6 , 5 , 3 ) should it exist. More generally, a path can intersect a cycle in a variety of more complex ways, involving more than two intersecting nodes.

[0042] FIGS. 2 ( a )-( e ) depicts a variety of flow relationships, where s represents the start node, and d represents the end node, and in which numbers 1-20 represent nodes on or in the p-cycle. FIG. 2 ( a ) displays the simplest scenario, where the cycle and the relevant flow segment intersect at two nodes 1 and 2 , and the flow through nodes 3 and 4 does not share any other spans or nodes with the cycle. Analogous to the concept of a straddling span in conventional p-cycles, it is natural to call this a straddling flow relationship. Similarly, FIG. 2 ( b ) depicts a flow segment ( 1 , 5 , 6 , 2 ) in an on-cycle relationship, which is called an on-cycle flow. From here, more complex relationships of flows to cycles need to be recognized that do not arise with span-protecting p-cycles. FIG. 2 ( c ) shows a three-node intersection relationship of what is otherwise a plain straddling flow labeled ( 1 , 7 , 8 , 2 ). FIG. 2 ( d ) shows an even more general intersecting flow relationship that produces two straddling portions ( 1 , 9 , 10 ) and ( 11 , 2 ) and an on-cycle segment ( 10 , 11 ). Conceptually the flow-to-cycle intersection relationship can be arbitrarily complex, such as in FIG. 2 ( e ) where it passes through nodes ( 1 , 12 , 13 , 14 , 15 , 16 , 17 , 18 , 19 , 20 , 2 ). But the following important observation can be made about any of these intersection relationships, no matter how apparently complex: With respect to a cycle j, and any span failure i on the intersecting flow segment, it is always possible to determine by simple inspection whether a unit copy of protection capacity on cycle j can provide either one or two protection paths for the affected flow. For example, in FIGS. 2 ( b ) and 2 ( a ) there are respectively one and two protection paths available from the cycle for any span failure on the corresponding intersecting flow segments. FIG. 2 ( c ) is in this regard equivalent to FIG. 2 ( a ). In FIG. 2 ( d ) two paths are available if the failure span is in either of the straddling segments, but only one if a span fails in the on-cycle segment. Thus, a preprocessing program can identify all the protection relationships between candidate cycles and the corresponding flow segments that it could protect. More formally this defines the topological parameters γ _i,j ^r ε( 0 , 1 , 2 ), which give the number of protection relationship that a unit capacity on cycle j can (potentially) provide to the intersecting flow segment of the working path for end-node pair r, in the event of span failure i. It is zero if span i is not contained in a flow that intersects cycle j. It is one if span i is in an intersecting flow and is also a span of cycle j itself (i.e., an on-cycle relationship), and two otherwise (i.e., a straddling relationship). For a node, the notation would replace i with n such that γ _i,j ^r ε( 0 , 1 , 2 ).

[0043] Mutual Capacity Considerations

[0044] Now comes the most complicating aspect of the concept of path-oriented p-cycles. The reason we said “potentially provide” above is that, as can be noted in FIG. 1 ( b ), the ability of the cycle to provide the assessed number of protection paths can depend on which other path failures occur at the same time. Unlike span-protecting p-cycles, when a span fails in the flow-oriented context, path segments with more than one set of end nodes are affected simultaneously. Because the affected paths (more specifically here, the affected path segments) all have different intersecting nodes on the flow p-cycle, we get into the problem of “mutual capacity.” This is the fundamentally complicating aspect of efficient multi node-pair re-routing problems. Here we can see the issue manifest itself in FIG. 1 ( b ). If span ( 7 , 2 ) fails, then only the flow segment for path ( 4 - 9 ) needs protection and it can obtain two protection paths from the cycle shown. But if span ( 6 , 7 ) fails, then access to the same flow p-cycle must be coordinated between the segments for paths ( 9 - 4 ) and ( 10 - 1 ), which fail simultaneously. This failure-specific way in which a given p-cycle can be used in different ways requires a new family of intermediate variables, which is not needed in the design of networks using basic span p-cycles. These are the variables n _i,j ^r which denote number of unit-capacity copies of cycle j required to specifically restore the working flow for node pair r upon span failure i.

[0045] Flow-Protecting Design Model

[0046] We can now put together an integer linear programming (ILP) model for design of flow-protecting p-cycle networks. Because we are presently only introducing the concept we will consider the “non-joint” design case where working demands are first routed via their shortest paths, followed by optimization of the spare capacity for flow p-cycle placement. Similarly, the present model assumes “oeo” OXC nodes, or transparent optical cross-connects with a suitable pool of wavelength converters, so that regeneration and/or wavelength conversion needs can be assumed to be met as required at any node. The cost of this is assumed to be reflected in c _k below. (The significance of these considerations is that the design model does not need to be burdened with simultaneously solving for explicit wavelength assignments and need consider only capacity-related costs). The parameters of the model are as follows. S is the set of spans in the network. Index i denotes spans specifically in a failure context, and k is used to index S in other general contexts. D _i is the set of end-node pairs of paths affected by failure of span i, index r. P is set of all simple cycles of the graph that are candidates to become p-cycles, indexed by j. In practice P may be a limited set of candidate cycles that are eligible for use by virtue of limited circumference, hop count, or other engineering considerations. When needed to reduce computational difficulty, P may also be limited to containing only elite or highly promising candidate cycles. c _k is the cost of adding a unit capacity (for instance an additional lightwave channel) to span k. c _k values are pre-computed constants which may include considerations such as the type of facility involved, distance-related costs for using amplifiers, the cost of any o/e interfaces at the span terminating OXCs, and an amortized allocation of the OXC core costs and wavelength converter pool cost. d ^r is the number of demand units (for instance, lightpath requirements) on node pair r. As discussed above γ _i,j ^r ε( 0 , 1 , 2 ) encodes the basic topological relationships between each span failure i with respect to the protection relationship cycle j provides for paths on demand pair r. Finally δ _j,k =1 if cycle j includes span k, otherwise, 0.

[0047] The variables to be solved for are as follows: n _j is the number of unit-capacity copies of cycle j to build, s _k is the number of spare capacity units required on span k to support the set of flow p-cycles used and, as explained, n _i,j ^r is a family of intermediate variables that consider the number of copies of cycle j that are needed specifically for protection of path r against failure i. All variables are non-negative integers, although it can be seen from the problem structure that spare capacity can be relaxed without loss of integrality. The model is:

[0048] Flow P-Cycles: 1 $\begin{array}{cc}\mathrm{Minimize}\sum _{k\in S}^{}c_ks_k& \left(1\right)\end{array}$

[0049] Subject To: 2 $\begin{array}{cc}\sum _{j\in P}^{}{\gamma }_{i,j}^r·n_{i,j}^r\ge d^r\forall i\in S;\forall r\in D_i& \left(2\right)\\ n_j\ge \sum _{r\in D_i}^{}n_{i,j}^r\forall i\in S;\forall j\in P& \left(3\right)\\ s_k\ge \sum _{j\in P}^{}n_j·{\delta }_{j,k}\forall k\in S& \left(4\right)\end{array}$

[0050] The first constraint system asserts that affected working flows must be fully restored. The second says that the number of copies of cycle j to build is set by the largest failure-specific simultaneous use of unit copies of cycle j. This is like setting the spare capacity of a conventional span or path restorable mesh network to satisfy the largest simultaneously imposed set of restoration flows over the set of all non-simultaneous failure scenarios. The final constraint system says that the spare capacity on span k must be enough to support the number of copies of each p-cycle that overlies the span.

[0051] An important simplifying aspect to note about this model (relative to prior attempts at strictly path protecting p-cycles) is that it avoids explicit enumeration of the specific paths or path segments to be protected. Rather, the decisions about which protected path segments are defined come out implicitly from the choice of p-cycles that the solution employs. But since every span failure scenario is considered in the model, all spans (and hence all paths) wind up being implicitly protected end to end, but over one or more protected flow segments on each end-to-end path. This is the key sense in which the more general nature of the flow p-cycle paradigm overcomes the previous problems we mentioned in attempts to directly formulate end-to-end p-cycle path protection.

[0052] As an example, we present four test networks that have been used to obtain samples of flow p-cycle-based networks for analysis and evaluation. FIG. 3 ( a ) is a network referred to as NSFNET, and has N=14, S=22, and |P|=139. FIG. 3 ( b ) is a network referred to as ARPA2, and has N=21, S=25, and |P|=18. FIG. 3 ( c ) is a network referred to as SmallNet, and has N=10, S=22, and |P|=833. FIG. 3 ( d ) is a network referred to as Bellcore, and has N=15, S=28, and |P|=976, where N is its number of nodes, S its number of spans and |P| is the complete number of distinct simple cycles on the graph. Each network has span distances assigned in proportion to the Euclidean distances of the span in the networks as drawn above. Except for Bellcore, demands were generated for all node pairs from a uniform random distribution on [1 . . . 20] and the design problems were solved to optimality in under 2 hours with AMPL/CPLEX 7.1 on an Ultrasparc Sun Server at 450 MHz with 4 GB of RAM. The same demand generating procedure was used to create the Bellcore test case but only 50% of node pairs exchange non-zero demand quantities. The Bellcore solution required about a day and was solved to within 1.34% gap to optimality. The run times, however, can be improved by applying pre-selection strategies or other heuristics in general if warranted.

[0053] For comparative reference on each test network, optimal span-protection (SP) p-cycle designs, span-restorable (SR) mesh network designs as well as path-restoration designs with and without stub release were also produced for comparison. Notably the SP p-cycle reference designs here were actually produced with the flow p-cycles model by simply defining and equivalent demand matrix having non-zero values only between directly connected node pairs. The span- and path-restorable mesh reference designs were produced by known methods. The reference problems all solved in seconds or minutes at most.

[0054] Table 1 summarizes aspects of the results. For each test network, column 1 describes the span-protecting (SP) p-cycle designs, column 2 details the SR mesh designs and column 3 is for the flow p-cycle designs. Columns 4 and 5 are results for path restorable designs (PR) without, and with, stub release, respectively. (The sequence reflects the theoretically expected ranking in terms of increasing efficiency). All designs for each network have the identical working capacity and demand routing. The first row records the total spare capacity relative to the SP p-cycle design needed for 100% restorability against all single span failures. The next row shows the total design capacity cost relative to the SP p-cycle design. The third row shows the corresponding redundancy ratio of the overall network designs. This is followed by indication of the 1/(d−1) lower bound for SR mesh, for interpretive reference. The next row records, for the p-cycle designs, the number of distinct cycles on which p-cycles were formed. Below this is a characteristic measure for each scheme of the average number of reconfiguration actions involved for each span failure. For SR and PR mesh designs it is the average number of restoration paths per failure. For SP p-cycles, it is the average number of p-cycles switching per failure, and for flow p-cycles it is the average number of flow segments deviated onto p-cycles to protect against each span failure.

[0055] Interpretation of Results and Significance

[0056] The results show that the flow p-cycle method can yield significant reductions in spare capacity requirement relative to the SP p-cycle architectures, ranging from 12 to 25% on the first three networks. The performance differences over the test networks are related to the different network average nodal degrees, d. 1/(d−1) is a practical lower bound on redundancy for any span restoration scheme, and hence also for SP p-cycles, but notably here, we see the flow p-cycle designs edging very close or even below that bound, justifying their classification as a kind of path-restoration scheme.

[0057] Other diagnostic results indicate that a design based solely on flow p-cycles may have more distinct p-cycle structures than in SP p-cycle designs, although the differences are not more than twice and one test case (ARPA2) required only eight flow p-cycles whereas nine SP p-cycles were otherwise required.

[0058] Operational Aspects

[0059] Here we explain at least one scheme by which the flow p-cycle protection is put into effect in real time in reaction to a span failure, and shown pictorially in FIG. 4 . We assume that p-cycles would be formed and sustained by OXC nodes under central control to connect the required spare wavelength channels together to create the desired set of p-cycles. At the time a p-cycle j is established through a node x, a list of the corresponding protected flow segments that intersect the cycle at that node is recorded in association with the p-cycle. The Signal_ID of the working path of which the p-cycle protects a segment is also recorded at the node for each span (as a possible failure) on the flow segment. In effect this data sets up matching conditions for node x to know locally which working signals (if any) it should switch into p-cycle j, depending on which span fails on any of the flow segments passing through it.

[0060] Upon failure, node x is either adjacent to the failure, in which case it sees LoS (loss of signal), or AIS (alarm indication signal) inserted downstream by the two nodes adjacent to the failure. All working signals bear a unique Signal_ID in their overheads and any time a node inserts AIS, it appends the ID of the incident span that has failed. Thus, at propagation speeds, the failure indication data {AIS, Signal_ID=Z, Span_ID=k} passes through all nodes on the failed path. But only node x will have been “pre-wired” with the matching conditions to associate Signal_ID=Z with locally accessible p-cycle j if an indication of its failure arrives, arising from span k. Thus a logical matching rule can be applied at any node seeing an AIS indication to quickly determine if it has a custodial responsibility to do protection switching for the failed signal. At node y, the Signal_ID is again matched, and the signal is switched off the p-cycle.

[0061] Simplified Applications of the General Concept

[0062] While it is a useful advance to understand the fully general model of flow-protecting p-cycles, the complexity may be judged higher than desired from a near-term operational standpoint. But an appreciation of the concept actually suggests some simpler specific adaptations of flow p-cycles that may be more practically manageable and useful. One of these is to only consider the use of flow p-cycles only for the important express flows through a network region. Conceptually one can picture an overall network design comprised in part of a set of simple fast-acting “local” span-protecting p-cycles. Logically overlaid on this is a select set of “express flow” protecting flow p-cycles. A particular economic advantage of this selective use of a few flow p-cycles is that the express flows they protect may take advantage of long-reach optical technology for optical bypass of all intermediate nodes on the protected flow segment. This allows the express flow signals to remain in the optical domain through the entire region, but remaining protected, saving considerably over the alternative of terminating on each OXC en route.

[0063] Closely related to this idea is the even more specific proposal of an area-boundary flow-protecting p-cycle. This is in the context of multi-domain optical networking. The idea is that within a domain, any local protection schemes could be used, but flows traveling entirely through the domain are protected by a domain perimeter flow p-cycle. The primary advantages of this would again be optical bypass savings and the simplicity of separating all transit flow considerations from the protection of intra-domain flows. The concept is summarized in FIG. 5 , where closed loop E represents the flow-protecting p-cycle, or a regional flow protecting p-cycle and L represents the span-protecting p-cycles or local span protecting p-cycles for the network N consisting of OXC nodes. In a long-haul network the “diameter” of the express flow-protecting p-cycles may match the transparent optical reach limit of the path segments involved so wavelength conversion and regeneration can be provided at the flow p-cycle nodes only, with all-optical transmission on the protected path segments.

[0064] Pre-Selection and Joint Optimization Considerations

[0065] The design of the flow-protecting p-cycles can be improved by using a pre-selection strategy, which also makes solving the joint optimization problem feasible.

[0066] The aspect of jointness in a p-cycle design problem will now be discussed. The issue is that one can either first route the working demands via shortest paths (or any other means) and then solve a corresponding minimum spare capacity allocation problem (the non-joint problem), or, attempt to optimize the choice of working routes in conjunction with the placement of spare capacity together (i.e., jointly) to minimize total capacity (the joint problem). An example of the effect of solving the joint problem is shown in FIGS. 6 ( a ) and ( b ). Network 60 is shown with flow 62 representing 2 units of capacity 2λ, and p-cycle 64 consisting of spans 101 - 106 . In FIG. 6 ( a ), flow 62 passes through spans 101 and 102 , while in FIG. 6 ( b ), flow 66 passes through spans 107 and 108 . In FIG. 6 ( a ), p-cycle 64 requires 2 units of spare capacity on spans 101 - 106 , while FIG. 6 ( b ) reduces the units of space capacity required for p-cycle 64 to one unit on spans 101 - 106 by increasing the length of the path of the working flow from 2 to 2+ε. Together these figures show how potentially advantageous it can be in terms of total capacity reduction, if the right choices of working path routing can be made, in conjunction with p-cycle placement choices, so as to realize the kind of savings evident in the example of FIGS. 6 ( a ) and ( b ).

[0067] A flow chart showing an example of how the non-joint problem is solved is shown in FIG. 7 ( a ), where the first step in 202 is to route all lightpath requirements via the shortest path. Step 204 follows from this in defining all working paths and working capacities. To solve for the required p-cycles and spare capacity in 212 , one can either enumerate all graph cycles as possible p-cycles in 206 and then use an ILP solution for p-cycle formation in 208 , or one can use another heuristic algorithm(s) for p-cycle formation in 210 . This process can be contrasted with the flow chart in FIG. 7 ( b ), where the first steps 220 and 222 are to enumerate eligible working routes and enumerate graph cycles as potential p-cycles, respectively. These two sets are combined and solved in a single ILP solution in 224 , from which the p-cycles and spare capacity are defined in 226 , and the working routes and capacity are defined in 228 .

[0068] To reduce the complexity of solving optimal p-cycle design problems, a scoring credit can be used, which considers not only topology information, but also the traffic demands of the flows that are potentially protected by the cycle. The definition is given as follows: 3 $\begin{array}{cc}\frac{\sum _{r\in D,i\in S^r}^{}l_r·g_r·{\gamma }_{i,j}^r}{\sum _{k\in P\left(j\right)}^{}c_k}=\mathrm{credit}\mathrm{of}\mathrm{cycle}j\in P& \left(5\right)\end{array}$

[0069] where D is set of nonzero demand pairs (i.e., flows) on the traffic matrix, indexed by r. S ^r is set of spans traversed by the working path between demand pair r. Here we assume there is only a single shortest working path existing between each demand pair. P(j) denotes cycle j in cycle set P. k enumerates spans on cycle P(j) and c _k represents the unit cost of span k. As an example, the Euclidean distance of spans between the nodes they connect can be used to represent the span cost, c _k . γ _i,j ^r is as already defined, now applied to flows rather than spans, and g _r denotes number of traffic demand units of the working flow between demand pair r. l _r is the length of the working flow of demand pair r. Note that the purpose of weighting the above two terms is to assign a larger scoring credit to a cycle that can potentially protect “thicker” and “longer” flows (i.e., the larger the product of g _r and l _r is the more important the corresponding flow is to overall design efficiency.)

[0070] Other methods of ranking the candidate cycles may also be used, such as methods that focus strictly on topology of the network and do not consider traffic flows. For example, by removing g _r and l _r from equation 5, we leave γ _i,j ^r as the only term being summed in the numerator, and obtain a topological score that can rank the cycles. The equation then becomes: 4 $\begin{array}{cc}\frac{\sum _{r\in D,i\in S^r}^{}{\gamma }_{i,j}^r}{\sum _{k\in P\left(j\right)}^{}c_k}=\mathrm{credit}\mathrm{of}\mathrm{cycle}j\in P& \left(6\right)\end{array}$

[0071] The preceding example is to show that other combinations of variables that describe a network may be combined by those skilled in the art to obtain a ranked list of cycles in a network. The equation may be modified according to the situation that the invention is to be applied, where some factors may have more of an effect on the overall cost or efficiency.

[0072] The set of cycles are ranked according to their score, and highest ranked cycles can be pre-selected as candidate cycles for the rest of the problem. While the pre-selection criteria is effective in predicting the success of a particular cycle, it is possible have “too elite” a population of candidate cycles and it may be desirable to dilute the population with a few other types of candidates. The basic framework is one within which many specific heuristic ideas can be tried, all having to do with defining the reduced set of elite cycles to consider. First, some experience with memory and run times may show, for example, that a budget of 10,000 cycles is realistic to work with. The budget can be used up representing any number of mixed strategies for populating the elite P set.

[0073] An example could be:

[0074] Admit the 5,000 cycles found by the score-based selection above.

[0075] Add the 2,000 cycles with most absolute number of straddling path segments.

[0076] Add the 2,000 of the longest cycles.

[0077] Add 1,000 random cycles.

[0078] By itself the first set of cycles may not necessarily ensure feasibility. When choosing only individually elite cycles, there is no strict guarantee that a cycle will be represented that would cover, for example, a very long degree-2 chain connected to an otherwise highly connected mesh. However, cycles in batch three above definitely cover that eventuality.

[0079] Once the set of candidate cycles of the network graph have been characterized in this way, the problem can be solved using, for example, an integer linear programming (ILP) formulation, where the objective function minimizes the total cost of spare capacity and (for the joint problem) working capacity. ILP formulations are well known in the art and need not be further described here. This function is subject to:

[0080] A. All lightpath requirements are routed.

[0081] B. Enough WDM channels (or working channels in general) are provided to accommodate the routing of lightpaths in A.

[0082] C. The selected set of p-cycles give 100% span protection.

[0083] D. Enough spare channels are provided to create the p-cycles needed in C.

[0084] E. Integer p-cycles decision variables and integer capacity.

[0085] Applying the pre-selection criteria can be particularly useful in the joint optimization problem, where the formulation generates large problem files that can be difficult to solve optimally if there is no pre-selection.

[0086] Two points concerning the impact and relevance of the invention can be noted. Firstly, we note that, in general, the joint p-cycle design is as efficient as previously studied dynamic path-restorable designs in other studies to date. Such high efficiency is a direct benefit in terms of reduced cost or greater revenue from the same facilities, but an efficient network is also inherently a more flexible network because less of its resources are tied up for protection. Secondly, the simple process of pre-selecting candidate p-cycles greatly reduces p-cycle solution times so much that it may be practical to continually re-compute the optimal p-cycle configuration on-line as the network demand pattern evolves. This helps greatly to remove some prior objections to the practicality of p-cycle based networks and enables the vision of a continually adapting background layer of p-cycles.

[0087] Immaterial modifications may be made to the embodiments described in this disclosure without departing from the invention. 1