Stochastic cross-layer optimization of networks to meet traffic availability goals at the lowest cost

Abstract

The present disclosure relates to network stochastic cross-layer optimization for meeting traffic flow availability goals at minimum cost. Systems and methods for network planning are described. The systems and methods are capable of integrating network traffic requirements, availability requirements, latency, physical infrastructure and networking device capabilities, and detailed cost structures to calculate a network design with minimum or reduced cost compared to conventional methods. In some embodiments, the method includes providing an initial set of deterministic faults, and then continuously performing network optimization and network availability simulation to determine which faults have the greatest impact on the performance of the network model. Highly impactful faults can then be provided back to the system, which generates an improved network design while still maintaining minimum cost.

Description

[0001] Description of the case

[0002] This application is a divisional application of Chinese invention patent application No. 201680034266.5, filed on July 1, 2016.

[0003] CROSS-REFERENCE TO RELATED APPLICATIONS

[0004] This application claims priority to U.S. Patent Application No. 14 / 922,905, filed on October 26, 2015, entitled “NETWORK STOCHASTIC CROSS-LAYER OPTIMIZATION FOR MEETING TRAFFIC FLOW AVAILABILITY TARGET AT MINIMUM COST,” which in turn claims priority to U.S. Provisional Patent Application No. 62 / 190,553, filed on July 9, 2015, entitled “NETWORK STOCHASTIC CROSS-LAYER OPTIMIZATION FOR MEETING TRAFFIC FLOW AVAILABILITY TARGET AT MINIMUM COST,” both of which are assigned to the assignee and are incorporated herein by reference. Technical Field

[0005] The present disclosure relates to network stochastic cross-layer optimization for meeting traffic flow availability objectives at minimum cost. Background Art

[0006] Large-scale networks are designed to meet different service purposes. The network design is optimized individually for each service purpose. Typically, the optimization is done manually based on the user's past experience and judgment, and often results in an over-provisioned network. As the size of the network increases, the over-provisioning of the network represents a significant cost to the network owner. Summary of the invention

[0007] According to one aspect of the present disclosure, a method for designing a network includes generating a minimum monetary cost network model that can meet business requirements. In response to a set of variables that each define one of network cost, physical layer characteristics, or logical layer characteristics, a set of constraints that define a relationship between at least two variables from the set of variables, and a purpose of reducing the monetary cost of the network defined by the minimum monetary cost network model, the minimum monetary cost network is generated. The method also includes generating an optimized network fault set (Fo ). The method further comprises iteratively updating the o The lowest monetary cost network model that can meet business needs under the condition of , until the current lowest monetary cost network under a given random failure set (F R ) to meet the business needs. The minimum monetary cost network is updated in response to the variable set, the constraint set and the purpose of reducing the monetary cost of the network. The method also includes generating a random fault set F R The method also includes determining the minimum monetary cost network model at a given F R In response to determining whether the lowest cost network meets the business requirements under the given F R In the case that the business requirement is not met, the method includes: R Select a subset of faults and remove the subset of faults from F R Add to F o The method further includes determining, in response to the determination of the lowest cost network given F R The current lowest cost network model is output based on the business needs.

[0008] According to another aspect of the present disclosure, a system for designing a network includes a computer-readable medium storing processor-executable instructions and at least one processor. Execution of the processor-executable instructions causes the at least one processor to generate a minimum monetary cost network model that can meet business requirements. In response to a set of variables that each define one of network cost, physical layer characteristics, or logical layer characteristics, a set of constraints that define a relationship between at least two variables from the set of variables, and a purpose of reducing the monetary cost of the network defined by the minimum monetary cost network model, the minimum monetary cost network is generated. Execution of the processor-executable instructions causes the at least one processor to generate an optimized network fault set F o Execution of the processor executable instructions causes the at least one processor to iteratively update the minimum monetary cost network model until the current minimum monetary cost network is within a given random fault set F R The minimum monetary cost network model meets the business needs under the given F o The execution of the processor executable instructions causes the at least one processor to generate a random fault set F R And determine the minimum monetary cost network model at a given F R In response to determining whether the lowest cost network meets the business requirements under the given F RIn the case where the business requirements are not met, the execution of the processor executable instructions causes the at least one processor to R Select a subset of faults and remove the subset of faults from F R Add to F o In response to determining the lowest cost network at a given F R In order to meet the business needs under the circumstances, the execution of the processor executable instructions causes the at least one processor to output the current lowest cost network model.

