public class Offline_ipOverWdm_routingSpectrumAndModulationAssignmentILPNotGrooming extends Object implements com.net2plan.interfaces.networkDesign.IAlgorithm
The input design is assumed to have a WDM layer compatible with
library usual assumptions:
Each lightpath produced by the design is returned as a
Route object. Protection lightpaths in 1+1 case
are returned as ProtectionSegment objects attached to the
Route. They represent a set of reserved frequency slots in
a set of fibers, to be used to protect other lightpaths.
Each lightpath starts and ends in a transponder. The user is able to define a set of available transpoder types, so the design can create lightpaths using any combination of them. The information user-defined per transponder is:
In addition, the user can force the design to use bidirectional transponders (the usual case). This means that (i) in each transponder we have the transmission and reception side inseparable (so you cannot e.g. buy just the transmission side), and (ii) a couple of transponders (of course of the same type) being the end points of a lightpath from node 1 to node 2, also are used for a lightpath from node 2 to node 1, (iii) note however that the two opposite lightpaths can follow arbitrary routes (they do not have to traverse the reversed sequence of nodes). This bidirectionality constraint is a common requirement if the lightpath will be used for carrying IP traffic, since IP assumes that its links (the lightpaths) are bidirectional pipes.
We assume that all the fibers use the same wavelength grid, composed of a user-defined number of frequency slots. The user can also select a limit in the maximum propagation delay of a lightpath.
The output design consists in the set of lightpaths to establish, in the 1+1 case also with a 1+1 lightpath each.
Each lightpath is characterized by the transponder type used (which sets its line rate and number of occupied slots in the
traversed fibers), the particular set of contiguous frequency slots occupied, and the set of signal regeneration points (if any).
This information is stored in the
ProtectionSegment object using the regular methods in WDMUTils,
and can be retrieved in the same form (e.g. by a report showing the WDM network information).
If a feasible solution is not found (one where all the demands are satisfied with the given constraints), a message is shown.
The user can choose among three possibilities for designing the network:
ProtectionSegmentobject). The backup lightpath uses the same type of transponder as the primary (and thus the same line rate, an occupies the same number of slots), its path is SRG-disjoint, and the particular set of slots occupied can be different.
The user can choose between two optimization targets:
This algorithm is quite general, and fits a number of use cases designing WDM networks, for instance:
The algorithm is based on solving a set of MILPs (Mixed Integer Linear Programs) interfacing from JOM to the user-defined
solver. The algorithm uses a flow-path formulation, where a number of candidate paths are pre-computed for each demand. The
k limits the maximum number of paths computed per demand. In the 1+1 case, the usable SRG-disjoint
path pairs for each demand are computed from the candidate paths. Increasing the number of paths
k also increases
the computational complexity of the algorithm, but can produce better solutions. In some occasions, a low
k number is the
reason for the algorithm failing in finding a feasible solution.
The details of the algorithm will be provided in a publication currently under elaboration.
|Constructor and Description|
|Modifier and Type||Method and Description|
public String executeAlgorithm(com.net2plan.interfaces.networkDesign.NetPlan netPlan, Map<String,String> algorithmParameters, Map<String,String> net2planParameters)
public String getDescription()
public List<com.net2plan.utils.Triple<String,String,String>> getParameters()
Copyright © 2018. All rights reserved.