ONDM 2017 Paper on Virtual DBA

Frame Level Sharing for DBA virtualization in multi-tenant PONs in Multi-Tenant PON

 

Figure 2

Fig. 2:Frame level sharing architecture, sharing frames among VNOs.

Performance Evaluation

We developed a C++ XGS-PON simulator (e.g., using symmetric 10G upstream/downstream rates) and used it to simulate one OLT and 60 ONUs with maximum physical distance of 40 Km. The upstream capacity was set to 9.95328 bps, according to the standard. The Ethernet frame size for the packet load generator ranges from 64 to 1518 bytes with trimodal size distribution, as reported in [14]. We employed self-similar traffic with long range dependence (LRD) and Hurst parameter 0.8. The ONUs are divided equally among VNOs and all VNOs employ the GIANT [9] DBA algorithm with three T-CONTs, namely: assured, non-assured and best effort. We considered service intervals of 4, 8, and 8 frames respectively. The ONU buffer size is set to 3 MB. The offered load is uniformly distributed among ONUs and T-CONTs. We assume the total PON assured traffic capacity is divided homogeneously among VNOs, but they are allowed to exceed this figure with non-assured and best effort traffic.

Regarding the number of VNOs and offered load distribution, we consider three simulation scenarios as follows:

  • Scenario 1: we consider two VNOs with offered load divided equally among them.
  • Scenario 2: we consider five VNOs with offered load divided equally among them.
  • Scenario 3: we consider two VNOs with offered divided on a 1:2 ratio among them.

The performance of our FLS algorithm is tested against the SS framework [7], discussed in section II. In order to achieve a fair comparison between FLS and SS capacity sharing policies we use same number of VNOs and same service intervals (both mechanism are based on the GIANT DBA) and set the maximum service rate to the full XGS-PON capacity. The forgetting factor was set to 0.125 [7], while the minimum committed service rate was set equal to the share of the total PON capacity for each VNO. Our main performance metrics is the average packet delay, while we also investigate the frame loss rate.

A. Scenario 1

The average packet delay for our proposed FLS and the benchmark SS is shown in Fig. 5. It can be noted that both static and dynamic SS switching mechanisms have the same performance for assured, non-assured, and best effort traffic. Regarding FLS, both capacity sharing and no capacity sharing have very close performance. Capacity sharing has lower delay than no capacity sharing at high load for best effort traffic. This situation is reversed for non assured traffic. Comparing both SS and FLS, we find that FLS delay is significantly lower than SS delay by 50% for assured and non assured traffic. This statement is still true for best effort traffic for offered load below 9 Gbps. The minimum achieved delay by SS matches our note in Section II. Since the service interval is equal to 4 for assured traffic and there are two VNOs, then the assured T-CONTs are polled every 8 frames. Hence the minimum average delay is 12 frames (1500μs). The reported results in the original SS paper [7] show the same behavior. On the other hand, FLS allows assured T-CONTs to be polled every 4 frames. Hence FLS achieves 50% lower delay. The frame loss rate is similar in both SS and FLS, thus we do not report its plot.

Figure 5

Fig. 5:Average delay (scenario 1): (a) Assured bandwidth (b) non-assured bandwidth (c) best effort.

B. Scenario 2

In scenario 2, the number of VNOs is set to 5. There are three interesting points to note. First, in FLS for best effort traffic the capacity sharing policy shows significant lower delay at high load compared to no capacity sharing. Second, the minimum achieved latency for FLS is still the same as in scenario 1. This shows that FLS is more resilient to the number of VNOs compared to SS. Third, the minimum achieved latency of SS is increased by a factor of 2.5, since, as explained in the subsection above, it is proportional to the number of VNOs in the system. This shows that SS framework performance is highly dependent on the number of VNOs.

C. Scenario 3

In Scenario 3, the number of VNOs is set to 2, but the offered load of one VNO is twice that of the other VNO. The delay performance of the low loaded operator is shown in Fig. 7, while the high loaded one is shown in Fig. 8. Comparing assured bandwidth performance for both operators, we see that FLS achieve higher isolation than SS, as we notice that the assured bandwidth delay of the lower loaded operator is almost constant over the load range for both the capacity and no-capacity sharing policies. On the other hand for SS, the dynamic switching mechanism achieves increasing delay for the lower loaded operator and decreasing delay for the higher loaded operator at high offered load. This is because as the offered load increases, the SS layer (dynamic) assigns more upstream frames to the higher loaded operator. This leads to reduced delay for the higher loaded operator and increased delay for the lower loaded one. Regarding Best effort traffic, FLS capacity sharing policy achieves significant lower delay compared to no-capacity sharing policy and both SS switching mechanisms.

The frame loss rate is reported in Fig. 9. For the lower loaded operator, the SS dynamic approach increases the frame loss rate by a small amount. For higher loaded operator, the SS dynamic approach and FLS capacity sharing policy are more stable than the SS static approach and FLS no-capacity sharing policy. However, the FLS capacity sharing approach has the advantage of not raising either the lower loaded operator frame loss rate nor the average delay, thus providing again good isolation between the two VNOs.

Figure 7

Fig. 7:Average delay (scenario 3, low loaded VNO): (a) Assured bandwidth (b) non-assured bandwidth (c) best effort.

Figure 8

Fig. 8:Average delay (scenario 3, high loaded VNO): (a) Assured bandwidth (b) non-assured bandwidth (c) best effort.

Figure 9

Fig. 9:Scenario 3: frame loss rate (a) low loaded VNO (b) high loaded VNO.

Conclusion

In this work, we proposed a novel virtualized PON sharing architecture called Frame Level Sharing (FLS). FLS introduces the concept of virtualization by migrating and virtualizing the DBA function from the physical OLT (owned by the infrastructure provider) to a virtual PON slice controlled by the virtual network operator. FLS is designed to achieve upstream frame level sharing among VNOs while maintaining service isolation among them, by introducing a new sharing engine layer on top of the TC layer. The sharing engine is responsible for merging the received virtual bandwidth maps into the physical bandwidth map to be transmitted along with the downstream frame. Simulation results in balanced load scenarios shows that FLS achieves less delay compared to a benchmark scheme (the Slice Scheduler) found in literature, and a low dependency on the number of VNOs sharing the PON. In addition, even for non-balanced load scenario, FLS achieves excellent service isolation among VNOs.

A. Elrasad and M. Ruffini, “Frame Level Sharing for DBA virtualization in multi-tenant PONs,” 2017 International Conference on Optical Network Design and Modeling (ONDM), Budapest, 2017, pp. 1-6.
doi: 10.23919/ONDM.2017.7958528
keywords: {channel capacity;passive optical networks;frame level sharing;DBA virtualization;PON;fiber-to-the-premises access network;ubiquitous fiber infrastructure;passive optical networks;point-to-point solutions;virtual network operators;capacity scheduling;virtual dynamic bandwidth assignment;Passive optical networks;Bandwidth;Delays;Engines;Switches;Business;Scheduling algorithms},
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7958528&isnumber=7958513

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s