CA2161847A1 - Method for preconfiguring a network to withstand anticipated failures - Google Patents
Method for preconfiguring a network to withstand anticipated failuresInfo
- Publication number
- CA2161847A1 CA2161847A1 CA002161847A CA2161847A CA2161847A1 CA 2161847 A1 CA2161847 A1 CA 2161847A1 CA 002161847 A CA002161847 A CA 002161847A CA 2161847 A CA2161847 A CA 2161847A CA 2161847 A1 CA2161847 A1 CA 2161847A1
- Authority
- CA
- Canada
- Prior art keywords
- span
- flow
- network
- restoration
- amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/14—Monitoring arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
Abstract
A method for restoring traffic in a network. The network includes plural distinct nodes interconnected by plural distinct spans, each span having working links and spare links. Each node has a digital cross-connect switch for making and breaking connections between adjacent spans forming span pairs at a node. Step 1: For each of at least two possible span failures, (a) find the number of restoration routes available in case of the occurrence of each span failure, (b) determine the resources used by each restoration route, and (c) determine the amount of flow to be restored for each span failure. Step 2: find, in a computer, the amount of flow fP to be restored along each restoration route that minimizes total unrestored flow for all possible span failures identified in step 1. Step 3: form connections at each digital cross-connect switch in the network along each restoration route before occurrence of one of the possible span failures identified in step 1 to permit the amount of flow fP determined in step 2 to be carried by each respective restoration route upon the occurrence of one of the possible span failures identified in step 1.
Description
~1 61847 TITLE OF THE INVENTION:
Method for Preconfiguring a Network to Withstand Anticipated Failures NAME(S) OF INVENTOR(S):
Wayne D. Grover, Michael H. MacGregor FIELD OF THE INVENTION
This invention relates to methods for restoring networks of spans, for example telecommunications networks, upon the occurrence of a failure of one of the spans of the network.
R~GROUND OF THE INVENTION
Methods for the restoration of digital transport networks have been studied for several years. Some researchers have concluded that distributed real-time protocols may operate too slowly to meet operational objectives, such as the 2 second call-dropping threshold in voice networks. This problem can be overcome by preparing the network for anticipated failures by optimally preconfiguring resources which will be used to react to the failure. This places the network into a state of "best readiness" to face a given set of anticipated failures.
See W.D. Grover and M.H. MacGregor, "Potential for spare capacity preconnection to reduce crossconnection workloads in mesh-restorable networks", Electronics Letters, Vol. 30, No. 3, pp. 194-195, February 3, 1994, and M. Herzberg and S.J. Bye, "An optimal spare-capacity assignment model for survivable networks with hop limits", Proceedings of IEEE
Globecom ~94, Vol. 3, pp. 1601-1606, IEEE, 1994.
The tremendous interest in real-time network restoration over the last few years is evidence both of the ~ 21 61847 importance and difficulty of this problem. Evidence has been mounting that it may not always be possible to meet operational requirements with real-time techniques. The suggested cures have ranged from high speed, parallel computing architectures for digital crossconnect machines to simplified network architectures where restoration can be made to occur more quickly in real-time. The proposal of Grover and MacGregor suggests anticipating failures, and preconfiguring the network to handle them so that real-time computation or reaction delay (one or both) is not required except at the endpoints of the failure. Thus, preconfiguration methods apply where computing a reaction or implementing it (or both) is/are too lengthy a process.
Various heuristic methods can be proposed to solve the problem of preconfiguring a network, given the anticipated failures and the resources available for reacting to them. However, it is not obvious how to achieve an optimal state of preconfiguration, largely because of the combinatorial complexity of the problem and the difficulty of finding an appropriate analytical notation. Grover and MacGregor establish the maximum potential for preconfiguration in a number of example networks, by arriving at a single scalar value there called an upper bound on network readiness. On average, 79% of the crosspoints required for span restoration of a mesh-restorable network were found available in the networks considered. This leaves open the question of how to find a detailed preconfiguration of the network to achieve some portion of this potential. The particular question left open by Grover and MacGregor was how to devise a means of coordinating the total quantities of span-to-span interconnection so that individual link crossconnections would be most coherently related to those at other nodes.
The goal was stated as one of forming the maximum number of '- ~15 l 8~7 fully preconnected end-to-end paths for the average restoration case. The method disclosed here provides a method of achieving that goal for the specific case of anticipating all possible span failures in a mesh-restorable network, as well as being more generally applicable to a variety of failure modes and network types.
SU~ARY OF THE INVENTION
There is therefore provided, in accordance with one aspect of the invention, a method for restoring traffic in a network in which the network is pre-configured for span restoration. The network includes plural distinct nodes interconnected by plural distinct spans, each span having working links and spare links. Each node has a digital cross-connect switch for making and breaking connections between links in adjacent spans forming paths or path segments (span pairs) through nodes. In a broad characterization of the method, there are three steps.
Step 1: For each of at least two possible span failures, (a) find the number of restoration routes available in case of the occurrence of each span failure, (b) determine the resources used by each restoration route, and (c) determine the amount of flow to be restored for each span failure.
Step 2: find, in a computer, the amount of flow fP to be restored along each restoration route that minimizes total unrestored flow for all possible span failures identified in step 1.
Step 3: form connections at each digital cross-connect switch in the network along each restoration route before occurrence of one of the possible span failures identified in step 1 to permit the amount of flow fP
determined in step 2 to be carried by each respective ~16184 7 restoration route upon the occurrence of one of the possible span failures identified in step 1.
These and other aspects of the invention will be described in more detailed below and claimed in the claims that follow.
BRIEF DESCRIPTION OF THE DRAWINGS
There will now be described preferred embodiments of the invention, with reference to the drawings, by way of illustration, in which like numerals denote like elements and in which:
Fig. 1 is a schematic showing nodes of a network with a network control overlay for use in carrying out the method of the invention;
Fig. lA is a schematic showing the method steps as they are carried out by the computer at an operations center;
Fig. 2A illustrates a node with three spans connected to it;
Fig. 2B illustrates how the node of Fig. 2A in the original network is transformed for the calculation of the preconfiguration tableau;
Fig. 2C illustrates a pair of interconnected nodes, each with three spans connected to it;
Fig. 2D illustrates how the nodes of Fig. 2C in the original network are transformed using a virtual cross-bar for the calculation of the preconfiguration tableau;
Fig. 3 is a diagram which presents an example network for application of the method of the invention;
Fig. 4 is a diagram showing an exemplary network with 100% span restorability;
Fig. 5 is a diagram showing results of applying a real time restoration algorithm to the network of Fig. 4 upon the failure of span 7-9;
4 ~
Fig. 6 is a diagram showing a pre-configuration plan for the network of Fig. 4;
Fig. 7 is a diagram showing paths that are restorable using pre-configured restoration paths shown in Fig. 6 upon failure of span 7-9; and Fig. 8 is a diagram showing additional flow restored in the pre-configured network of Fig. 6 using a real time restoration process.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
Referring to Fig. 1, there is shown a network formed of plural distinct nodes 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 interconnected by plural distinct spans, each labelled 20. A specific span may be labelled according to the nodes it interconnects, so that the span connecting nodes 10 and 12 would be referred to as span 10-12 as in Fig. 1, or it may be labelled directly, as in Figs. 2A-2D
or Fig. 3. Each span 20 is a telecommunications facility link having working links and spare links, and may comprise for example OC-3 links. Each node 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 incorporates, and may be considered to consist essentially of, a conventional digital cross-connect switch for making and breaking connections between links in adjacent spans 20 at the node. The links in spans 20 connect to the nodes 10-19 through fiber optic terminals, for example AT&T FT Series G, for electrical/optic conversion of the signals. Exemplary digital cross-connect switches are the AT&T DACS IV-2000, Alcatel RDX-33 and the Tellabs Titan Model 5533. Adjacent spans, for example spans 10-12 and 12-16 form a span pair.
A network operations center 22, for example an AT&T
Transport and Maintenance System, controls the operation of the digital cross-connect switches 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 via a control overlay of for example 6~847 X.25 communications links 24. The network operations center 24 includes a computer 26 that carries out the computations in the operation of the method of the invention and that instructs the digital cross-connect switches 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 to make and break connections between links in adjacent spans 20. The computer may be, for example, a UNIX work station that may be connected directly to the digital cross-connect switches via the X.25 communications links and through an X.25 packet assembler-disassembler.
For practical implementation of the method of the invention, the network, the set of anticipated failures, and the intended means of reacting to those failures can be represented in the computer 26 as an objective function, a set of constraints which relate preconfiguration options to available network resources, and a set of constants which specify whether a given restoration reaction occupies a particular resource in the case of a particular failure.
Such a formulation may be called a tableau to determine the preferred preconfiguration of network resources to respond to one or more anticipated failures, or more simply a "preconfiguration tableau".
The set of constants to be input to the computer 26 are stored in the computer 26 in a memory 30 as illustrated in Fig. lA, which may be any of various kinds of computer readable memory. The constants may be entered via a conventional text editor or may be supplied through an additional program that generates the constants. The set of constraints to be input to the computer 26 are stored in the computer 26 in a memory 32, which may also be any of various kinds of memory. The set of constraints may likewise be entered to computer 26 through a conventional text editor or another program. Format of the input constants and constraints is determined by the optimization engine. The objective function is also stored in memory 34.
Memory 30, 32 and 34 may all be part of a larger memory.
Once a preconfiguration tableau is constructed within computer 26, it can be passed to any of a number of preexisting software packages (optimization engines) for solving optimization problems. The software package is loaded into the computer 26 where it configures the computer 26 as an optimization engine 36. The constants, objective function and constraint sets are then provided to the optimization engine 36, which calculates the optimized preconfiguration of resources for the network in compliance with the preconfiguration tableau. This preconfiguration of resources may be stored in a memory 38 or output directly to the network.
The output of the optimization engine is used to instruct the digital cross-connect switches 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 and put the network into a state of preferred readiness. An exemplary optimization engine that may be used in the implementation of the invention is the CPLEX Linear Optimization Base System available from CPLEX Optimization, Inc., Suite 279, 930 Tahoe Blvd, Bldg 802, Incline Village, Nevada 89451. The optimization engine may be linear or non-linear according to whether the objective function is linear or non-linear in the solution variables.
The objective function reflects operational priorities. For example, in the case of a transport network, the preferred objective is to preconfigure the network to minimize the sum of unrestored flow over all possible span failures, considered one at a time. This objective function can be written as:
Nf min~ Wiui i=l ~1618~
where ui is the unrestored flow for the ith failure given the preconfigured state of the network, wi is a weight which can be used to reflect the probability or cost of a given failure, and N~ is the number of failures being considered. The weights wi are selected by the operator, retrieved from memory, or may be input from another computer program.
In a voice network, the flow in the network is usually discussed in terms of carried traffic. The objective function for a voice network can be constructed in equivalent form to the above described objective function, in which it is sought to minimize lost traffic defined in terms of Erlang ~B~ losses or to minimize blocking. In a transport network, the objective function may be constructed to minimize the maximum flow remaining lost after restoration. In a data network, the objective function can be set up in form to minimize throughput loss or delay. The form of each of these objective functions is known in the art and need not be further described here.
The network is transformed, within the computer 26, into an equivalent representation as illustrated in Figs. 2A, 2B, 2C and 2D. Each possible span pair, for example spans Sl and S2 at a node 10, becomes an edge E1_2 in the transformed network as shown in Fig. 2B. The transformed edges of neighbouring nodes, as for example nodes 10 and 12 shown in Fig. 2C are represented as having edges joined with a full virtual crossbar 30 as shown in Fig. 2D. The computer 26 thus constructs a model of the network formed of cross-connected edges (span pairs).
The constraint sets specify the set of failures being considered (that is, which spans are being considered), the network resources available for responding to those failures (the spare capacities of the spans that might be used as restoration paths), and the choices available in responding to each failure, such as a variety of routing choices.
The constraints are defined in terms of flow, which in the context of a communications network represents the movement of signal units, but it could equally well represent the transport of commodities through a set of pipelines, or the carriage of goods over highways in trucks. The endpoints of span failure are sources and sinks of flow (e.g. Sender and Chooser in a distributed restoration algorithm), while flow is assumed to be conserved at intermediate nodes of the transformed network (e.g. Tandem nodes).
The constraint sets make use of both variables and constants. The variables are values manipulated by the optimization engine in order to arrive at a feasible, optimal solution. Each variable represents a state of a network element, and the values that the variable can take are the possible states of that element. For example, a variable might represent the number of connections being made at a node. The constants are fixed values which describe the features of the original network, and the preconfiguration options for each failure.
The constants in the constraint equations include the number s of spans in the original network, the restoration capacity Ri of each span, the number Nf of failures being considered, the amount of flow to be restored for each failure (the number of working links on a span whose failure is being considered), the number P of restoration routes for each failure, and the resources (spans) used by each restoration route. The resources are specified by the notation ~P, which takes the value 1 when a span j is in a given restoration route p, and zero otherwise. ~P is thus a matrix which reflects routes in the network. This matrix may be rather empty, containing ~161847 many zeros, so that in describing the route it may sometimes be simpler to specify the sequence of spans in a route.
All of these constants are inputs to the method.
S That is, the constants are input to the computer 26 when the computer 26 implements the optimization engine. The constants may be outputs from other software programs. For example, the restoration capacity of a given span may fluctuate, and a program may be used that keeps track of the state of the spans in the network. The output of this program will then specify one set of constants for the optimization engine. As another example, the set of constants which specifies the resources used to restore a particular failure can be quite large, depending on the size of the network. In general, if the location of the nodes and spans of a network are known, the preferred or shortest set of routes can be identified by well-known procedures. In a given case, since the number of restoration routes in a large network can be extremely large, various limits may be placed on the available restoration routes such as by number of spans (for example no more than, say, 10 spans in a route) or by distance along the route (for example the route may not be longer than 20,000 km) or by a combination of upper limits.
The preconfiguration state of the network is specified by the variables which give the amount of flow fP
on each restoration path. The values of fP are output from the optimization engine and may be automatically used to establish the cross-connections at each digital cross-connect switch along the specified restoration routes.
For minimizing unrestored flow in a transport network, the objective function is first defined. It is de6irable to keep the objective function linear in its variables, as this allows the use of linear programming 216 l 8~7 tools in solving the problem as for example the CPLEX
system. Such tools are widely available and can be very efficient.
The network is transformed into an equivalent representation as described in Figs. 2A, 2B, 2C and 2D.
The transformation and the constraint set generation are carried out within a software program in computer 26.
Seven constraint sets may be used in the tableau.
Ci j is the number of connections formed between spare links in spans i and j of the original network. Any other number of working links may also be corrected through this node for spans i, j but they are not of concern. Ci j is thus the number of restoration connections for i and j, and is the - capacity of edge i- j in the transformed network. For uniqueness, i< j . Restoration readiness connections can be made only between spans that meet at a common node (pairs of adjacent spans). The sum of the restoration connections involving a span is bounded by the restoration capacity of the span:
s Constraint set 1 (~ C~ Ri)~i=l, . . ., s fP is the restoration flow along the p~th restoration route through the preconfigured connections.
The amount of preconnected flow on a spare connection is bounded by the capacity assigned to that spare connection:
Constraint set 2 (~ ~jp~kfp~cj k) ~i~ k=l,..,,s p=l where ~ is zero unless fP crosses span j, in which case it is 1.
~6 a ~ ~ ~
Ck mi iS the number of pre-configuration connections to be made at a virtual crossbar between edges i-j and k-m. For uniqueness, i < j, k < m, and i < k.
Ck m iS the number of cross-over connections between 5 i- j and k-m and specify how much of the restoration capacity in i- j connections is allocated on the next hop to become k-m connections. ~Thus, one of i = k, i = m, j = k, or j = m must be true.) The amount of preconnected restoration flow on a cross-over connection is bounded by the amount of capacity assigned to that cross-over connection:
Constraint set 3 (~ ~pi~pk~pmfp~ck~mk) ~i,k,m=l, . . ., S
p=l The sum of cross-over connections to or from a given spare connection is bounded by the size of the spare connection:
Constraint set 4 (~ ~ Ckm~C~ i,j=l,...,s
Method for Preconfiguring a Network to Withstand Anticipated Failures NAME(S) OF INVENTOR(S):
Wayne D. Grover, Michael H. MacGregor FIELD OF THE INVENTION
This invention relates to methods for restoring networks of spans, for example telecommunications networks, upon the occurrence of a failure of one of the spans of the network.
R~GROUND OF THE INVENTION
Methods for the restoration of digital transport networks have been studied for several years. Some researchers have concluded that distributed real-time protocols may operate too slowly to meet operational objectives, such as the 2 second call-dropping threshold in voice networks. This problem can be overcome by preparing the network for anticipated failures by optimally preconfiguring resources which will be used to react to the failure. This places the network into a state of "best readiness" to face a given set of anticipated failures.
See W.D. Grover and M.H. MacGregor, "Potential for spare capacity preconnection to reduce crossconnection workloads in mesh-restorable networks", Electronics Letters, Vol. 30, No. 3, pp. 194-195, February 3, 1994, and M. Herzberg and S.J. Bye, "An optimal spare-capacity assignment model for survivable networks with hop limits", Proceedings of IEEE
Globecom ~94, Vol. 3, pp. 1601-1606, IEEE, 1994.
The tremendous interest in real-time network restoration over the last few years is evidence both of the ~ 21 61847 importance and difficulty of this problem. Evidence has been mounting that it may not always be possible to meet operational requirements with real-time techniques. The suggested cures have ranged from high speed, parallel computing architectures for digital crossconnect machines to simplified network architectures where restoration can be made to occur more quickly in real-time. The proposal of Grover and MacGregor suggests anticipating failures, and preconfiguring the network to handle them so that real-time computation or reaction delay (one or both) is not required except at the endpoints of the failure. Thus, preconfiguration methods apply where computing a reaction or implementing it (or both) is/are too lengthy a process.
Various heuristic methods can be proposed to solve the problem of preconfiguring a network, given the anticipated failures and the resources available for reacting to them. However, it is not obvious how to achieve an optimal state of preconfiguration, largely because of the combinatorial complexity of the problem and the difficulty of finding an appropriate analytical notation. Grover and MacGregor establish the maximum potential for preconfiguration in a number of example networks, by arriving at a single scalar value there called an upper bound on network readiness. On average, 79% of the crosspoints required for span restoration of a mesh-restorable network were found available in the networks considered. This leaves open the question of how to find a detailed preconfiguration of the network to achieve some portion of this potential. The particular question left open by Grover and MacGregor was how to devise a means of coordinating the total quantities of span-to-span interconnection so that individual link crossconnections would be most coherently related to those at other nodes.
The goal was stated as one of forming the maximum number of '- ~15 l 8~7 fully preconnected end-to-end paths for the average restoration case. The method disclosed here provides a method of achieving that goal for the specific case of anticipating all possible span failures in a mesh-restorable network, as well as being more generally applicable to a variety of failure modes and network types.
SU~ARY OF THE INVENTION
There is therefore provided, in accordance with one aspect of the invention, a method for restoring traffic in a network in which the network is pre-configured for span restoration. The network includes plural distinct nodes interconnected by plural distinct spans, each span having working links and spare links. Each node has a digital cross-connect switch for making and breaking connections between links in adjacent spans forming paths or path segments (span pairs) through nodes. In a broad characterization of the method, there are three steps.
Step 1: For each of at least two possible span failures, (a) find the number of restoration routes available in case of the occurrence of each span failure, (b) determine the resources used by each restoration route, and (c) determine the amount of flow to be restored for each span failure.
Step 2: find, in a computer, the amount of flow fP to be restored along each restoration route that minimizes total unrestored flow for all possible span failures identified in step 1.
Step 3: form connections at each digital cross-connect switch in the network along each restoration route before occurrence of one of the possible span failures identified in step 1 to permit the amount of flow fP
determined in step 2 to be carried by each respective ~16184 7 restoration route upon the occurrence of one of the possible span failures identified in step 1.
These and other aspects of the invention will be described in more detailed below and claimed in the claims that follow.
BRIEF DESCRIPTION OF THE DRAWINGS
There will now be described preferred embodiments of the invention, with reference to the drawings, by way of illustration, in which like numerals denote like elements and in which:
Fig. 1 is a schematic showing nodes of a network with a network control overlay for use in carrying out the method of the invention;
Fig. lA is a schematic showing the method steps as they are carried out by the computer at an operations center;
Fig. 2A illustrates a node with three spans connected to it;
Fig. 2B illustrates how the node of Fig. 2A in the original network is transformed for the calculation of the preconfiguration tableau;
Fig. 2C illustrates a pair of interconnected nodes, each with three spans connected to it;
Fig. 2D illustrates how the nodes of Fig. 2C in the original network are transformed using a virtual cross-bar for the calculation of the preconfiguration tableau;
Fig. 3 is a diagram which presents an example network for application of the method of the invention;
Fig. 4 is a diagram showing an exemplary network with 100% span restorability;
Fig. 5 is a diagram showing results of applying a real time restoration algorithm to the network of Fig. 4 upon the failure of span 7-9;
4 ~
Fig. 6 is a diagram showing a pre-configuration plan for the network of Fig. 4;
Fig. 7 is a diagram showing paths that are restorable using pre-configured restoration paths shown in Fig. 6 upon failure of span 7-9; and Fig. 8 is a diagram showing additional flow restored in the pre-configured network of Fig. 6 using a real time restoration process.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
Referring to Fig. 1, there is shown a network formed of plural distinct nodes 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 interconnected by plural distinct spans, each labelled 20. A specific span may be labelled according to the nodes it interconnects, so that the span connecting nodes 10 and 12 would be referred to as span 10-12 as in Fig. 1, or it may be labelled directly, as in Figs. 2A-2D
or Fig. 3. Each span 20 is a telecommunications facility link having working links and spare links, and may comprise for example OC-3 links. Each node 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 incorporates, and may be considered to consist essentially of, a conventional digital cross-connect switch for making and breaking connections between links in adjacent spans 20 at the node. The links in spans 20 connect to the nodes 10-19 through fiber optic terminals, for example AT&T FT Series G, for electrical/optic conversion of the signals. Exemplary digital cross-connect switches are the AT&T DACS IV-2000, Alcatel RDX-33 and the Tellabs Titan Model 5533. Adjacent spans, for example spans 10-12 and 12-16 form a span pair.
A network operations center 22, for example an AT&T
Transport and Maintenance System, controls the operation of the digital cross-connect switches 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 via a control overlay of for example 6~847 X.25 communications links 24. The network operations center 24 includes a computer 26 that carries out the computations in the operation of the method of the invention and that instructs the digital cross-connect switches 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 to make and break connections between links in adjacent spans 20. The computer may be, for example, a UNIX work station that may be connected directly to the digital cross-connect switches via the X.25 communications links and through an X.25 packet assembler-disassembler.
For practical implementation of the method of the invention, the network, the set of anticipated failures, and the intended means of reacting to those failures can be represented in the computer 26 as an objective function, a set of constraints which relate preconfiguration options to available network resources, and a set of constants which specify whether a given restoration reaction occupies a particular resource in the case of a particular failure.
Such a formulation may be called a tableau to determine the preferred preconfiguration of network resources to respond to one or more anticipated failures, or more simply a "preconfiguration tableau".
The set of constants to be input to the computer 26 are stored in the computer 26 in a memory 30 as illustrated in Fig. lA, which may be any of various kinds of computer readable memory. The constants may be entered via a conventional text editor or may be supplied through an additional program that generates the constants. The set of constraints to be input to the computer 26 are stored in the computer 26 in a memory 32, which may also be any of various kinds of memory. The set of constraints may likewise be entered to computer 26 through a conventional text editor or another program. Format of the input constants and constraints is determined by the optimization engine. The objective function is also stored in memory 34.
Memory 30, 32 and 34 may all be part of a larger memory.
Once a preconfiguration tableau is constructed within computer 26, it can be passed to any of a number of preexisting software packages (optimization engines) for solving optimization problems. The software package is loaded into the computer 26 where it configures the computer 26 as an optimization engine 36. The constants, objective function and constraint sets are then provided to the optimization engine 36, which calculates the optimized preconfiguration of resources for the network in compliance with the preconfiguration tableau. This preconfiguration of resources may be stored in a memory 38 or output directly to the network.
The output of the optimization engine is used to instruct the digital cross-connect switches 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 and put the network into a state of preferred readiness. An exemplary optimization engine that may be used in the implementation of the invention is the CPLEX Linear Optimization Base System available from CPLEX Optimization, Inc., Suite 279, 930 Tahoe Blvd, Bldg 802, Incline Village, Nevada 89451. The optimization engine may be linear or non-linear according to whether the objective function is linear or non-linear in the solution variables.
The objective function reflects operational priorities. For example, in the case of a transport network, the preferred objective is to preconfigure the network to minimize the sum of unrestored flow over all possible span failures, considered one at a time. This objective function can be written as:
Nf min~ Wiui i=l ~1618~
where ui is the unrestored flow for the ith failure given the preconfigured state of the network, wi is a weight which can be used to reflect the probability or cost of a given failure, and N~ is the number of failures being considered. The weights wi are selected by the operator, retrieved from memory, or may be input from another computer program.
In a voice network, the flow in the network is usually discussed in terms of carried traffic. The objective function for a voice network can be constructed in equivalent form to the above described objective function, in which it is sought to minimize lost traffic defined in terms of Erlang ~B~ losses or to minimize blocking. In a transport network, the objective function may be constructed to minimize the maximum flow remaining lost after restoration. In a data network, the objective function can be set up in form to minimize throughput loss or delay. The form of each of these objective functions is known in the art and need not be further described here.
The network is transformed, within the computer 26, into an equivalent representation as illustrated in Figs. 2A, 2B, 2C and 2D. Each possible span pair, for example spans Sl and S2 at a node 10, becomes an edge E1_2 in the transformed network as shown in Fig. 2B. The transformed edges of neighbouring nodes, as for example nodes 10 and 12 shown in Fig. 2C are represented as having edges joined with a full virtual crossbar 30 as shown in Fig. 2D. The computer 26 thus constructs a model of the network formed of cross-connected edges (span pairs).
The constraint sets specify the set of failures being considered (that is, which spans are being considered), the network resources available for responding to those failures (the spare capacities of the spans that might be used as restoration paths), and the choices available in responding to each failure, such as a variety of routing choices.
The constraints are defined in terms of flow, which in the context of a communications network represents the movement of signal units, but it could equally well represent the transport of commodities through a set of pipelines, or the carriage of goods over highways in trucks. The endpoints of span failure are sources and sinks of flow (e.g. Sender and Chooser in a distributed restoration algorithm), while flow is assumed to be conserved at intermediate nodes of the transformed network (e.g. Tandem nodes).
The constraint sets make use of both variables and constants. The variables are values manipulated by the optimization engine in order to arrive at a feasible, optimal solution. Each variable represents a state of a network element, and the values that the variable can take are the possible states of that element. For example, a variable might represent the number of connections being made at a node. The constants are fixed values which describe the features of the original network, and the preconfiguration options for each failure.
The constants in the constraint equations include the number s of spans in the original network, the restoration capacity Ri of each span, the number Nf of failures being considered, the amount of flow to be restored for each failure (the number of working links on a span whose failure is being considered), the number P of restoration routes for each failure, and the resources (spans) used by each restoration route. The resources are specified by the notation ~P, which takes the value 1 when a span j is in a given restoration route p, and zero otherwise. ~P is thus a matrix which reflects routes in the network. This matrix may be rather empty, containing ~161847 many zeros, so that in describing the route it may sometimes be simpler to specify the sequence of spans in a route.
All of these constants are inputs to the method.
S That is, the constants are input to the computer 26 when the computer 26 implements the optimization engine. The constants may be outputs from other software programs. For example, the restoration capacity of a given span may fluctuate, and a program may be used that keeps track of the state of the spans in the network. The output of this program will then specify one set of constants for the optimization engine. As another example, the set of constants which specifies the resources used to restore a particular failure can be quite large, depending on the size of the network. In general, if the location of the nodes and spans of a network are known, the preferred or shortest set of routes can be identified by well-known procedures. In a given case, since the number of restoration routes in a large network can be extremely large, various limits may be placed on the available restoration routes such as by number of spans (for example no more than, say, 10 spans in a route) or by distance along the route (for example the route may not be longer than 20,000 km) or by a combination of upper limits.
The preconfiguration state of the network is specified by the variables which give the amount of flow fP
on each restoration path. The values of fP are output from the optimization engine and may be automatically used to establish the cross-connections at each digital cross-connect switch along the specified restoration routes.
For minimizing unrestored flow in a transport network, the objective function is first defined. It is de6irable to keep the objective function linear in its variables, as this allows the use of linear programming 216 l 8~7 tools in solving the problem as for example the CPLEX
system. Such tools are widely available and can be very efficient.
The network is transformed into an equivalent representation as described in Figs. 2A, 2B, 2C and 2D.
The transformation and the constraint set generation are carried out within a software program in computer 26.
Seven constraint sets may be used in the tableau.
Ci j is the number of connections formed between spare links in spans i and j of the original network. Any other number of working links may also be corrected through this node for spans i, j but they are not of concern. Ci j is thus the number of restoration connections for i and j, and is the - capacity of edge i- j in the transformed network. For uniqueness, i< j . Restoration readiness connections can be made only between spans that meet at a common node (pairs of adjacent spans). The sum of the restoration connections involving a span is bounded by the restoration capacity of the span:
s Constraint set 1 (~ C~ Ri)~i=l, . . ., s fP is the restoration flow along the p~th restoration route through the preconfigured connections.
The amount of preconnected flow on a spare connection is bounded by the capacity assigned to that spare connection:
Constraint set 2 (~ ~jp~kfp~cj k) ~i~ k=l,..,,s p=l where ~ is zero unless fP crosses span j, in which case it is 1.
~6 a ~ ~ ~
Ck mi iS the number of pre-configuration connections to be made at a virtual crossbar between edges i-j and k-m. For uniqueness, i < j, k < m, and i < k.
Ck m iS the number of cross-over connections between 5 i- j and k-m and specify how much of the restoration capacity in i- j connections is allocated on the next hop to become k-m connections. ~Thus, one of i = k, i = m, j = k, or j = m must be true.) The amount of preconnected restoration flow on a cross-over connection is bounded by the amount of capacity assigned to that cross-over connection:
Constraint set 3 (~ ~pi~pk~pmfp~ck~mk) ~i,k,m=l, . . ., S
p=l The sum of cross-over connections to or from a given spare connection is bounded by the size of the spare connection:
Constraint set 4 (~ ~ Ckm~C~ i,j=l,...,s
2 0 k=l m=l Ui represents the flow left unrestored by the preconfiguration plan for failure i, di represents the amount of flow to be restored after failure i, and ri represents the amount of flow restorable in excess of the demand (super-restorable flow). Then:
p Constraint set 5 tui+~ ~l f p=di+r~ . . ., Nf p=l where the ~ are 0/1 according to whether fP can be used for restoring failure i: In the case of span restoration, is 1 for any flow whose route contains the end-nodes of the ~15~847 failed span, and that route does not contain the failed span, and P is the number of restoration routes being considered over all failures. It is preferable to treat the ~P as input constants and write them into the constraint set, thus removing all variables for which the multiplier is zero.
The amount of unrestored flow is bounded by the total demand:
Constraint set 6 (ui < di)~i = 1, ...,s The number of demand units in excess of what is required for restoration of a span, ri, and the flow on a route, fP, are non-negative. All variables may be required to be non-negative integers, which complicates the solution and may require a very large amount of computation.
If the cross-checking provided by the counts of spare connections between spans and the counts of cross-over connections between pairs of spans is not required, then constraint sets 2 and 4 can be omitted, and constraint set 1 is written in terms of flow:
Constraint set 8 (~ ~ifP5Ri) ~i=1, . .,, 5 p=l Once the tableau has been written, it must be submitted to an optimization engine to find an optimal solution. The format of the tableau is specified by the particular optimization engine used. The information specified above, applied to a particular problem, such as one of the problems described below, is sufficient to instruct the CPLEX optimization engine. The output from the 18~7 engine will include the value of the objective function, and values for all the variables. The preconfiguration state of the network is derived from the values of the fP
by mapping these flows onto the network, and preconfiguring resources (e.g. by operating the digital cross-connect switches at the nodes traversed by each restoration route) to support the given amount of flow. The state of the network can be double-checked by testing whether the numbers of spare connections and cross-over connections match those in the output from the optimization engine.
The example network and results shown in Fig. 3 briefly illustrate the method. There are eight boxes numbered 0 through 7 representing eight network nodes, and nine circles numbered S0 to S8 representing the spans in the network. The numbers in parentheses beside each span represent the working and spare capacity of each span. A
preconfiguration plan has been developed to anticipate failures on spans S0, Sl and S2. In each case, the failure of a span results in the loss of 70 working links. In general, the spans could have different working capacities.
The network transformation results in 12 variables representing spare connections, and 16 variables representing crossover connections. After defining the objective function, the constraints in the manner disclosed in constraint sets 1 - 7 and solving the tableau, the results shown below are obtained, where the pj have been used to describe the sequence of nodes traversed by the ~th restoration path, rather than including the matrix of values for all the ~.
c2,3 = 20, C3~4 =90, C1~4= 20, C1~5 = 50, C4~5 = 70, c5,6 = 120 C0~6 = 50 c0,7 = 50 c7,8 = 120 Cl,8 = 50 C1,2 = o, C2~8 = 20, ~lg 17 C3 4=20, C3 4=20, C3 s=70, C54 6=70, C5 5=50, C5 6=50, Co 7=50, C7 8 =5 0, Cl 8 =O, Cl 8 =5 0, C7 8 =5 0, C2 3 =O, Cl 4 =O, Cl 5 =O, C23=20,C78=20 fl = 20, pl = 6-7-1-2-3-0-4-5, f2 = 50, p2 = 6-7-1-0-4-5, f3 = 50, p3 = 0-4-5-6-7-1-2-3, f4 = 20, p4 = 0-1-2-3 Two paths are used for each failure, span 0 uses paths 1 and 2, span 1 uses the 1-2-3-0 segment of path 1 and the 0-4-5-6-7-1 segment of path 3, and span 2 uses paths 3 and 4. In this particular case, 100% of the capacity required is preconfigured. That is, the network ~i6l847 is in a state of complete readiness for any one of these three failures. The network is pre-configured by ensuring that each digital cross-connect switch connects the spans in the network according to the spare connections and cross-over connections that are output from the optimization engine.
The particular crosspoints which must be closed by the digital cross-connect switch at each node can also be determined directly from the flows fP output by the optimization engine. The spans making up the path followed by a given flow fP are those for which ~P has the value 1.
First, the two terminal spans of the path are identified. Starting with either terminal span of the path, an unused spare link in the span is identified, and then an unused spare link in the next span is identified. The cross-point between the two spare links, which is at the first intermediate node in the path, is then operated to connect the unused spare links in the first and second spans of the path. Next, an unused spare link in the third span is identified and the crosspoint connecting the spare link in the second span to the spare link in the third span is operated at the digital cross-connect switch at the second intermediate node (between spans 2 and 3). This process continues until the second last node in the path, at which a crosspoint is operated between an unused spare link in the second last span to one in the last span.
Once all the nonzero flows in the preconfiguration solution have been processed in this manner, all the required crosspoints have been operated.
The correctness of the operation can be double-checked at each crossconnect, by checking to make sure that the number of crosspoints actually operated between any two spans matches the number of spare connections, Ci j, for that span pair, and also by checking to make sure that the number of crossover connections joining a sequence of three spans matches the number of crossover connections, Ck,] , as output by the optimizer.
A further example will now be described in relation to Figs. 4-8.
Referring to Fig. 4, there is shown a network having nodes 10, 11, 12, 13, 14, 15, 16, 17, 18 and 19.
(n,m) on a given span indicates the working (n) and spare (m) capacity of the span. If span 17-19 fails, 8 working links are lost. The network shown in Fig. 4 is configured for 100~ span restorability. A real time restoration algorithm for example according to the technique outlined in United States patent no. 4,956,835 issued Sept. 11, 1990, in the name of Wayne Grover will yield the restoration paths shown in Fig. 5. For rapid implementation of a restoration plan, however, according to the method of the invention, a pre-configuration plan is shown in Fig. 6 which specifies the restoration paths, and the cross-points pre-configured. The boxes associated with each node or digital cross-connect switch 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 indicates the respective nodes that are connected and the number of links made available for restoration flow. Thus, the digital cross-connect switch 12 is operated to join nodes 10 and 16 with one link, nodes 10 and 18 with two links and nodes 13 and 16 with one link. As shown in Fig. 8, upon the failure of span 17-19, four unit restoration paths are found fully pre-connected, while the remainder are restored dynamically by a real time restoration algorithm.
The objective function can be recalculated at time intervals corresponding approximately to the rate of change of the input constants. Thus, as network conditions ~ 1 51~4~
change, the optimization tableau may be submitted to the optimization engine to update the preconfiguration of the network, either automatically at fixed time intervals or when needed or a mixture of both strategies.
A person skilled in the art could make immaterial modifications to the invention described in this patent without departing from the essence of the invention.
p Constraint set 5 tui+~ ~l f p=di+r~ . . ., Nf p=l where the ~ are 0/1 according to whether fP can be used for restoring failure i: In the case of span restoration, is 1 for any flow whose route contains the end-nodes of the ~15~847 failed span, and that route does not contain the failed span, and P is the number of restoration routes being considered over all failures. It is preferable to treat the ~P as input constants and write them into the constraint set, thus removing all variables for which the multiplier is zero.
The amount of unrestored flow is bounded by the total demand:
Constraint set 6 (ui < di)~i = 1, ...,s The number of demand units in excess of what is required for restoration of a span, ri, and the flow on a route, fP, are non-negative. All variables may be required to be non-negative integers, which complicates the solution and may require a very large amount of computation.
If the cross-checking provided by the counts of spare connections between spans and the counts of cross-over connections between pairs of spans is not required, then constraint sets 2 and 4 can be omitted, and constraint set 1 is written in terms of flow:
Constraint set 8 (~ ~ifP5Ri) ~i=1, . .,, 5 p=l Once the tableau has been written, it must be submitted to an optimization engine to find an optimal solution. The format of the tableau is specified by the particular optimization engine used. The information specified above, applied to a particular problem, such as one of the problems described below, is sufficient to instruct the CPLEX optimization engine. The output from the 18~7 engine will include the value of the objective function, and values for all the variables. The preconfiguration state of the network is derived from the values of the fP
by mapping these flows onto the network, and preconfiguring resources (e.g. by operating the digital cross-connect switches at the nodes traversed by each restoration route) to support the given amount of flow. The state of the network can be double-checked by testing whether the numbers of spare connections and cross-over connections match those in the output from the optimization engine.
The example network and results shown in Fig. 3 briefly illustrate the method. There are eight boxes numbered 0 through 7 representing eight network nodes, and nine circles numbered S0 to S8 representing the spans in the network. The numbers in parentheses beside each span represent the working and spare capacity of each span. A
preconfiguration plan has been developed to anticipate failures on spans S0, Sl and S2. In each case, the failure of a span results in the loss of 70 working links. In general, the spans could have different working capacities.
The network transformation results in 12 variables representing spare connections, and 16 variables representing crossover connections. After defining the objective function, the constraints in the manner disclosed in constraint sets 1 - 7 and solving the tableau, the results shown below are obtained, where the pj have been used to describe the sequence of nodes traversed by the ~th restoration path, rather than including the matrix of values for all the ~.
c2,3 = 20, C3~4 =90, C1~4= 20, C1~5 = 50, C4~5 = 70, c5,6 = 120 C0~6 = 50 c0,7 = 50 c7,8 = 120 Cl,8 = 50 C1,2 = o, C2~8 = 20, ~lg 17 C3 4=20, C3 4=20, C3 s=70, C54 6=70, C5 5=50, C5 6=50, Co 7=50, C7 8 =5 0, Cl 8 =O, Cl 8 =5 0, C7 8 =5 0, C2 3 =O, Cl 4 =O, Cl 5 =O, C23=20,C78=20 fl = 20, pl = 6-7-1-2-3-0-4-5, f2 = 50, p2 = 6-7-1-0-4-5, f3 = 50, p3 = 0-4-5-6-7-1-2-3, f4 = 20, p4 = 0-1-2-3 Two paths are used for each failure, span 0 uses paths 1 and 2, span 1 uses the 1-2-3-0 segment of path 1 and the 0-4-5-6-7-1 segment of path 3, and span 2 uses paths 3 and 4. In this particular case, 100% of the capacity required is preconfigured. That is, the network ~i6l847 is in a state of complete readiness for any one of these three failures. The network is pre-configured by ensuring that each digital cross-connect switch connects the spans in the network according to the spare connections and cross-over connections that are output from the optimization engine.
The particular crosspoints which must be closed by the digital cross-connect switch at each node can also be determined directly from the flows fP output by the optimization engine. The spans making up the path followed by a given flow fP are those for which ~P has the value 1.
First, the two terminal spans of the path are identified. Starting with either terminal span of the path, an unused spare link in the span is identified, and then an unused spare link in the next span is identified. The cross-point between the two spare links, which is at the first intermediate node in the path, is then operated to connect the unused spare links in the first and second spans of the path. Next, an unused spare link in the third span is identified and the crosspoint connecting the spare link in the second span to the spare link in the third span is operated at the digital cross-connect switch at the second intermediate node (between spans 2 and 3). This process continues until the second last node in the path, at which a crosspoint is operated between an unused spare link in the second last span to one in the last span.
Once all the nonzero flows in the preconfiguration solution have been processed in this manner, all the required crosspoints have been operated.
The correctness of the operation can be double-checked at each crossconnect, by checking to make sure that the number of crosspoints actually operated between any two spans matches the number of spare connections, Ci j, for that span pair, and also by checking to make sure that the number of crossover connections joining a sequence of three spans matches the number of crossover connections, Ck,] , as output by the optimizer.
A further example will now be described in relation to Figs. 4-8.
Referring to Fig. 4, there is shown a network having nodes 10, 11, 12, 13, 14, 15, 16, 17, 18 and 19.
(n,m) on a given span indicates the working (n) and spare (m) capacity of the span. If span 17-19 fails, 8 working links are lost. The network shown in Fig. 4 is configured for 100~ span restorability. A real time restoration algorithm for example according to the technique outlined in United States patent no. 4,956,835 issued Sept. 11, 1990, in the name of Wayne Grover will yield the restoration paths shown in Fig. 5. For rapid implementation of a restoration plan, however, according to the method of the invention, a pre-configuration plan is shown in Fig. 6 which specifies the restoration paths, and the cross-points pre-configured. The boxes associated with each node or digital cross-connect switch 10, 11, 12, 12, 13, 14, 15, 16, 17, 18 and 19 indicates the respective nodes that are connected and the number of links made available for restoration flow. Thus, the digital cross-connect switch 12 is operated to join nodes 10 and 16 with one link, nodes 10 and 18 with two links and nodes 13 and 16 with one link. As shown in Fig. 8, upon the failure of span 17-19, four unit restoration paths are found fully pre-connected, while the remainder are restored dynamically by a real time restoration algorithm.
The objective function can be recalculated at time intervals corresponding approximately to the rate of change of the input constants. Thus, as network conditions ~ 1 51~4~
change, the optimization tableau may be submitted to the optimization engine to update the preconfiguration of the network, either automatically at fixed time intervals or when needed or a mixture of both strategies.
A person skilled in the art could make immaterial modifications to the invention described in this patent without departing from the essence of the invention.
Claims (12)
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. A method for restoring traffic in a network in which the network includes plural distinct nodes interconnected by plural distinct spans, each span having working links and spare links, and having a span capacity, each node having a digital cross-connect switch for making and breaking connections between links in adjacent spans forming span paths through a node, the method comprising the steps of:
(1) for each of at least two possible span failures, (a) finding a number of restoration routes that are available in case of the occurrence of each span failure, (b) determining the resources used by each restoration route, and (c) determining the amount of flow to be restored for each span failure;
(2) finding, in a computer, the amount of flow fP
to be restored along each restoration route that minimizes total unrestored flow for all possible span failures identified in step 1; and (3) forming connections at each digital cross-connect switch in the network along each restoration route before occurrence of one of the possible span failures identified in step 1 to permit the amount of flow fP
determined in step 2 to be carried by each respective restoration route upon the occurrence of one of the possible span failures identified in step 1.
(1) for each of at least two possible span failures, (a) finding a number of restoration routes that are available in case of the occurrence of each span failure, (b) determining the resources used by each restoration route, and (c) determining the amount of flow to be restored for each span failure;
(2) finding, in a computer, the amount of flow fP
to be restored along each restoration route that minimizes total unrestored flow for all possible span failures identified in step 1; and (3) forming connections at each digital cross-connect switch in the network along each restoration route before occurrence of one of the possible span failures identified in step 1 to permit the amount of flow fP
determined in step 2 to be carried by each respective restoration route upon the occurrence of one of the possible span failures identified in step 1.
2. The method of claim 1 further including:
finding in a computer an assignment of connections between links in adjacent spans in the network that minimizes total unrestored flow for all possible span failures identified in step 1; and forming the connections at each digital cross-connect switch in the network by instructing each digital cross-connect switch in the network to make connections according to the assignment of connections.
finding in a computer an assignment of connections between links in adjacent spans in the network that minimizes total unrestored flow for all possible span failures identified in step 1; and forming the connections at each digital cross-connect switch in the network by instructing each digital cross-connect switch in the network to make connections according to the assignment of connections.
3. The method of claim 1 in which finding, in a computer, the amount of flow fP to be restored along each restoration route includes:
forming a transformed network in which each span pair at a node is an edge in the transformed network and edges between adjacent nodes are cross-connected.
forming a transformed network in which each span pair at a node is an edge in the transformed network and edges between adjacent nodes are cross-connected.
4. The method of claim 1 in which finding, in a computer, the amount of flow fP to be restored along each restoration route includes:
generating a first set of constraints relating the number of connections preconfigured for restoration between each two adjacent spans of the original network to the capacities of the two adjacent spans; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the first set of constraints.
generating a first set of constraints relating the number of connections preconfigured for restoration between each two adjacent spans of the original network to the capacities of the two adjacent spans; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the first set of constraints.
5. The method of claim 1 in which finding, in a computer, the amount of flow fP to be restored along each restoration route includes:
generating a second set of constraints relating the amount of flow to be restored between each two adjacent spans of the original network to the number of spare links between the adjacent spans; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the second set of constraints.
generating a second set of constraints relating the amount of flow to be restored between each two adjacent spans of the original network to the number of spare links between the adjacent spans; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the second set of constraints.
6. The method of claim 1 in which finding, in a computer, the amount of flow fP to be restored along each restoration route includes:
generating a third set of constraints relating the amount of flow to be restored between three consecutive spans of the original network to the capacity of cross-connections between the consecutive spans; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the third set of constraints.
generating a third set of constraints relating the amount of flow to be restored between three consecutive spans of the original network to the capacity of cross-connections between the consecutive spans; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the third set of constraints.
7. The method of claim 1 in which finding, in a computer, the amount of flow fP to be restored along each restoration route includes:
generating a fourth set of constraints relating the amount of flow used to restore a particular span failure to the number of working links on the particular span before failure; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the fourth set of constraints.
generating a fourth set of constraints relating the amount of flow used to restore a particular span failure to the number of working links on the particular span before failure; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the fourth set of constraints.
8. The method of claim 1 in which finding, in a computer, the amount of flow fP to be restored along each restoration route includes:
generating a fifth set of constraints relating the amount of flow on a particular span that cannot be restored upon the failure of that span to the number of working links on the particular span before failure; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the fifth set of constraints.
generating a fifth set of constraints relating the amount of flow on a particular span that cannot be restored upon the failure of that span to the number of working links on the particular span before failure; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the fifth set of constraints.
9. The method of claim 1 in which finding, in a computer, the amount of flow fP to be restored along each restoration route includes:
generating a sixth set of constraints relating the number of working links of a particular span before failure of that span to the restoration capacity of that span; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the sixth set of constraints.
generating a sixth set of constraints relating the number of working links of a particular span before failure of that span to the restoration capacity of that span; and minimizing total unrestored flow for all possible span failures identified in step 1 subject to the sixth set of constraints.
10. The method of claim 1 further including, upon occurrence of a span failure, restoring capacity in the network according to a real-time restoration process.
11. The method of claim 1 in which forming the connections at each digital cross-connect switch in the network is carried out, for each restoration route, by:
identifying a starting node in the restoration route; and instructing the digital cross-connect switch at that node, and at each subsequent node in the network along the restoration route, to make connections determined by the restoration flow for that restoration route.
identifying a starting node in the restoration route; and instructing the digital cross-connect switch at that node, and at each subsequent node in the network along the restoration route, to make connections determined by the restoration flow for that restoration route.
12. A method for restoring traffic in a network in which the network includes plural distinct nodes interconnected by plural distinct spans, each span having working links and spare links, and having a span capacity, each node having a digital cross-connect switch for making and breaking connections between adjacent spans forming span paths through a node, the method comprising the steps of:
(1) for each of at least two possible span failures, (a) finding the number of restoration routes available in case of the occurrence of each span failure, (b) determining the resources used by each restoration route, and (c) determining the amount of flow to be restored for each span failure;
(2) finding, in a computer, the amount of flow fP
to be restored along each restoration route that minimizes spare capacity for all possible span failures identified in step 1; and (3) forming connections at each digital cross-connect switch in the network along each restoration route before occurrence of one of the possible span failures identified in step 1 to permit the amount of flow fP
determined in step 2 to be carried by each respective restoration route upon the occurrence of one of the possible span failures identified in step 1.
(1) for each of at least two possible span failures, (a) finding the number of restoration routes available in case of the occurrence of each span failure, (b) determining the resources used by each restoration route, and (c) determining the amount of flow to be restored for each span failure;
(2) finding, in a computer, the amount of flow fP
to be restored along each restoration route that minimizes spare capacity for all possible span failures identified in step 1; and (3) forming connections at each digital cross-connect switch in the network along each restoration route before occurrence of one of the possible span failures identified in step 1 to permit the amount of flow fP
determined in step 2 to be carried by each respective restoration route upon the occurrence of one of the possible span failures identified in step 1.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002161847A CA2161847A1 (en) | 1995-10-31 | 1995-10-31 | Method for preconfiguring a network to withstand anticipated failures |
| US08/551,709 US5850505A (en) | 1995-10-31 | 1995-11-01 | Method for preconfiguring a network to withstand anticipated failures |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002161847A CA2161847A1 (en) | 1995-10-31 | 1995-10-31 | Method for preconfiguring a network to withstand anticipated failures |
| US08/551,709 US5850505A (en) | 1995-10-31 | 1995-11-01 | Method for preconfiguring a network to withstand anticipated failures |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2161847A1 true CA2161847A1 (en) | 1997-05-01 |
Family
ID=25678198
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002161847A Abandoned CA2161847A1 (en) | 1995-10-31 | 1995-10-31 | Method for preconfiguring a network to withstand anticipated failures |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5850505A (en) |
| CA (1) | CA2161847A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0907303A3 (en) * | 1997-10-01 | 2004-12-08 | Nortel Networks Limited | Communication system architecture and operating methods thereof |
| US9025464B2 (en) | 2002-12-05 | 2015-05-05 | Telecommunications Research Laboratories | Method for design of networks based on p-cycles |
Families Citing this family (59)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6496476B1 (en) | 1997-03-12 | 2002-12-17 | Worldcom, Inc. | System and method for restricted reuse of intact portions of failed paths |
| US6411598B1 (en) | 1997-03-12 | 2002-06-25 | Mci Communications Corporation | Signal conversion for fault isolation |
| US6507561B1 (en) | 1997-03-12 | 2003-01-14 | Worldcom, Inc. | Telecommunications network distributed restoration method and system |
| US6456588B1 (en) * | 1997-04-21 | 2002-09-24 | At&T Corp. | Hypercube routing and restoration in telecommunications networks |
| US6215867B1 (en) * | 1997-06-20 | 2001-04-10 | At&T Corp. | Telecommunications network architecture with rapid restoration |
| US5958063A (en) * | 1997-06-30 | 1999-09-28 | Mci Communications Corporation | Method and system for pre-patching a communications network |
| US6421349B1 (en) * | 1997-07-11 | 2002-07-16 | Telecommunications Research Laboratories | Distributed preconfiguration of spare capacity in closed paths for network restoration |
| US6130876A (en) * | 1997-09-24 | 2000-10-10 | At&T Corp | Method and apparatus for restoring a network |
| US6021113A (en) * | 1997-10-29 | 2000-02-01 | Lucent Technologies Inc. | Distributed precomputation of network signal paths with table-based link capacity control |
| US6151304A (en) * | 1997-10-29 | 2000-11-21 | Lucent Technologies Inc. | Distributed precomputation of network signal paths with improved performance through parallelization |
| US6137775A (en) * | 1997-12-31 | 2000-10-24 | Mci Communications Corporation | Spare capacity planning tool |
| US6337846B1 (en) | 1998-09-08 | 2002-01-08 | Mci Worldcom, Inc. | Quantification of the quality of spare links in a telecommunications network |
| US6418117B1 (en) | 1998-09-08 | 2002-07-09 | Mci Worldcom, Inc. | Out of band messaging in a DRA network |
| US6294991B1 (en) | 1998-09-08 | 2001-09-25 | Mci Communications Corporation | Method and system therefor for ensuring a true activation of distributed restoration in a telecommunications network |
| US6456589B1 (en) * | 1998-09-08 | 2002-09-24 | Worldcom, Inc. | Method of coordinating the respective operations of different restoration processes |
| US6404733B1 (en) | 1998-09-08 | 2002-06-11 | Mci Worldcom, Inc. | Method of exercising a distributed restoration process in an operational telecommunications network |
| US6078659A (en) * | 1998-09-29 | 2000-06-20 | At&T Corp. | Apparatus and method for fast automated recovery from toll switch failure in a telephone network |
| US6498778B1 (en) * | 1998-12-17 | 2002-12-24 | At&T Corp. | Optimizing restoration capacity |
| CA2269649A1 (en) | 1999-04-22 | 2000-10-22 | Telecommunications Research Laboratories | Protection of routers in a telecommunications network |
| US6819662B1 (en) | 1999-04-29 | 2004-11-16 | Telecommunications Research Laboratories | Method for protecting a telecommunications network |
| US6813240B1 (en) | 1999-06-11 | 2004-11-02 | Mci, Inc. | Method of identifying low quality links in a telecommunications network |
| US6535481B1 (en) | 1999-08-20 | 2003-03-18 | Nortel Networks Limited | Network data routing protection cycles for automatic protection switching |
| US6549513B1 (en) * | 1999-10-12 | 2003-04-15 | Alcatel | Method and apparatus for fast distributed restoration of a communication network |
| US6392989B1 (en) | 2000-06-15 | 2002-05-21 | Cplane Inc. | High speed protection switching in label switched networks through pre-computation of alternate routes |
| JP3578062B2 (en) * | 2000-08-09 | 2004-10-20 | 日本電気株式会社 | Communication network design circuit, design method therefor, and recording medium and transmission medium recording control program therefor |
| AU2001281240A1 (en) * | 2000-08-10 | 2002-02-25 | University Of Pittsburgh | Apparatus and method for spare capacity allocation |
| CA2359168A1 (en) * | 2000-10-25 | 2002-04-25 | John Doucette | Design of meta-mesh of chain sub-networks |
| US7075892B2 (en) * | 2000-11-03 | 2006-07-11 | Telecommunications Research Laboratories | Topological design of survivable mesh-based transport networks |
| US6982951B2 (en) * | 2000-12-21 | 2006-01-03 | At&T Corp. | Method for selecting a restoration path in a mesh network |
| US8103789B1 (en) | 2001-03-01 | 2012-01-24 | Juniper Networks, Inc. | Method and apparatus for computing a backup path using fate sharing information |
| US6850705B2 (en) | 2001-03-17 | 2005-02-01 | Fujitsu Limited | Online distributed path routing method and system |
| US7126921B2 (en) | 2001-05-14 | 2006-10-24 | Tropic Networks Inc. | Packet network providing fast distribution of node related information and a method therefor |
| US7652983B1 (en) * | 2001-06-25 | 2010-01-26 | At&T Intellectual Property Ii, L.P. | Method for restoration and normalization in a mesh network |
| CA2392123A1 (en) * | 2001-06-28 | 2002-12-28 | Telecommunications Research Laboratories | Evolution of a telecommunications network from ring to mesh structure |
| US20030117950A1 (en) * | 2001-12-26 | 2003-06-26 | Huang Gail G | Link redial for mesh protection |
| US6778492B2 (en) * | 2002-01-17 | 2004-08-17 | Cisco Technology, Inc. | Load balancing for fast reroute backup tunnels |
| WO2003077423A2 (en) | 2002-03-08 | 2003-09-18 | Quellan, Inc. | High speed analog-to-digital converter using a unique gray code having minimal bit transitions |
| US6954788B2 (en) | 2002-06-26 | 2005-10-11 | Qwest Communications International, Inc. | Communication resource system |
| AU2003256569A1 (en) | 2002-07-15 | 2004-02-02 | Quellan, Inc. | Adaptive noise filtering and equalization |
| US7848249B1 (en) | 2002-09-30 | 2010-12-07 | Cisco Technology, Inc. | Method for computing FRR backup tunnels using aggregate bandwidth constraints |
| US7418493B1 (en) * | 2002-09-30 | 2008-08-26 | Cisco Technology, Inc. | Method for computing FRR backup tunnels using aggregate bandwidth constraints |
| US7934144B2 (en) | 2002-11-12 | 2011-04-26 | Quellan, Inc. | High-speed analog-to-digital conversion with improved robustness to timing uncertainty |
| US7969862B1 (en) * | 2003-03-04 | 2011-06-28 | Ciena Corporation | Cycle-based restoration in mesh networks utilizing bandwidth and flow considerations |
| US7804760B2 (en) | 2003-08-07 | 2010-09-28 | Quellan, Inc. | Method and system for signal emulation |
| US7050388B2 (en) | 2003-08-07 | 2006-05-23 | Quellan, Inc. | Method and system for crosstalk cancellation |
| EP1687929B1 (en) | 2003-11-17 | 2010-11-10 | Quellan, Inc. | Method and system for antenna interference cancellation |
| US7616700B2 (en) | 2003-12-22 | 2009-11-10 | Quellan, Inc. | Method and system for slicing a communication signal |
| US7356749B2 (en) * | 2004-02-02 | 2008-04-08 | Lucent Technologies Inc. | Method and apparatus for detecting a three-state signal in a base station in a wireless communications system |
| US20050195739A1 (en) * | 2004-02-23 | 2005-09-08 | Grover Wayne D. | Protecting a network using protected working capacity envelopes |
| US7725079B2 (en) | 2004-12-14 | 2010-05-25 | Quellan, Inc. | Method and system for automatic control in an interference cancellation device |
| US7522883B2 (en) | 2004-12-14 | 2009-04-21 | Quellan, Inc. | Method and system for reducing signal interference |
| US9252983B2 (en) | 2006-04-26 | 2016-02-02 | Intersil Americas LLC | Method and system for reducing radiated emissions from a communications channel |
| EP2119140B1 (en) * | 2007-01-09 | 2015-04-15 | Orange | Method for conveying a data packet through a router in a packet communication network supported by a transport network |
| CN102056336B (en) * | 2009-11-02 | 2013-01-09 | 华为技术有限公司 | Method and device for cooperatively processing self-organizing operation, and communication system |
| FR2954872B1 (en) * | 2009-12-30 | 2012-02-03 | Thales Sa | METHOD FOR ANALYZING THE FAILURES NECESSARY TO MAKE IMPOSSIBLE COMMUNICATION BETWEEN ELEMENTS OF A TELECOMMUNICATIONS NETWORK |
| CN104040974B (en) | 2011-03-29 | 2017-02-22 | 华为技术有限公司 | Apparatus and method for spare capacity allocation on dual link failureS |
| US9602351B2 (en) * | 2014-06-06 | 2017-03-21 | Microsoft Technology Licensing, Llc | Proactive handling of network faults |
| US9887878B2 (en) | 2014-06-06 | 2018-02-06 | Microsoft Technology Licensing, Llc | Dynamic scheduling of network updates |
| US9491054B2 (en) | 2014-06-06 | 2016-11-08 | Microsoft Technology Licensing, Llc | Network-state management service |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA1291549C (en) * | 1987-11-06 | 1991-10-29 | Wayne D. Grover | Method and apparatus for self-healing and self-provisioning networks |
| JPH0624366B2 (en) * | 1988-11-24 | 1994-03-30 | 日本電気株式会社 | Network failure recovery method |
| US5113398A (en) * | 1989-06-01 | 1992-05-12 | Shackleton System Drives Corporation | Self-healing data network and network node controller |
| US4993015A (en) * | 1989-11-06 | 1991-02-12 | At&T Bell Laboratories | Automatic fault recovery in a packet network |
| US4959854A (en) * | 1990-01-26 | 1990-09-25 | Intervoice Inc. | Apparatus and method for automatically reconfiguring telephone network resources |
| US5093824A (en) * | 1990-03-27 | 1992-03-03 | Bell Communications Research, Inc. | Distributed protocol for improving the survivability of telecommunications trunk networks |
| US5222128A (en) * | 1990-07-26 | 1993-06-22 | At&T Bell Laboratories | Telecommunication disaster plan |
| JPH04154242A (en) * | 1990-10-17 | 1992-05-27 | Nec Corp | Network failure recovery system |
| US5146452A (en) * | 1990-10-26 | 1992-09-08 | Alcatel Network Systems, Inc. | Method and apparatus for rapidly restoring a communication network |
| JP3071007B2 (en) * | 1991-10-22 | 2000-07-31 | 富士通株式会社 | Communication network control method |
| US5371744A (en) * | 1992-03-23 | 1994-12-06 | Hughes Aircraft Company | System and method for enumerating all acyclic paths in a processing system for reconfiguration and fault tolerance |
| US5444693A (en) * | 1992-04-27 | 1995-08-22 | At&T Corp. | System for restoration of communications networks |
| US5435003A (en) * | 1993-10-07 | 1995-07-18 | British Telecommunications Public Limited Company | Restoration in communications networks |
| JPH07226736A (en) * | 1994-02-14 | 1995-08-22 | Hitachi Ltd | Fault recovery method in mesh network |
| US5463615A (en) * | 1994-07-07 | 1995-10-31 | At&T Corp. | Node failure restoration tool |
| US5657320A (en) * | 1995-06-06 | 1997-08-12 | Mci Corporation | Method and system for resolving contention of spare capacity circuits of a telecommunications network |
| US5646936A (en) * | 1995-06-22 | 1997-07-08 | Mci Corporation | Knowledge based path set up and spare capacity assignment for distributed network restoration |
| US5590119A (en) * | 1995-08-28 | 1996-12-31 | Mci Communications Corporation | Deterministic selection of an optimal restoration route in a telecommunications network |
-
1995
- 1995-10-31 CA CA002161847A patent/CA2161847A1/en not_active Abandoned
- 1995-11-01 US US08/551,709 patent/US5850505A/en not_active Expired - Lifetime
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0907303A3 (en) * | 1997-10-01 | 2004-12-08 | Nortel Networks Limited | Communication system architecture and operating methods thereof |
| US6917586B1 (en) | 1997-10-01 | 2005-07-12 | Nortel Networks Limited | Communication system architecture and operating methods thereof |
| US9025464B2 (en) | 2002-12-05 | 2015-05-05 | Telecommunications Research Laboratories | Method for design of networks based on p-cycles |
Also Published As
| Publication number | Publication date |
|---|---|
| US5850505A (en) | 1998-12-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5850505A (en) | Method for preconfiguring a network to withstand anticipated failures | |
| US5459716A (en) | Facility restoration for telecommunications networks | |
| Iraschko et al. | Optimal capacity placement for path restoration in STM or ATM mesh-survivable networks | |
| US7787770B2 (en) | Methods for co-modelling and analyzing packet networks operating over optical networks | |
| Alanyali et al. | Provisioning algorithms for WDM optical networks | |
| US6421349B1 (en) | Distributed preconfiguration of spare capacity in closed paths for network restoration | |
| CN1887024B (en) | System and method for the automatic setup of switched circuits based on traffic prediction in a telecommunications network | |
| Iraschko et al. | Optimal capacity placement for path restoration in mesh survivable networks | |
| US6295275B1 (en) | Dynamic route generation for real-time network restoration using pre-plan route generation methodology | |
| JPH05506976A (en) | Distributed protocol for improving fault resiliency of telephone communication networks | |
| US20100080119A1 (en) | Method for restoring connections in a network | |
| CN112653575B (en) | Network configuration method, controller and flow guiding system | |
| US20040220886A1 (en) | Communication signal resource chain assignment for optical networks subject to reach constraints | |
| US6304349B1 (en) | WDM optical communications networks and methods for provisioning | |
| US8774627B2 (en) | Network restoration under link or node failure using preconfigured virtual cycles | |
| Melián et al. | Minimizing the cost of placing and sizing wavelength division multiplexing and optical crossconnect equipment in a telecommunications network | |
| EP1449320B1 (en) | Method for planning or provisioning data transport networks | |
| EP1531633A1 (en) | Method for restoring a connection in a telecommunication network | |
| US20020094798A1 (en) | Forming a communication network | |
| Barezzani et al. | Protection planning in transmission networks | |
| JPH11163878A (en) | Spare route setting method | |
| Izmailov et al. | Flow splitting approach for path provisioning and path protection problems | |
| Veerasamy et al. | Spare capacity assignment in telecom networks using path restoration and further improvement using traffic splitting | |
| Pickavet et al. | AI Techniques for planning telecommunication networks | |
| Tsirakakis et al. | Simulation tools for multilayer fault restoration |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |
Effective date: 20051031 |