[0009] According to another aspect of the present disclosure, a computer-readable medium includes instructions for designing a network. Execution of the instructions causes a processor to generate a minimum monetary cost network model that can meet business requirements. In response to a set of variables that each define one of network cost, physical layer characteristics, or logical layer characteristics, a set of constraints that define a relationship between at least two variables from the set of variables, and a purpose of reducing the monetary cost of the network defined by the minimum monetary cost network model, the minimum monetary cost network is generated. Execution of the processor-executable instructions causes the processor to generate an optimized network fault set F o Execution of the processor executable instructions causes the processor to iteratively update the minimum monetary cost network model until the current minimum monetary cost network is within a given random fault set F R The minimum monetary cost network model meets the business needs under the given F o The execution of the processor executable instructions causes the processor to generate a random fault set F R And determine the minimum monetary cost network model at a given F R In response to determining whether the lowest cost network meets the business requirements under the given F R In the case that the business requirement is not met, the execution of the processor executable instruction causes the processor to R Select a subset of faults and remove the subset of faults from F R Add to F o In response to determining the lowest cost network at a given F R In order to meet the business needs under the condition that the processor can execute the instructions, the processor outputs the current lowest cost network model.

[0010] The above general description and the following description of the drawings and the detailed text description are exemplary and explanatory, and are intended to provide further explanation of the aspects as claimed. From the following brief description of the drawings and the detailed description of the invention, other objects, advantages and novel features will be apparent to those skilled in the art. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Those skilled in the art will appreciate that the drawings described herein are for illustrative purposes only. It is to be understood that in some instances, various aspects of the described embodiments may be shown in an exaggerated or enlarged manner to facilitate understanding of the described embodiments. In the figures, the same reference numerals generally refer to the same features, functionally similar or structurally similar elements in the various figures. The drawings are not necessarily drawn to scale, but rather emphasize the illustration of the principles of the teachings. The drawings are not intended to limit the scope of the present teachings in any way. The systems and methods can be better understood by reference to the illustrative description of the following drawings, in which:

[0012] Figure 1A A block diagram illustrating an example physical topology of a network.

[0013] Figure 1B The diagram shows Figure 1A Block diagram of an example logical topology implemented on the physical topology of the network shown.

[0014] Figure 2 A block diagram of an example network manager is illustrated.

[0015] Figure 3 Illustration for use Figure 2 A flowchart of an example method for an example network manager to design a network is shown. DETAILED DESCRIPTION

[0016] The various concepts introduced above and discussed in more detail below can be implemented in any number of ways, as the concepts described are not limited to any particular manner of implementation. Specific implementations and examples of applications are provided primarily for illustrative purposes.

[0017] The present disclosure describes systems and methods for network planning. The systems and methods are capable of integrating network business requirements, availability requirements, latency, physical infrastructure and networking device capabilities, and detailed cost structures to calculate a network design with the lowest or reduced cost compared to conventional methods. In some embodiments, the method includes providing an initial set of deterministic faults, and then continuously performing network optimization and network availability simulation to determine which faults have the greatest impact on the performance of the network model. Faults with high impact can then be provided back to the system, which generates an improved network model while reducing network costs.

[0018] Figure 1AA block diagram of an example physical topology of an example network 100 is illustrated. Network 100 includes upper layer nodes 102(1)-102(3) (collectively referred to as upper layer nodes 102) and lower layer nodes 106(1)-106(3) (collectively referred to as lower layer nodes 106). Upper layer node 102 is coupled to lower layer node 106 via switches 104(1) and 104(2) (collectively referred to as switches 104). Upper layer node 102 and lower layer node 106 are coupled to switch 104 via physical links 108.

[0019] In some embodiments, the switches 104 are wavelength selective switches or other types of switches, such as optical circuit switches (OCS). Each switch 104 includes a plurality of north ports to which the high-level nodes 102 are coupled and a plurality of south ports to which the low-level nodes 106 are coupled. The interconnection of the north ports and the south ports within the switch 104 is configurable, and the interconnection of the north ports and the south ports determines how the high-level and low-level nodes are interconnected. In some embodiments, the physical topology is referred to as an L1 topology, which refers to the first level in the open system interconnection (OSI) stack.

[0020] Figure 1B A block diagram of an example logical topology 150 implemented on the physical topology of the network 100 is illustrated. The logical topology 150 determines how the high-level nodes 102 communicate with the low-level nodes 106 across the network 100 created by the switches 104. For example, one of the switches 104 couples the high-level node 102(1) to the low-level node 106(1), and the other switches 104 couple the high-level node 102(1) to the low-level node 106(3). Logical links 112 form connections between the high-level nodes 102 and the low-level nodes 106 within the logical topology 150. The mapping between the physical topology of the network 100 and the logical topology 150 may be referred to as a cross-layer network topology. In some embodiments, the logical topology is referred to as an L3 topology, which refers to the third level in the Open Systems Interconnection (OSI) stack.

[0021] Figure 2 A block diagram of an example network manager 200 is illustrated. The network manager 200 includes a cross-layer topology manager 202 configured to generate a cross-layer mapping between a physical topology of a network and a logical topology of the network. The network manager 200 also includes a fault generator 204 configured to generate random faults for each link in the physical topology. The network manager 200 includes a traffic engineering (TE) simulator 206 that receives data generated or received by the cross-layer topology manager 202 and the fault generator, and calculates whether the network defined by the L1 and L3 topology models can meet business requirements.

