Simulation Results

z^m_(i,j)+ˆzⁿ_(i,j)

≤L(i,j),∀(i,j)∈E (4.5)

with L_(i,j)being the maximum number of labels per link (or interface) in(i,j).

4.5.4 No Label Stacking

For the particular case of the ROUTING ANDLABELMERGINGproblem, the pre-vious model can be simplified by eliminating the decision variables ˆzⁿ_(i,j) and y^φ,α. This leads to the removal of inequalities (4.1e) and (4.1f), and the modification of inequalities (4.1g) accordingly. This variation is mainly used for modeling ELS (see Section 4.6.3).

4.6 Simulation Results

Since the purpose of this book is to delve into the value of mathematical formu-lations of networking problems, in this section we give a brief explanation of the simulation results of the aforementioned problems.

Since the motivations and objectives are different for every technology, the re-sults are depicted in different subsections following the same order as that in Sec-tion 4.2.

4.6.1 MPLS-TE

MPLS-TE was designed for the support of external path computation procedures aiming at optimizing some TE metric. Therefore, it is the aim of MPLS-TE to rely on routing protocols for path computation. Hence, for MPLS-TE, we present sim-ulation results that do not include the routing part of the problem. That is, we are given a set of paths and we only want to reduce the number of labels by label merg-ing and stackmerg-ing.

We want to compare how many labels can be reduced by using the stack. An extended version of the results presented in this subsection can be found in [16].

We considered an Australian ISP topology gathered in the Rocketfuel project.

The topology consists of 28 nodes. We choose 30% of nodes as ingress and egress and we vary the number of routed LSPs between them from 10 to 300. To generate

the path routes, we use the k-shortest path first (k-SPF) algorithm. We have chosen k-SPF because shortest path routing leads to the worst link utilization. As a conse-quence, the usage of k-SPF would give us a lower bound on the usage of the label space incurred by any of the traditional routing solutions.

Figure 4.8 shows the number of labels used when: a)no reduction method is applied, b)label merging and no label stacking is used and, c)label merging and stacking is used. The numerical value is found using the ILP formulations described in the chapter. At the bottom of the figure we show the average overhead in the packets due to the usage of the stack.

0 200 400 600 800 1000 1200 1400 1600 1800

Number of Labels

No Label Space Reduction MultiPoint-to-Point Asymmetric Merged Tunnels

4 5 6 7

0 50 100 150 200 250 300

Avg. Header Size using AMTs (bytes)

Number of LSPs

Fig. 4.8 Comparison using one stacked label. The routes are given

We observe that, when the network load is high (300 LSPs), the label space reduction is 70.6% using the stack, while without using the stack, label merging achieves a reduction of 48.75% in the label space usage.

4.6.2 AOLS

The motivations for reducing the label space usage in AOLS are as strong as con-sidering the selection of appropriate routes within the same problem. That is, to consider the path routes that would help reduce the label space, as mentioned in Section 4.4. Since the tendency of an ‘optimal’ routing solution is to saturate link capacity, we summarize in this subsection results showing the trade-off between link

capacity and the number of labels that can be saved. An extended version of these results can be found in [11].

The results we show in this section are computed using a heuristic. However, they are corroborated with the optimal solution of the model in smaller networks.

The gap between the heuristic and the model solutions lies within 20% of the differ-ence when considering smaller networks. We use two routing heuristics: Constraint Shortest Path First (CSPF) and Path-Interfering Routing Algorithm (PIRA) (specif-ically designed for label space usage optimization) [11].

In brief, we found that the use of the stack reduces the label space four times on average when the capacity of the links is just enough to route traffic, and almost six times if the link capacity is doubled.

Considering the routing solutions, we noticed that while the Maximum Link Uti-lization (MLU) of CSPF is 934 units of traffic, PIRA’s is 2,236; this is 2.5 times more. However, we notice that this case occurs in few links. Figure 4.9 shows the distribution of links in PIRA that are above a given ratio of CSPF’s MLU. For in-stance, there are six links in PIRA that are using between 50% and 75% more ca-pacity than the minimum MLU considering CSPF routing. It turns out that while 25 links (out of 114) require a higher link capacity, 74 are not used by PIRA (16 of them are not used by CSPF either).

0

Relative Link Usage Distribution respect to CSPF Minimum MLU Links Overusing MLU of CSPF = 25

CSPF=16

Fig. 4.9 Distribution of links in PIRA that are exceeding CSPF’s MLU

We now compare the best solution without stacking (CSPF with label merging) with the best solution using the stack (PIRA with label merging and stacking). The maximum number of labels that the label merging solution uses is 20. This makes all AOLS blocks sized for coding five-bit long labels. By using stacking, the maximum

number of labels becomes 11, making the AOLS blocks sized for coding labels only four bits long. In our results without stacking, we noticed that 11 links are causing the five- bit long labels. However, using the stack, only four links are forbidding us from using three-bit long labels. Even though we did not optimize the maximum number of labels per link, it is not difficult to see that rerouting the traffic in the three links of our solution would be easier than rerouting the traffic in the 11 links in the label merging solution in order to reduce by one bit the label encoding size.

4.6.3 ELS

As mentioned in Section 4.2.3, the motivations to study ELS labels space are to determine the scalability of the architecture and the available methods when using a 12-bit label. This has been mainly studied in [3]. As in MPLS-TE, in [3], the improvement of label space usage has not been considered as a routing objective.

Instead, the scalability of ELS was evaluated for the off-line and online routing scenarios. Both cases, when labels have link and node scope, were considered.

For the online routing scenario, the Shortest Path First (SPF), the Constraint Shortest Path First (CSPF), and the MIRA were implemented. Three topologies were considered, COST266, Germany50 and Exodus(US); a capacity of 10 Gbit/s are assigned to all the links [3]. Two sets of LSP requests were evaluated, one with requests of low capacity (1 Mbit/s) to consider a worst case (given that label sparcity is higher for low capacity demands) and another with requests of different capacities (1 Mbit/s, 2 Mbit/s, 10 Mbit/s, 20 Mbit/s) to consider a more realistic case. Results are compared in terms of the decrease in throughput given by the rejection of LSP requests due to unavailability of labels.

• When considering homogeneous bandwidth requests of 1 Mbit/s, results show that with the label size restricted to 12 bits per link, all evaluated algorithms result in a decrease in throughput that ranges from 32% to 50% compared to the scenario in which there is no limit in the label space size. With a restricted label size but label merging enabled, the resulting throughput is identical to the one obtained when using an unlimited label size. When the label size is restricted to 12 bits per node, the decrease in throughput ranges from 46% to 69% and with label merging enabled from 12% to 22%. The latter observation applies for all the evaluated algorithms. This is an interesting result as it shows that label merging overcomes the label size limits for a link scope even with demands of low capacity. This is not the case when the labels have a node scope were there are limitations even with merging.

• When considering heterogeneous bandwidth requests, with the label size re-stricted to 12 bits per link, none of the evaluated algorithms show a decrease in throughput higher than 1%. In addition, when label merging is applied, the maximum number of labels used decreases considerably (from 42% to 57%).

When the label size is restricted to 12 bits per node, the decrease in throughput ranges from 19% to 29%, and with label merging enabled, from 1% to 11%.

For the off-line routing scenario model, a model similar to the one presented in Section 4.5 with the no label stacking and Traffic Engineering Variations was implemented. Results show that the highest maximum number of utilized labels was very low compared to the unused labels for both node and link scopes. This result shows that, even without merging, for the off-line scenario a 4,096 label value space is not a limitation.