Our main design goal for virtual networks was that they reflect different use-cases with a diverse set of resource demands. To fulfill this goal, we designed four different archetypes of virtual networks. After the creation of a substrate network as outlined in the previous section, we added ten instances of each of the four virtual network types to define a VNMP instance. The size of each virtual network was chosen uniformly at random from[5,min(30,0.3∗ |V|)]. These bounds ensure that on one hand, the created virtual networks are not too small and on the other hand that they are significantly smaller than the substrate network into which they have to be mapped. Now follows a discussion of the four different virtual network archetypes.
5.3.1 Stream Network
This virtual network type models (video-)streaming services and has a random tree structure.
The root node represents a streaming service which broadcasts its content consisting of multiple channels. Intermediate nodes in the distribution tree split this stream and forward only the channels that are actually watched by the customers connected to the leaf nodes of the tree. This is an example of an application that can directly benefit from custom routing protocols, as this splitting and forwarding of data is currently not possible within the network. A streaming service sends between 10 and 20 channels, each requiring between 2 and 10 units of bandwidth, which covers audio and video streaming. Every intermediate node forwards between 30% and 100%
of received channels to each of its children, making sure each channel is forwarded at least once and each child receives at least one channel. The required bandwidth of each virtual arc is the product of transferred channels and the bandwidth requirement per channel. The required CPU power on each virtual node is three times the received bandwidth which models the required
processing power for unpacking and redistributing the stream. For the root node, the required CPU power is three times the sent bandwidth. Streaming applications are not delay constrained in our model, so we set the delay requirement of each virtual arc to the highest shortest path delay within the substrate network. As for the allowed mapping of the virtual nodes, we create groups of substrate nodes for the root and all leaf nodes. The node grouping procedure works as follows: Initially, substrate nodes are grouped according to their geo-location. If this creates more groups than required, some are randomly deleted so that the required number of groups is reached. Otherwise, we generate a new group by randomly moving half of the nodes of the largest group (rounding down in case of odd-sized groups) to this new group. New groups are generated until the required number of groups is reached. The location of the root node of the Stream virtual network is fixed to one of the nodes of its group. The leaf nodes can be mapped to any substrate node in their group. Intermediate nodes in the streaming tree can be mapped to any node in any group.
5.3.2 Web Network
This virtual network type models the typical web usage and has star structure. The center rep-resents the web-server which serves the connected customers. Each customer receives between one and five units of bandwidth, the processing of which requires one unit of CPU power per re-ceived unit of bandwidth. The CPU requirement of the web-server is the sum of the transmitted bandwidth. As for the allowed mapping, the node grouping procedure is used to create map-ping target candidates for each node of the virtual network. The virtual node of the web-server can only be mapped to one randomly selected substrate node of its group. All other nodes can be mapped to two randomly selected nodes of their group. As delay requirement for each arc (which connects the web-server node to one of the customer nodes) we set the smallest possible delay with which both possible locations of the customer node may be reached from the loca-tion of the web-server node. This models hard delay requirements, since users usually expect web-pages to load fast.
5.3.3 Peer-to-Peer Network
This virtual network type represents Peer-to-Peer (P2P) networks and is based on a directed small world graph [98, 149]. P2P applications do not have delay requirements (in our model), so the delays are set as they are for the Stream virtual networks. However, they have high bandwidth requirements; each arc requires between 10 and 70 units of bandwidth. The CPU requirements on each virtual node are twice the outgoing bandwidth which models compression or encryption services offered by this network type. As for the allowed mapping, the node grouping procedure is used to create groups for each of the nodes of the P2P network. Every virtual node is allowed to be mapped to any substrate node of its group.
5.3.4 Voice-over-IP Networks
This virtual network type models Voice-over-IP (VoIP) networks and is, like the P2P type, based on a directed small world graph. It requires 2 to 20 units of bandwidth for each virtual connection
and three times the outgoing bandwidth as CPU power on each virtual node, which models video compression and transcoding services. The virtual nodes can be mapped to any substrate node of their substrate node group created by the node grouping procedure. The delay requirement of a virtual connectionf for this virtual network type is set to the lowest possible value such that a delay constrained path between every location ofs(f)andt(f)in the substrate exists.
To sum it all up, Stream networks have high bandwidth and CPU requirements but are barely delay constrained. Web networks on the other hand have very low bandwidth and CPU require-ments but stringent delay constraints. P2P networks have high bandwidth and medium CPU requirements and lax delay constraints. VoIP networks have medium bandwidth and CPU re-quirements and are moderately delay constrained. P2P and VoIP networks also have a complex structure.
At this point, we have built a VNMP instance by creating a substrate network and assigning costs and delays to it. Then we added ten virtual networks for each of the four different network types together with their mapping constraints. To clarify, the 40 different networks are combined into one graph, the virtual network graphG0. The only missing component are the bandwidth and CPU capacities in the substrate network. We assign them by creating a random solution to the VNMP instance as it is now and use it as a guide to define the available resources.
As the first step for creating the guiding solution, we map each virtual node to one of its allowed locations in the substrate. Note that due to the chosen delay limits of the virtual networks, it is guaranteed that implementing paths satisfying the delay constraint exist for any mapping of the virtual nodes. To set the implementing paths of the solution, we could just use delay shortest paths. However, that would introduce too much structure into the solution, meaning that it could be found easily based on the final VNMP instance. Therefore, we construct implementing paths by solving a resource constrained shortest path problem. The delays within the substrate are used as resource, as lengths we set random values between one and ten for every substrate arc.
The distance values are set differently for every path calculation to increase the randomness of the final solution. Based on the created solution, we assign CPU and bandwidth resources available in the substrate so that the solution is valid. Some nodes or arcs may not have been assigned resources. Substrate nodes get assigned the average amount of CPU resources (that have already been set) within their geo-location. If all nodes of a geo-location have not been assigned CPU resources, they are assigned the average amount of assigned CPU resources within the whole substrate network. The same process is applied to assign missing bandwidth resources.
Arcs within a geo-location get assigned the average of the location, if no arc has been assigned resources the average bandwidth resources within the substrate are assigned. Arcs connecting different geo-locations get assigned the average bandwidth of arcs that have been assigned a bandwidth capacity and cross a geo-location. Note that it is not possible that no arc connecting different geo-locations has been assigned a bandwidth capacity based on the guiding random solution. Now all resources have been assigned. As a final step, we increase the CPU and bandwidth capacities at each node or arc separately by 20% to 50% so that there is more room for optimization.
One design goal is still unfulfilled: a way to control the “hardness” of a VNMP instance. We do this by modifying the number of virtual networks that have to be mapped, which we will denote by the load of an instance. The instances created by the outlined procedure have a load of 1, or
Table 5.1: Properties of the VNMP instances: average number of substrate nodes (V) and arcs (A), virtual nodes (V0) and arcs (A0), number of allowed mapping targets for each virtual node (MV0) and the average total usage costs (Cu).
Size |V| |A| |V0| |A0| |MA0| Cu
20 20 40.8 220.7 431.5 3.8 1536.0
30 30 65.8 276.9 629.0 4.9 2426.6
50 50 116.4 398.9 946.9 6.8 4298.1
100 100 233.4 704.6 1753.1 11.1 8539.1 200 200 490.2 691.5 1694.7 17.3 17584.2 500 500 1247.3 707.7 1732.5 30.2 44531.8 1000 1000 2528.6 700.2 1722.8 47.2 89958.4
full load. For lower loads, some virtual networks are removed. At load 0.9, one virtual network of each type has been removed. At load 0.1, the VNMP instance contains four virtual networks, one of each type. Based on the created 210 VNMP instances of full load (30 instances for seven different substrate network sizes), 1890 additional instances can be derived by reducing the virtual network load (0.1 to 0.9), yielding a total of 2100 VNMP instances. The created instances are available at [87].