[0022] The network manager 200 is implemented by a dedicated logic circuit (e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit)) and / or a general-purpose computing device. In addition to hardware, the network manager 200 may also include code stored on a computer-readable medium, which, when executed, causes the network manager 200 to perform one or more methods described herein.

[0023] The fault generator 204 of the network manager 200 generates a combination of possible faults that may occur in the network. Each possible fault may be referred to as a fault sample and includes a fault of one or more links and other network devices in the physical network. In some embodiments, the fault generator 204 receives past fault data, such as the probability that a link or network device will fail at a specified time. In some embodiments, the possible faults generated by the fault generator 204 are the faults that are most likely to occur in the network based on past fault data. In other embodiments, the fault generator 204 is capable of receiving user instructions for generating possible faults. For example, a user may wish to run a "what-if analysis" to determine the consequences in the event of a specific fault. In these cases, the user can indicate to the fault generator 204 which links and network devices will fail and how they will fail.

[0024] The TE simulator 206 of the network manager 200 is a traffic engineering simulator that receives data from the cross-layer topology manager 202, the fault generator 204, and other sources to calculate which requirements across the logical layer model are met and which are not met.

[0025] As an overview, the cross-layer topology manager 202 of the network manager 200 is configured to generate a physical topology model, a logical topology model, and a cross-layer topology, which is a mapping between the logical and physical layers of the network. In some embodiments, generating a physical topology model, a logical topology model, and a cross-layer topology is referred to as a "computing network." The cross-layer topology manager 202 is configured to calculate a network that reduces the overall cost of the network but enables the network to meet availability, latency, and bandwidth requirements. In some embodiments, the cross-layer topology manager 202 includes a mixed integer linear problem solver for calculating a network with reduced costs that meets multiple constraints. In some embodiments, linear problems are not as computationally complex as mixed integer linear problems, and the cross-layer topology manager 202 approximates the results of mixed integer linear problems by solving the linear problem and rounding the results up to the nearest integer. For example, a network design with a small number of hardware components can be obtained using a linear problem. As an example, the cross-layer topology manager 202 can design a network comprising 129.4 racks. The cross-layer topology manager 202 then rounds the results up so that they can be physically implemented - for example, 129.4 racks will be implemented as 130 racks.

[0026] When calculating the network, the cross-layer topology manager 202 receives topology data, capacity data, delay data, equipment data, availability data, or a combination thereof as constraints. For example, when developing a network model that reduces overall costs, the cross-layer topology manager 202 receives information about the physical structure of the network. Information about the physical layer may include whether the optical fiber is owned or rented from other providers. Leased and owned optical fibers are considered separately when generating a cross-layer topology with reduced costs because owned optical fibers include additional costs compared to leased optical fibers, such as the cost of installing and maintaining optical fibers. The cost of maintaining optical fibers may also include the cost of additional equipment such as racks, chassis, optical commons, line cards, online amplifiers, etc. required for operating optical fibers, and may also include electrical costs. The cross-layer topology manager 202 also generates a set of faults from the fault generator 204 before calculating the network model. In some embodiments, faults are generated based on existing fault strategies for the network. In other embodiments, faults are generated by network simulation that takes into account the probability of failure.

[0027] The cross-layer topology manager 202 generates a linear programming model based on a list of variables and constraints provided to the cross-layer topology manager 202. The cross-layer topology manager 202 solves the linear programming model given the list of variables and constraints with the goal of reducing or minimizing the monetary cost of the network. The set of variables includes variables that define network costs, physical layer characteristics, or logical layer characteristics. Example network cost variables may include the cost of purchasing a rack or the cost of transmitting data over leased optical fiber. Example physical layer characteristic variables may include the number of ports a physical router has, while example logical layer variables may include the capacity of a logical link. The list of variables that can be implemented into the integer linear programming model by the cross-layer topology manager 202 of the network manager 200 includes: a Boolean variable for each owned optical fiber indicating whether the owned optical fiber is active; a Boolean variable for each L1 node indicating whether the L1 node is from a predetermined manufacturer; a non-negative integer variable associated with each corresponding manufacturer indicating the number of chassis at each L1 node provided by the corresponding manufacturer; a non-negative integer variable for each L1 node indicating the number of racks at the L1 node of a predetermined manufacturer; a Boolean variable for each L1 node indicating whether the L1 node includes an optical sharer of a predetermined manufacturer; a non-negative integer variable for each L1 node indicating the number of racks at the L1 node of a predetermined manufacturer a non-negative integer variable indicating the number of line cards for the add / drop paths; a Boolean variable for each L1 node indicating whether a sublink is regenerated at the L1 node of a predetermined manufacturer; a non-negative integer variable for each L1 node indicating the number of line cards used for regeneration at the L1 node of a predetermined manufacturer; a non-negative integer variable for each sublink indicating the number of leased optical fibers used by the sublink; a non-negative integer variable for each sublink indicating the number of ports occupied by the sublink on the L3 node; a Boolean variable for each link indicating whether the sublink is used; a non-negative continuous variable indicating the link capacity; a non-negative continuous variable for each sublink indicating the sublink capacity; a non-negative continuous variable indicating the traffic volume; and any combination thereof.

