This guide identifies installation prerequisites, describes how to install Net2Plan, and explains how to run it and extend its functionalities.
Net2Plan is a free and open-source Java tool devoted to the planning, optimization and evaluation of communication networks. It has been originally thought as a tool to assist the teaching of communication networks planning courses. Finally, it has converted into as a (in our opinion) powerfull tool for network planning for the academia and industry.
Net2Plan allows testing several built-in algorithms, or new algorithms that users (i.e. students) can easily implement. This process is facilitated by a set of included libraries. The integration of the user-made algorithms in the tool is straightforward. The algorithms are implemented as Java .class/.jar files with a mandatory format for input and output parameters. Hence, algorithms in this form can be readily integrated into Net2Plan (see Section 5.1.2).
Net2Plan is implemented as a Java library along with both command-line and graphical user interfaces (CLI and GUI, respectively). The GUI is specially useful for laboratory sessions as an educational resource, or for a visual inspection of the network. In its turn, the command-line interface is specifically devoted to in-depth research studies, making use of batch processing or large-scale simulation features. Therefore, Net2Plan is a tool intended for a broad spectrum of users: industry, research, and academia.
Regardless of the interface (CLI or GUI) selected by the user, Net2Plan currently provides five different tools: network design, traffic matrix generation, resilience simulation, connection-admission-control (CAC) simulation, and reporting.
Network design. Assists users in the process of network design and planning. For instance, deciding on the network topology, the traffic routing, the capacities in the links, the bandwidth assigned to each demand, the network protection/restoration schemes... The GUI organizes network information, statistics and performance estimations computed from the network design, related to nodes, links, routes, etc. Also, it is possible to generate automatic built-in or user-made reports, that estimate more in-depth several network aspects (i.e. network robustness respect to multiple failures, network delay or blocking statistics...).
Traffic matrix generation. Assists users in the process of generating user-defined traffic matrices following or not several random models found in the literature. These traffic matrices can serve later to feed the network planning, or network simulation processes.
Resilience simulation. Simulates the network operation, where failures and links and nodes randomly appear according to the user-defined availability information of the network nodes/links. Allows testing built-in or user-made provisioning algorithms, that react to failure/reparation events from an initial network design. Network and service availability results are collected and reported to the user.
Connection-admission-control simulation. Simulates the network operation, where traffic demands are the source of connection requests. This permits testing the performances of built-in or user-defined CAC (Connection-Admission-Control) algorithms, that block the connections or allocate them (deciding their route). For each traffic source, the requested connections duration, reserved capacity and interarrival time can be user-defined following different patterns (also built-in or user-defined). Network performances like connection blocking measures are collected and reported to the user.
Reporting. Net2Plan permits the generation of built-in or user-defined reports, from any network design. The report generation tool is integrated within network design, resilience simulation, connection-admission-control simulation tools, so that it is possible to create reports related to in any of these network aspects.
Net2Plan requires Java Runtime Environment 7 or higher versions and a screen resolution of, at least, 800x600 pixels. Since it is developed in Java, it works in the most well-known operation systems (Microsoft Windows, Linux, Mac OS X).
To install Net2Plan, save the compressed file in any directory. Then, extract all the files and folders into a new directory, for example C:\Work\Net2Plan (in a Windows environment).
To run Net2Plan in GUI mode, just double click on Net2Plan.jar, or execute the following command in a terminal:
java -jar Net2Plan.jarTo run Net2Plan in CLI mode, execute the following command in a terminal:
java -jar Net2Plan-cli.jarThis section describes the directory structure in the toolbox. It has the following folders:
| Directory | Description |
|---|---|
help |
Includes this guide |
javadoc |
Includes the library API Javadoc |
lib |
Includes auxiliary Java libraries required by the kernel |
src |
Includes the kernel code and some example codes |
workspace |
Includes examples: topologies, traffic matrices, algorithms, reports… |
In this section, we provide the theoretical framework that is behind Net2Plan philosophy, and the (common) notation we use to characterize the network, topology, routing etc.
In Net2Plan a network topology is defined as a graph \(G(N,E)\), where \(N\) is the set of nodes and \(E\) is the set of links. The number of nodes and links are the cardinality of sets \(N\) and \(E\), which are \(|N|\) and \(|E|\), respectively. Network topologies are considered as multi-digraphs. This means that every link is unidirectional (directed graph or digraph), and that network topologies can have multiple links between the same node pair. No self-links are allowed.
Given a link \(e \in E\), \(a(e)\) denotes the initial node of the link, and \(b(e)\) denotes its destination node. We use \(l_{e}\) to denote the link length (measured in km). Given a node \(n\), \(d^{+}(n)\) is the set of outgoing links from \(n\) (\(d^{+}(n) = \{e \in E : a(e) = n\}\)) and \(d^{-}(n)\) is the set of incoming links to \(n\) (\(d^{-}(n) = \{e \in E : b(e) = n\}\)). In Fig. 4.1 an example of network topology is shown.
Fig. 4.1. Topology with \(|N|\) = 3 nodes, \(N = \{n_1,n_2,n_3\}\), \(|E|\) = 3, \(E = \{e_1,e_2,e_3\}\). End nodes of \(e_1\) are \(a(e_1) = n_1\) and \(b(e_1) = n_2\). Outgoing links from node \(n_2\) are \(d^{+}(n_2) = \{e_2,e_3\}\), and the incoming one is \(d^{-}(n_2) = {e_1}\)
Each node \(e\) in a network has associated a real number \(u_e\) = 0 which represents its capacity. The capacity is the amount of traffic the link is able to carry. Thus, capacities and traffics are measured in the same units. Unless stated otherwise, the traffic and capacities in Net2Plan are measured in Erlangs.
For the sake of simplicity, we denote the set of link capacities as a vector u = \(\{u_e, e \in E\}\). In addition, the carried traffic by link \(e\) is denoted by \(y_e\). The vector y = \(\{y_e, e \in E\}\) represents the traffic carried in all the links in the network.
Typically link capacities are limited to a discrete range of values due to technological reasons, such as STM-\(N\) carriers in SDH. In these cases, capacities are referred as modular capacities.
Traffic is modelled through a set of demands (or commodities) \(D\). Each demand \(d \in D\) represents an offered traffic flow to the network. In general, the traffic of a demand \(d\) can have one or more ingress nodes in the set \(a(d)\), and one or more egress nodes denoted by the set \(b(d)\); however, in current version of Net2Plan demands are considered unicast. This means that each demand \(d\) has one ingress node and one egress node, thus \(|a(d)|\) = \(|b(d)|\) = 1. In addition, self-demands are not allowed.
The offered traffic by a demand \(d\) is represented as \(h_d\). Such value is measured in the same units as link capacities u (i.e. Erlangs). In some situations, it is not possible to carry all the offered traffic by the demands. Then, \(r_d \leq h_d\) represents the amount of traffic belonging to demand \(d\) that is carried. In their vector form, h = \(\{h_d, d \in D\}\) and r = \(\{r_d, d \in D\}\) represent offered and carried traffic, respectively.
A simplified approach to model the offered traffic between nodes is the so-called traffic matrix. A traffic matrix is a \(|N|\)x\(|N|\) matrix (where \(|N|\) is the number of nodes in the network) in which each pair \((i,j)\) represents the traffic from node \(i\) to node \(j\). The traffic design tool is intented to help users to generate traffic matrices using several random traffic models.
The main drawback of representing the offered traffic by means of traffic matrices, is that the traffic matrix representation assumes that at most one demand exists between each pair of nodes. Then, if we compute the traffic matrix representation of a demand set \(D\) where some node pairs have more than one demand between them, an ambiguity can occur. This situation is posed in Fig. 4.2, where demands 1 and 2 from the demand set on the left are grouped in a single entry in the traffic matrix. The same result is obtained with the demand set on the right.
Fig. 4.2. Ambiguity in traffic matrices
Routing is the process of, for each traffic demand, selecting paths in a network along which to send the traffic. Given a network topology \(G(N,E)\), a path \(p\) is an ordered sequence of links \(p = (e_1,\dots,e_k)\), such that the destination node of a link \(e_i\) is the origin node of the following link \(e_i+1\). The set of all possible paths in a network is denoted as \(P\). The first node of the path \(a(p)\) is the origin node of the first link \(a(e_1)\), and the last node in the path \(b(p)\) is the destination node of the last link \(b(e_k)\). Finally, given a link \(e \in E\), \(P_e\) is the set of paths which traverse the link \(e\). For example in Fig. 3.3, given \(p_1 = \{e_{12},e_{23},e_{34}\}\) and \(p_2 = \{e_{42},e_{23}\}\), \(P_{e_{23}} = \{p_1,p_2\}\). In addition, \(l(p)\) is the number of hops in path \(p\).
Fig. 4.3. Topology with \(|N|\) = 4 nodes, \(N = {n_1,\dots,n_4}\), \(|E|\) = 4, \(E = \{e_{12},e_{23},e_{34},e_{42}\}\)
In Net2Plan, the routing is internally represented in the form of demand-path variables. Formally, for each demand \(d\) in the network, a set of paths \(P_d \subset P\) is defined between the end nodes of the demand (\(a(d) = a(p), b(d) = b(p)\)). Also, given a path \( p \), the demand that the path is linked to is denoted as \( d(p) \). Then, traffic routing is represented by a vector x = \(\{x_{p}, p \in P\}\) where \(x_{p}\) is the traffic volume carried through the path \(p\) for demand \(d(p)\). Note that we define a path \(p \) as a sequence of links that carry traffic of a specific demand \( d (p) \). If two demands exist \( d_1, d_2 \) between the same end nodes, and the traffic of both demands is carried through the same sequence of links, we consider in Net2Plan that the routing is composed of two paths \( p_1, p_2 \) with the same end nodes, one for each demand, so that \(d (p_1 ) = d_1, d(p_2) = d_2 \).
According to the notation used to define the network routing in Net2Plan, the following relations hold:
\[\sum_{p \in P_{d}} x_{p} = r_d \leq h_{d}\ \ \ \ \ \ \forall d \in D\ \ \ \ \ \ \text{the traffic carried by a demand $d$ is the sum of traffics in the paths assigned to that demand}\]
\[\sum_{p \in P_{e}} x_{p} \leq u_{e}\ \ \ \ \ \ \forall e \in E\ \ \ \ \ \ \text{the traffic in a link is the sum of the traffic in the paths traversing that link, and is constrained (in general) to be limited by the link capacity}\]
Next, two typical routing constraints are described:
Unsplittable or non-bifurcated routing: If the routing is non-bifurcated, each traffic demand is carried by at most one path. Conversely, if a demand \(d\) is carried by more than one path (i.e. \(x_{p_{1}}\) > 0, \(x_{p_{2}}\) > 0, for two different paths \(p_1\), \(p_2 \in P_{d}\)), we say that the routing of the demand is balanced among those paths.
Integral flows routing: Each path must carry and integer amount of traffic. In some cases, \(h_d\) is measured on integer units and it has no sense to carry non-integer fractions of traffic (i.e. technologies based on virtual circuits of fixed bandwidth). Thus an integral routing is constrained to carry an integral amount of traffic in each path (or an integer multiple of a base value).
Table 1 summarizes information about background underlying Net2Plan.
| Element | Parameter | Description |
|---|---|---|
Nodes |
\(N\) \(\delta^{+}(n)\), \(\delta^{-}(n)\) |
Set of nodes \(n \in N\) Set of outgoing and incoming links from/to node \(n\) |
Links |
\(E\) \(a(e)\), \(b(e)\) \(l_{e}\) \(u_{e}\) u \(y_{e}\) y |
Set of links \(e \in E\) Origin and destination nodes of link \(e\) Length of link \(e\) (Km) Capacity of link \(e\) (Erlangs) Vector form of \(u_{e}\) Traffic carried by link \(e\) (Erlangs) Vector form of \(y_{e}\) |
Demands |
\(D\) \(a(d)\), \(b(d)\) \(h_{d}\) h \(r_{d}\) r | Set of demands \(d\in D\) Ingress and egress nodes of demand \(d\) Offered traffic for demand \(d\) (Erlangs) Vector form of \(h_{d}\) Carried traffic for demand \(d\) (Erlangs) Vector form of \(r_{d}\) |
Routing |
\(x_{p}\) \(x\) \(a(p)\), \(b(p)\), \(l(p)\) \(p=\{\dots\}\) \(d(p)\) \(P\) \(P_{d} \subset P\) \(P_{e}\) |
Traffic volume carried by \(p\in P_{d}\) for demand \(d(p)\) Vector form of \(x_{p}\) Origin and destination nodes of path, number of hops in the path \(p\) Sequence of links traversed in path \(p\) Demand corresponding to path \(p\) Set of all paths defined in the network \(p\in P\) Subset of the paths in \(P\) that are associated to demand \(d\) Subset of the paths in \(P\) that traverse link \(e\) |
In this section several performance and cost metrics are described. These metrics are useful to define objective functions or problem constraints.
In practical network design different variables can be involved: link capacities, the traffic routing, the topological design of the network, the storage capacity at each node, and so on. Usually, network design problems receive some of this information as input parameters (e.g. traffic demand, and network topology) and try optimize the rest (e.g. capacities in the links and traffic routing) according to a performance merit of interest. Clearly, the number of possible variants and subtypes of network design problems is infinite. Moreover, different technologies add their own particular aspects to network design. For this reason, network design has become a mixture of art and engineering.
In an attempt to provide a (somehow) systematic criteria to cathegorize network design problems, in Net2Plan we adopted the following scheme, which is just an extension of the network design problems’ taxonomy in Kleinrock’s book [Kleinrock1976]:
According to this naming scheme, combinations of these problems are named combining the acronyms. For example, a capacity and flow assignment (CFA) problem involves the joint computation of routing and link capacities. We remark that this taxonomy should be considered as an attempt to give a didactic organization to the utmost diversity of planning problems that arise in communication networks.
Typically network design problems are presented as optimization problems, this means that there are a set of performance criteria to maximize or minimize, subject to some constraints (qualitative statements about network design and performance), given a set of input parameters (i.e. partial network designs, technology constraints...). Optimization algorithms (or just "algorithms") are the methods that compute a numerical solution to a given problem instance. In Net2Plan, an algorithm is a Java file with a given signature (see Section 5.1.2 for more information) that establishes the format of the input and output parameters.
Net2Plan is divided into two main parts: user interface (GUI or CLI) and kernel. The main idea is that all the design algorithms, independently of their specific target, receive as input parameter the current network structure (see Section 4 for more information), and return an updated version of this network structure. Then, the Net2Plan kernel and GUI, are devoted to just process the designs returned by the algorithms: check its validity (e.g. the topology has a correct format, the links are not oversubscribed etc), graphically display the network design, and compute some reports and performance merits.
The idea behind Net2Plan is that you can progressively design your network. This is, you can chain successive algorithms, each one completing a part of the network design. For instance, you can start with a network where only the nodes are defined. Then, an algorithm is used to define the links in the network according to some figure of performance. Afterwards, an algorithm can be run to jointly decide on the capacity in the links and routing of the flows, for a given traffic matrix. As a result, Net2Plan can be a powerful tool for communications network planning courses, since students can see step by step how their designs grow.
Fig. 5.1. Design flow in Net2Plan
Net2Plan assists the task of creating and evaluating network design algorithms by providing built-in example algorithms. Please, visit the Net2Plan website to see an updated list of built-in algorithms and use cases. In Section 5.1.2 we explain in more detail how to integrate new algorithms in Net2Plan.
Please, visit the Net2Plan website to see an updated list of built-in algorithms and use cases.
New algorithms can be implemented as Java classes (.class/.jar files) with a given signature. Integration of algorithms simply requires saving them in any directory of the computer, although it is a good practice to store them in the \workspace directory.
Important: When algorithms are implemented as Java classes, the full path to the class must follow the package name of the class, in order to successfully load the algorithm. For example, if we create an algorithm named testAlgorithm in the package test.myAlgorithms, the full path to the class must be like ...{any}.../test/myAlgorithms/testAlgorithm.class. For .jar files there is not any restriction on the full path, they can be stored at any folder.
Algorithms must implement the IAlgorithm interface in package com.net2plan.networkDesign (check the Library API Javadoc for more information) which can be found in lib\net2plan-lib.jar. Users are responsible to implement three methods: getDescription() returns a description of the algorithm; getParameters() returns the set of parameters of the algorithm, including name, default value and description; and finally executeAlgorithm() which implements the algorithm.
The signature of executeAlgorithm() must be like this:
String executeAlgorithm(NetPlan netPlan, Map<String, String> algorithmParameters, Map<String, String> net2planParameters)
The input parameters are defined as follows:
String: the algorithm is in charge of performing the adequate conversions itself.The output parameter is a String including any kind of information.
In order to improve the user experience, kernel is able to catch any exception thrown by algorithms. Those exceptions are introduced in a Java error console (see Section 6.1.3 for more information). For example, exceptions allow users to check if their algorithms are well-programmed (i.e. no null-pointers), thus in the error console they got a full trace of the error (files, line numbers...). However, when input parameters are wrong or an error within the algorithm is returned (i.e. an optimization problem is unable to find feasible solutions), we we recommend to throw extensions using the Net2PlanExtension class (see Library API Javadoc for more information), since it allows users to see the error in a small dialog in which the only information is the error message (i.e. "A feasible solution was not found") instead of the full error trace in the error console (i.e. "RuntimeException: A feasible solution was not found (MyAlgorithm.java:35), ...)".
When the network design phase is finished, users can evaluate their networks by means of reports. Reports return every kind of information that user requires from a network plan e.g. blocking or delay analysis... Users can also create report-generating routines, that show the network performances they want in the form they want.
Please, visit the Net2Plan website to see an updated list of built-in reports and use cases.
Integration of new reports follows a similar scheme as for algorithms. Reports must implement the IReport interface in package com.net2plan.networkDesign (check the Library API Javadoc for more information) which can be also found in lib\net2plan-lib.jar. Users are responsible to implement four methods: getTitle() returns a brief title of the report, getDescription() returns a description; getParameters() returns the set of parameters of the report; and finally executeReport() which implements the report.
The signature of executeReport() must be as follows:
String executeReport(NetPlan netPlan, Map<String,String> reportParameters, Map<String,String> net2planParameters, IWrapperManager wrapperManager)
The input parameters are defined as follows:
String: the report is in charge of performing the adequate conversions itself.The output parameter is a String including any kind of information. However, it is recommended that returns an HTML file, since the GUI is able to parse and show it to the user, with the option of showing in an Internet browser. This feature allows to include e.g. images within reports.
TBD
TBD
In order to start Net2Plan follow the instructions presented in the previous section. Then, if you choose the GUI, the welcome screen will appear.
Fig. 6.1. Welcome screen
In the top menu you can choose between the different options which Net2Plan provides. Below are listed and explained:
Fig. 6.2. Main menu
This menu has four options: Options, Classpath Editor, Show Java console, and Exit.
Use Options to set Net2Plan-wide parameters. These options have a global scope to all Net2Plan modules: are used within the kernel, and, for instance, to compute delay metrics in built-in reports. In this version there are just four options:
precisionFactor in options structure): This parameter allows considering in the kernel small tolerances in the sanity-checks of the network designs. It avoids situations in which numerical inaccuracies would be interpreted as errors, i.e. if carried traffic by a link is greater than link capacity, kernel may show a warning, but in some cases due to solvers precision there might be a numerical error. For instance, \(u_{e}\) = 10 and \(y_{e}\) = 10.000001 in general would trigger an error, but with this precision factor if \(u_{e} \leq y_{e} \leq u_{e} +\) PRECISIONFACTOR then \(y_{e}=u_{e}\). Its value is constrained to be in range (0,1).averagePacketLengthInBytes in options structure): To get average packet delay metrics in the reports, it is needed to convert the traffic in the links from an adimensional Erlang units to seconds. This parameter divided by the next one allows such conversion. Its value is constrained to be greater than zero.binaryRateInBitsPerSecondPerErlang in options structure): Binary rate equivalent to 1 Erlang. Its value is constrained to be greater than zero.propagationSpeedInKmPerSecond in options structure): Velocity of propagation in the media considered for the links. It allows to compute propagation times. A zero or negative value implies that propagation times are equal to zero. Options are saved when you press “Update” button. Then new values are checked and saved in the options file.
Fig. 6.3. Options
Although a moderate library set is provided within Net2Plan, users may require extra Java libraries (.jar files) to develop their own algorithms or reports (i.e. mathematical or graph theory libraries). So, the classpath editor avoids the tedious task of include Java libraries in environment variables (i.e. CLASSPATH in Windows).
Fig. 6.4. Classpath editor
In the current version of Net2Plan Java libraries can be included in run-time, but unfortunately it is not possible to do the same to remove libraries. In this case, user is forced to restart Net2Plan.
This feature centralizes the error handling within Net2Plan. When an error is thrown, for example, due to invalid input parameters in an algorithm, the error and the stack trace is shown there. Moreover, System.out/System.err is redirected there also, allowing users to debug their Java code.
Important: When JNI/JNA for native library access is used, the native output (i.e. stdout in C/C++) is not equivalent to the Java output, thus such an information will not appeared in the Java error console. A workaround is to start Net2Plan from the command-line according to Section 3.
Fig. 6.5. Java error console
Quits Net2Plan.
This menu has three items: Network design, Traffic design, Resilience simulation and Connection-admission-control simulation.
Selecting Network design opens the Network design window, which you can use to execute your algorithms.
The workspace of the window is divided into three areas: input data, execution and reporting (right area), plot area (top-left area), and information area (bottom-left area).
Fig. 6.6. Network design window
This panel is used for graphically design and see networks. Users are able to add or remove nodes and links, make zoom or take a picture.
Nodes are inserted by right clicking into the canvas and using the option “Add node here”. Nodes can be removed by right clicking on them and using the option “Remove node”.
Fig. 6.7. Inserting a node
Links are inserted by clicking first in the origin node and then in the destination node. It is possible to insert unidirectional links or bidirectional ones (in this case, you must press SHIFT key during that process). Also links can be inserted by right clicking over the origin node and selecting the destination node in the popup menu.
Fig. 6.8. Inserting a link graphically
Fig. 6.9. Inserting a link using a popup menu
In addition, in this panel you can see the current state of the network design through the "Edit network plan" tab. If the design includes routing information, it is possible to visualize the paths which carry traffic of a demand, the paths traversing a link…
Fig. 6.10. Showing the route followed by a traffic demand
Finally, users can add/remove network elements (nodes, links, demands...), assign values to certain properties (e.g. link capacities to all links), or even add/remove user-specific attributes to every network element (nodes, links... or the whole network) using popup menus in the "Edit network plan" tab.
Fig. 6.11. Editing attributes
In this panel you can see the general state of the network design e.g. if node, link or demand sets are defined, if routing is defined… that is, to check the current state in which the network is.
With these two panels, users are able to execute and edit their designs and execute algorithms.
In the Execution controller, users can load network designs and traffic demands and execute algorithms. In general, to calculate a new design the user has to specify the following things:
.xml file with a previously computed and saved network design. The design can be partial: e.g. only the nodes of the network are present. Loading a new design, overwrites any active design coming from previous design algorithm executions. .xml file describing a demand set. If the network structure already contains a demand set and then you load a new .xml file, you will be asked to overwrite it and to remove routing information. Asking “No” you cancel that process.
Fig. 6.12. Executing an algorithm
Once those inputs are filled, the algorithm can be executed by clicking on “Execute”. A popup will be shown during the execution of the algorithms, allowing to stop algorithms taking long execution times. When the execution finishes, a message will be shown, informing whether the algorithm runs well or some error was thrown. Users are able to save current designs using the option “Save”.
In the Edit network plan, users can see and edit information of each element within the network plan e.g. change node name or position, change link capacity, or add a demand attribute. Moreover, as network plan is being completed, more information appears, e.g. if all traffic is being carried, if there are traffic losses…
Fig. 6.13. Edit network plan
In this panel user can select a report to apply to the network plan. The structure is similar to those to execute algorithms. Upon selection and clicking “Show” the report is shown in the bottom part. The user can see it in a browser using the option “View in navigator”.
Fig. 6.14. Showing a report
Reports can be closed individually using the CTRL + W combination.
Selecting Traffic matrix design under Tools menu activates the Traffic generation window. This interface allows the user to generate a .xml file representing a traffic matrix. This figure displays the workspace window for this option.
Fig. 6.15. Traffic matrix design window
The Traffic design window is divided into four different parts:
The user initiates the process by selecting the number of nodes \(N\) in the network using Resize option. The traffic matrix will be like this:
where \(i\) and \(j\) are the node identifiers. Self-demands are not allowed (\(\gamma_{ii} = 0\)).
Next, the user has two options: to introduce values manually, or to use traffic generation patterns. Also you can open an existing .xml file to edit it, or reset to all-zero matrix.
Finally, the user can save it into the file system with the Save button.
Now, the user can apply an automatic normalization of the matrix. Three types of normalization methods are implemented: total, row and column normalization [Cahn1998]. The first adjusts the traffic matrix so that the total traffic offered to the network matches a user defined value. The second (third) modifies the matrix so that the \(i\)-th row (column) of the matrix sums \(x_{i}\), being \(x_{i}, \)i$ = \(1...N\) a vector defined by the user. Note that this means that the total traffic transmitted (received) by node \(i\) is fixed to exactly \(x_i\).
Fig. 6.16. Traffic normalization
\[M'_{T}(i,j) = M_{T}(i,j)\cdot\frac{\text{Total offered traffic}}{\sum_{ij}M_{T}(i,j)}\]
where \(M'_{T}(i,j)\) is the normalized traffic and \(M_{T}\) is the original traffic matrix.
The user introduces the total offered traffic volume in a popup.
Row normalization: the sum of each traffic matrix row have to be the value that the user introduces in a popup.
Column normalization: the sum of each traffic matrix column have to be the value that the user introduces in a popup.
After this, the user can select one of the traffic generation patterns among the five modes available: four of them are simpler, and based on the uniform distribution.
Please note at the end of this process diagonal values of traffic matrix are zero, since self-demands are not allowed.
Fig. 6.17. Uniform traffic models
Traffic generation: population-distance traffic model The fifth mode allows creating a traffic matrix according to the model described in [2]. This latter model applies the information of node position, population and node level, present in a topology information table (user can load a topology from a .xml file). The distribution based on populations and distances follows the next expression:
where Level is a \(L\)x\(L\) two-dimensional matrix (\(L\): number of levels or node types defined by the user). This matrix allows us to introduce asymmetric traffic in the traffic generator; \(Pop_i\) is the population of the node \(i\); \(Pop_{max}\) is the maximum population; \(dist\) is a matrix \(N\)x\(N\) (\(N\): number of nodes) with the distances between nodes; \(dist_{max}\) is the maximum distance.
Fig. 6.18. Population-distance traffic models
TBD
TBD
TBD
In order to help users to develop their own classes, Net2Plan is shipped along a Java library (lib/net2plan-lib.jar) which includes, not only interfaces to implement algorithms and reports, but also classes e.g. to compute shortest paths, network performance metrics, or random traffic matrix models, along with general helper Java classes such as IntUtils or DoubleUtils. Check the library API Javadoc for more information.
Net2Plan 0.2.0 (March 18, 2013)
In its very early stage Net2Plan was designed as a MATLAB toolbox. From version 0.2.0, previous MATLAB versions were discontinued, thus backward-compatibility is not ensured at all. However, interested users can found them in the website.
Net2Plan tool has its origins in 2011, during the preparation of the teaching materials for two new Communication Networks Planning courses at Universidad Politécnica de Cartagena (Spain) taught by Prof. Pablo Pavón Mariño:
Net2Plan is also a part of the Ph.D. work of José Luis Izquierdo Zaragoza, supervised by Prof. Pablo Pavón Mariño.
Aside from Net2Plan, authors also collaborate in the development of MatPlanWDM, an open-source tool for multilayer optical networks. Moreover, Prof. Pablo Pavón Mariño develops the JOM, an open-source Java library for modeling and solving optimization problems in a simple MATLAB-like syntax.
[Cahn1998] R.S. Cahn, Wide Area Network Design: Concepts and Tools for Optimization. The Morgan Kaufmann Series in Networking, Morgan Kaufmann, 1998
[Kleinrock1976] L. Kleinrock, Queueing Systems, Volume 2: Computer Applications. John Wiley & Sons, 1976
[Pavon2012] P. Pavon-Marino, “Lectures of the Telecommunication Networks Theory course,” 2012