[0028] The constraints define a relationship between at least two of the variables described above. The list of constraints that the cross-layer topology manager 202 of the network manager 200 can implement into an integer linear programming model includes: if a sublink is used, the corresponding link is considered to be used as well; if a node is not a reconfigurable optical add / drop multiplexer (ROADM) and a link is already used, the node is an intermediate line amplifier (ILA); if a node is a ROADM, all of its links have optical cooperators; if a node has a degree greater than 3, the node is a ROADM; if a link requires an add / drop at an L1 node, the number of line cards with an add / drop is greater than or equal to the capacity of the link divided by the bandwidth of a single line card; a link is considered to be used if the link includes a positive number of leased fibers or line cards; add, drop, and regeneration occur at a multiplexer or demultiplexer (e.g., ROADM); regeneration is required when a fiber link exceeds the fiber reach; if a sublink is regenerated at an L1 node, the number of line cards required to implement the sublink is greater than or equal to the capacity of the sublink divided by the bandwidth of a single line card; the capacity of the route divided by the bandwidth capacity of each line card; each line card and optical multiplexer is required to be in a chassis and each chassis accommodates a predetermined number of line cards or optical multiplexers; at least one rack is required for each degree of each optical multiplexer; each chassis is required to be in a rack and each rack accommodates a predetermined number of chassis; each router must have more (or at least the same number of) ports than the physical links connected to it; each node in the physical layer must have more (or at least the same number of) ports than the physical links connected to it; the capacity of each link is limited by the sum of the capacities of the sub-links of the link; the number of leased fibers has a capacity equal to or greater than the sum of the capacities of the sub-links passing through the leased fibers; for each failure, the flow through the link is less than the capacity of the link; for each failure, each flow and each node, except for the source and sink of the flow, the incoming flow of the node is equal to the outgoing flow of the node, where the difference between the incoming flow and the outgoing flow is equal to the (negative) demand; or any combination thereof.

[0029] Using the above constraints and variables, the cross-layer topology manager 202 is able to calculate a network model that reduces the cost of implementing the network by solving a linear program that minimizes the cost provided by an equation that adds together the total cost of operating each optical fiber in operation, the total cost of each ILA L1 node, the total cost of each of the multiple required racks, the total cost of the optical multiplexer, the total cost of the line cards required for add / drop, twice the total cost of the line cards required for regeneration, the total cost of data transmission over leased lines, and the cost of routers used to provide ports for each physical link.

[0030] Programmatically, the objectives described above provided to the cross-layer topology manager 202 may be input as:

[0031] sum{fiber}FiberLightingCost(fiber)*islitvar(fiber)

[0032] +sum{l1node,vendor}ILACost*isilavar(l1node,vendor)

[0033] +sum{l1node,vendor}ChassisCost(vendor)*numchassisvar(l1node,vendor)

[0034] +sum{l1node,vendor}RackCost(vendor)*numracksvar(l1node,vendor)

[0035] +sum{fiber,l1node,vendor}OpticalCommonsCost(vendor)*hasopticalcommonsvar_(fiber,l1node,vendor)

[0036] +sum{link,l1node,vendor}LineCardForAddDropCost(vendor)*numlinecardsadddropvar_(link,l1node,vendor)

[0037] +sum{sublink,l1node,vendor}2*LineCardForRegenCost(vendor)*numlinecardsregenonesidevar(sublink,l1node,vendor)

[0038] +sum{sublink,leasedwave}LeasedWaveCost(leasedwave)*numleasedwavesvar(sublink,leasedwave)

[0039] +sum{sublink,l3node}PortCost(l3node)*numportsvar(sublink,l3node)

[0040] In some embodiments, to improve the scalability of the methods described herein, the cross-layer topology manager 202 can approximate the variables and constraints described above or include additional constraints and restrictions on the variables described above. For example, when generating L1 paths, the cross-layer topology manager 202 can reduce the number of paths considered by using a shortest path algorithm that includes iteratively removing edges of the calculated paths and then recalculating the paths with the edges removed. In other embodiments, the number of paths considered is reduced by not considering paths above a predetermined threshold.

[0041] In some embodiments, to improve scalability, the cross-layer topology manager 202 assumes that each sub-link of a link has the same path. Since the sub-links are assumed to have the same path, a failure affecting the link results in a total failure of each sub-link. In other embodiments, the sub-links of a link have different paths, which enables the link to operate at a reduced capacity when a failure occurs in a physical link that supports a portion of the sub-links of the link. In these embodiments, the cross-layer topology manager 202 also includes a constraint that the delay between sub-links following different paths is below a predetermined threshold.

[0042] In some embodiments, the number of links is constrained. A pair of nodes can be linked by multiple links, and each of the multiple links can be implemented by multiple different sub-links. In a physical environment, the number of links that can couple two nodes together may be limited due to maintenance, configuration, or space considerations. In order to take these physical factors into account, in some embodiments, the number of parallel links between node pairs is limited by constraints.

[0043] In some embodiments, geographic constraints are added. The geographic constraints reduce the number of possible fiber paths through the network by limiting the links included in the calculation for a portion of the network. In subsequent calculations performed by the cross-layer topology manager 202, the remaining portion of the network is analyzed.

[0044] In some embodiments, each fault, flow, link, and direction of the network is associated with a variable. To reduce the number of variables, in some embodiments, parallel physical links between pairs of nodes are grouped together as a single "megalink."

[0045] In some embodiments, additional constraints are imposed on the physical links traveling in parallel between node pairs. For example, a constraint that the delay of the auxiliary path is greater than the delay of the main path can be set for the main path and the auxiliary path. The additional constraints for parallel links can include the constraint that there is no path in the network whose delay is greater than the delay of the main path and less than the delay of the auxiliary path. In some embodiments, constraints are added that the traffic flowing through the network is only routed along a limited number of paths and that the traffic is evenly divided along the limited number of paths.

[0046] In some embodiments, flows are latency sensitive, and latency-based constraints are incorporated into the linear program solved by the cross-layer topology manager 202. For example, latency-based constraints can limit the average latency of flows through the network. In some embodiments, the number of variables is reduced by removing paths that include significant detours that result in significant latency. In some embodiments, flows are routed along one of a predetermined number of paths. In these embodiments, possible paths that are not one of the predetermined number of paths are discarded to reduce the number of variables in the linear program.

[0047] In some embodiments, the cross-layer topology manager 202 reduces the computational complexity of the calculated linear program by removing faults from the computation dominated by other faults. For example, a first fault is dominated by a second fault if the first fault only affects a portion of the links affected by the second fault and the second fault causes a greater amount of network capacity loss. In these embodiments, the first fault is not included in the network optimization performed by the cross-layer topology manager 202.

[0048] In some embodiments, the computational efficiency of the cross-layer topology manager 202 is improved by decomposing single-source, multi-destination flows into single-source, single-destination flows. After the flows are decomposed, the decomposed flows with the same destination are subsequently merged. If the network has N nodes and there are flows from each node to each other node (full mesh), the decomposition process reduces the total number of variables by (N-1). The flows can be decomposed by starting at a destination node with a negative outgoing flow and moving backward along the path from the destination to a single source. The minimum flow along the backward path is selected. The single-source, multi-destination flows along the path are reduced to the selected minimum flow, which results in at least one link no longer carrying a flow. The process is repeated until each single-source, multi-destination flow is completely decomposed.

[0049] In some embodiments, the computational efficiency of the cross-layer topology manager 202 is improved by integrating small, long flows into a sequence of larger, shorter flows. For example, consider a network including a short, large flow (e.g., 100 flow units) from node A to node B, a short, large flow from node B to node C, and a long, small flow (e.g., 1 flow unit) from node A to node C. The computational complexity is reduced by modeling the three flows as a first flow from node A to node B having 101 flow units and a second flow from node B to node C having 101 flow units.

[0050] Figure 3 1 is a flow chart of an example method 300 for designing a network. The method 300 includes generating an initial network model that can meet a given set of business requirements (step 302). The method 300 includes generating an optimized fault set (F o ) (Step 304). Calculate the value that satisfies the given F o The lowest monetary cost network (step 306). Generate a random fault set (F R )(Step 308). The method 300 includes determining the lowest monetary cost network at a given F R If the minimum monetary cost network cannot meet the given F R In the case of business needs, method 300 is from F R High impact faults are selected from F (step 312). The high impact faults are added to F o (Step 314), and then the method repeats steps 306-310 until the lowest monetary cost network meets the business requirements given the new set of random failures generated for each iteration of steps 306-310.

[0051] As given above, method 300 includes generating an initial network model to meet a given set of business requirements (step 302). In some embodiments, generating the initial network model includes generating a model of a physical topology, a logical topology, and a cross-layer topology that maps the logical topology to the physical topology. The network model is generated to meet the business requirements when the network does not experience any type of failure.

[0052] The method includes generating an optimized fault set (F o )(Step 304). In some implementations, the optimized fault set (F o ) indicates a random selection of failures in the physical network that are used to design the network model, such as one or more physical link failures.

[0053] Next and also refer to Figure 2, calculate a new minimum monetary cost network (step 306). The minimum monetary cost network is calculated by optimizing the fault set (F o ) is provided to the cross-layer topology manager 202 for calculation. The cross-layer topology manager 202 also receives a set of business requirements. Figure 2 As described, the cross-layer topology manager 202 receives or generates values ​​for multiple variables and constraints or their components used to describe the network. In response to the fault set, the cross-layer topology manager 202 calculates a network model so that the network model can meet the business requirements provided while experiencing each fault in the optimized fault set. The calculated network model is calculated to reduce or minimize the monetary cost of implementing the network. The calculated network model is called the minimum monetary cost network model. The minimum monetary cost network is calculated by solving the minimum monetary cost given the numerical values ​​of multiple variables and constraints by a linear programming solver. In some embodiments, the minimum monetary cost network is not actually the absolute minimum cost network that may be identified given unlimited time and computing resources. Instead, the minimum monetary cost network can be the minimum cost network identified under the condition of a given number of computing resources, a specific computing algorithm, and the amount of time allocated to identify the optimal computing network given the requirements, variables and constraints discussed above.

[0054] The method 300 also includes generating a random fault set (F R )(Step 308). In some embodiments, the additional faults include a random selection of possible physical network faults. In other embodiments, the network manager 200 receives probabilistic fault data or past fault data and generates additional faults in response to the received fault data. For example, an independent probability function can be used to generate possible faults based on the received fault probability data.

[0055] Next, method 300 includes determining that the lowest monetary cost network experiences a random set of failures (F R ) to determine whether the business requirements are met for each failure in the process (step 310).

[0056] If the flow does not meet the required availability, the method 300 includes selecting a random failure set (F R) selects the fault that has the highest impact on the availability of the flow (step 312). In some embodiments, the "impact" metric of each random fault is calculated by multiplying the probability of the corresponding fault by the number of flows that are unavailable due to the fault. In other embodiments, other functions can be used to calculate the impact metric. For example, the impact metric can take into account a partial reduction in flow availability rather than considering availability as a binary analysis. In some embodiments, a fault impact threshold is provided, and faults with an impact metric above the threshold are selected. In some embodiments, all additional faults are selected. In some embodiments, additional parameters such as business requirements are provided back to the cross-layer topology manager 202 to update the minimum cost network model. For example, business requirements that cannot be met by the model can be provided back to the cross-layer topology manager 202 for use in updating the minimum cost network model.

[0057] The method 300 also includes selecting from a random fault set (F R ) to the optimized fault set (F o )(Step 314). In some embodiments, the added fault becomes a constraint that forces flows that are unavailable due to the additional fault to be available in the new lowest monetary cost network calculated by the cross-layer topology manager 202. The method 300 then repeats steps 306-310 until the updated F o The generated lowest monetary cost network experiences F R To meet business needs, the new F R In some embodiments, the method includes for each iteration of the plurality of randomly generated fault sets F R0 -F RN The lowest cost network is tested, and high-impact faults are selected from each set. In some embodiments, the method requires the lowest cost network to meet the business requirements in response to multiple randomly generated faults before ending the iteration. For example, in some embodiments, if the current lowest cost network cannot meet the first randomly generated fault set, the current iteration ends immediately, and the iterative process will not stop until the lowest cost network meets, for example, three randomly generated fault sets.

[0058] In some embodiments, as described above, the fault set is selected outside of the calculation of the lowest cost network. For example, the method 300 is initially provided with a fixed fault set that is updated after each simulation finds a fault that the network model cannot support.

[0059] In other embodiments, the set of faults is selected during the calculation of the lowest cost network - this provides a closed loop method for calculating the lowest monetary cost network model. In these embodiments, the cross-layer topology manager 202 is initially provided with a set of faults for calculating the lowest cost network model, a probability of occurrence of each fault in the set of faults, and a target availability of each of a plurality of flows. Each fault in the set of faults is randomly generated, for example, treating the occurrence of each fault as an independent random variable. The cross-layer topology manager 202 then generates the lowest monetary cost network model such that the probability of each of a plurality of flows being satisfied under all faults in the set of faults is greater than the corresponding target availability of each of the plurality of flows. For example, if a flow has a target availability of 95%, then the network model is generated such that the flow is available during faults whose probabilities sum to at least 95%. Note that the cross-layer topology does not require modifications to the network to ensure the availability of all flows in all sets of faults, but only to ensure a sufficient number of sets of faults to meet the predetermined target availability of each flow. Next, the computation of the minimum cost network is modeled as a two-stage random integer program, where the first-stage decisions are long-term capacity planning decisions (e.g., capacity of links, L3 / L1 mapping, fiber lighting, hardware deployment), while the second-stage decisions are real-time decisions for flow routing during each failure scenario. Chance constraints are then used to force flow requirements to be satisfied under a subset of failures in the set of failures, where the probability of the flow being satisfied under the subset of failures is greater than or equal to the target availability.

[0060] In some embodiments, when link and node failures occur, it may take several minutes to generate a new end-to-end path. However, locally repairing a portion of a link can be accomplished by rerouting the portion of the path over an alternate tunnel that bypasses the failed link or node. Locally repairing the portion of the path can be performed faster (e.g., in a time frame of less than 50 milliseconds) than generating a new end-to-end path.

[0061] When a link or node failure occurs, nodes adjacent to the failure can begin forwarding traffic over an alternate path, which is expected to have the bandwidth required to support the new traffic. In some embodiments, the alternate path is a local alternate path, which is the shortest path (or substantially the shortest path) around the failure. The local alternate path provides a relatively faster repair (e.g., within a time frame of less than 50 milliseconds) than generating a new end-to-end path.

[0062] In some embodiments, the backup path is integrated into the minimum cost network model. The amount of additional bandwidth added to the minimum cost network to support the backup path is called the rerouting tax. The integration of the backup path into the minimum cost network model begins with the generation of the minimum cost network as described above with respect to method 300. In some embodiments, a backup path is identified for each possible network failure in the minimum cost network. In some other embodiments, the backup path is identified only for a subset of possible network failures. If the backup path cannot support its normal business and rerouting business, the amount of additional bandwidth required along the backup path is calculated and the additional bandwidth is added to the backup path in the minimum cost network model. Summing the additional bandwidth required for each calculated failure provides the rerouting tax of the network. In some embodiments, backup paths are generated only for paths that carry high priority business, such as business with high availability requirements.

[0063] In some embodiments, the method 300 described above can provide multiple lowest cost networks. For example, the method 300 can be run multiple times, and during each run a different set of random failures can be provided at step 308, which will cause the method 300 to generate a different lowest cost network model. In these embodiments, a final lowest cost network can be selected from the multiple lowest cost networks generated by the multiple runs by determining which lowest cost network has the lowest cost when the rerouting tax is integrated into the total cost of the network. For example, a first lowest cost network may have a cost X that is slightly lower than a cost Y of a second lowest cost network; however, the rerouting tax T of the first lowest cost network is slightly lower than the cost Y of the second lowest cost network; however, the rerouting tax T of the first lowest cost network is slightly lower than the cost Y of the second lowest cost network; 1 The rerouting tax T can be significantly higher than the second lowest cost network 2 In this example, the second lowest cost network may be selected for implementation because the total cost of the second lowest cost network (Y+T 2 ) is lower than the total cost of the first lowest cost network (X+T 1 ).

[0064] The subject matter and operations described in this specification can be implemented in digital electronic circuits, or in computer software, firmware or hardware (including the structures disclosed in this specification and their structural equivalents), or in a combination of one or more of them. The embodiments of the subject matter disclosed in this specification can be implemented as one or more computer programs, such as one or more computer program instruction modules encoded on one or more computer storage media to be executed by a data processing device or to control its operation.

[0065] A computer readable medium can be, or be included in, a computer readable storage device, a computer readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. In addition, although a computer readable medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium can also be, or be included in, one or more separate components or media (e.g., multiple CDs, discs, or other storage devices). Therefore, a computer storage medium can be tangible and non-transient.

[0066] The operations described in this specification can be performed by a data processing device on data stored on one or more computer-readable storage devices or received from other sources. The term "data processing device" or "computing device" includes all types of devices, equipment and machines for processing data, such as programmable processors, computers, systems on chips or multiple processors, or a combination of the foregoing. The device may include a dedicated logic circuit, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, the device may also include code that creates an execution environment for the computer program in question, such as code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform operating environment, a virtual machine, or a combination of one or more of them. The device and the execution environment can implement a variety of different computing model architectures, such as web services, distributed computing, and grid computing architectures.

[0067] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may correspond to a file in a file system, but need not be so. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple collaborative files (e.g., files storing one or more modules, subroutines, or code portions). A computer program can be deployed to execute on a single computer or on multiple computers located in one location or distributed across multiple locations and interconnected by a communication network.

[0068] As an example, processors suitable for executing computer programs include general and special purpose microprocessors, and any one or more processors of any type of computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic components of a computer are a central processing unit for executing instructions and one or more memories for storing instructions and data. Typically, a computer will also include one or more large storage devices for storing data, or the computer may be operably coupled to receive data from or transmit data to the large storage device, or both, such as a magnetic, magneto-optical disk, or an optical disk. However, a computer need not have such a device.

[0069] Although this specification contains many specific implementation details, these should not be understood as limiting the scope of any invention and the content claimed for protection, but as a description of the features of a particular embodiment specific to a particular invention. Certain features described in this specification in the context of a single embodiment can also be implemented in a single embodiment in combination. On the contrary, various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any appropriate sub-combination. In addition, although features may be described above as working in a certain combination and even initially required to be so, one or more features from the claimed combination may be separated from the combination in some cases, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0070] Similarly, although the operation is depicted in a particular order in the figures, this should not be understood as requiring such operation to be performed in the particular order shown or in a continuous order, or all illustrated operations will be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of the various system components in the above described embodiment should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems are usually integrated together in a single product or are packaged in multiple products.

[0071] Thus, specific implementations of the subject matter have been described. Other implementations are within the scope of the following claims. For example, the actions referenced in the claims can be performed in a different order and still achieve the desired results. As an example, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In some implementations, multitasking and parallel processing may be advantageous.

Claims

1. A method for designing a network, the method comprising: Receive optimized network fault set F o 、F o The probability of occurrence of each failure in and the target availability of each flow in the multiple flows, wherein the optimized network failure set F o indicates a random selection of faults in the physical network that are used to design the lowest cost network model; generating a minimum monetary cost network model capable of meeting business needs in response to the long-term capacity requirements of the minimum cost network model; Until F o Until the probability that each of the plurality of flows is satisfied under each failure in is greater than the corresponding target availability of each of the plurality of flows, iteratively perform the following operations: In response to a given F o updating the minimum monetary cost network model based on the short-term capacity requirements of the minimum cost network model for each failure in the network; as well as Calculated in F o The probability that each of the multiple flows is satisfied under each failure in .

2. The method according to claim 1, further comprising: The minimum monetary cost network model is generated and updated using linear programming.

3. The method according to claim 1, further comprising: The minimum monetary cost network model is generated and updated using mixed integer linear programming.

4. The method according to claim 1, further comprising: An impact measure is determined for each fault.

5. The method according to claim 4, wherein: Each fault in the subset of faults has an impact metric above a predetermined threshold.

6. The method according to claim 1, further comprising: Update the minimum monetary cost network model to o Meet additional business requirements set in the case.

7. The method according to claim 1, further comprising: Given a set of network faults F t Identify local backup paths for each business requirement in the case of as well as The minimum monetary cost network model that can satisfy the service demands when the service demands traverse their corresponding local backup paths is updated.

8. A system for designing a network, comprising a computer readable medium storing processor executable instructions and at least one processor, wherein execution of the processor executable instructions causes the at least one processor to: Receive optimized network fault set F o 、F o The probability of occurrence of each failure in and the target availability of each flow in the multiple flows, wherein the optimized network failure set F o indicates a random selection of faults in the physical network that are used to design the lowest cost network model; generating a minimum monetary cost network model capable of meeting business needs in response to the long-term capacity requirements of the minimum cost network model; Until F o Until the probability that each of the plurality of flows is satisfied under each failure in is greater than the corresponding target availability of each of the plurality of flows, iteratively perform the following operations: In response to a given F o updating the minimum monetary cost network model based on the short-term capacity requirements of the minimum cost network model for each failure in the network; and Calculated in F o The probability that each of the multiple flows is satisfied under each failure in .

9. The system according to claim 8, wherein: Execution of the processor-executable instructions further causes the at least one processor to: generate and update the minimum monetary cost network model using linear programming.

10. The system according to claim 8, wherein: Execution of the processor-executable instructions further causes the at least one processor to: generate and update the minimum monetary cost network model using mixed integer linear programming.

11. The system according to claim 8, wherein: Execution of the processor-executable instructions further causes the at least one processor to: determine an impact metric for each fault.

12. The system according to claim 11, wherein: Each fault in the subset of faults has an impact metric above a predetermined threshold.

13. The system according to claim 8, wherein: Execution of the processor executable instructions further causes the at least one processor to: update the minimum monetary cost network model to o Meet additional business requirements set in the case.

14. The system according to claim 13, wherein: Execution of the processor-executable instructions further causes the at least one processor to: Given a set of network faults F t Identify local backup paths for each service requirement in the case of The minimum monetary cost network model that can satisfy the service demands when the service demands traverse their corresponding local backup paths is updated.

15. A computer readable medium having stored thereon processor executable instructions, wherein execution of the processor executable instructions causes a processor to: Receive optimized network fault set F o 、F o The probability of occurrence of each failure in and the target availability of each flow in the multiple flows, wherein the optimized network failure set F o indicates a random selection of faults in the physical network that are used to design the lowest cost network model; generating a minimum monetary cost network model capable of meeting business needs in response to the long-term capacity requirements of the minimum cost network model; Until F o Until the probability that each of the plurality of flows is satisfied under each failure in is greater than the corresponding target availability of each of the plurality of flows, iteratively perform the following operations: In response to a given F o updating the minimum monetary cost network model based on the short-term capacity requirements of the minimum cost network model for each failure in the network; and Calculated in F o The probability that each of the multiple flows is satisfied under each failure in .

16. The computer-readable medium of claim 15, wherein: Execution of the processor-executable instructions further causes the processor to: generate and update the minimum monetary cost network model using linear programming.

17. The computer-readable medium of claim 15, wherein: Execution of the processor-executable instructions further causes the processor to: generate and update the minimum monetary cost network model using mixed integer linear programming.

18. The computer-readable medium of claim 15, wherein: Execution of the processor-executable instructions further causes the processor to: determine an impact metric for each fault.

19. The computer-readable medium of claim 18, wherein: Each fault in the subset of faults has an impact metric above a predetermined threshold.

20. The computer-readable medium of claim 15, wherein: Execution of the processor executable instructions further causes the processor to: update the minimum monetary cost network model to o Meet additional business requirements set in the case.

Images