Scaling through flow aggregation

Flow aggregation is key to the scalability of our framework. We explained in Section 3.2 how a single rule can be used to carry multiple flows. In Figure 5.11, hosts 1, 2, 3 and 4 send data to the sink. Without flow aggregation, the controller must push a flow rule for each chunk in each transfer. For example, in Fig. 5.8, when all hosts send 20 chunks to the sink, then the ovs1 switch needs 20 rules for the traffic coming from host1, but the ovs2 switch needs 40, the ovs3 switch needs

60and so on, for a total of 280 flows. In this experiment, however, the controller

knows that all traffic is heading to the sink. Therefore, only 20 rules per switch are sufficient to carry all traffic.

0 200 400 600 800 1,000 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 ·10 4 Number of chunks Num of rules Without bypass With bypass

Figure 5.11: Number of flow rules pushed with and without aggregating flows.

5.5.3 Routing and bypassing in a mesh topology

Lastly, we experiment using a mesh topology to show how the implementation exploits the services provided by the Floodlight controller to find a route between the source and the destination. Also, we show how traffic coming from more than one switch can also be aggregated. The topology is shown in Fig. 5.12.

Figure 5.12: Experimental mesh topology.

The experiment consists of transferring a file from sources 1 and 3 to the destination. Our implementation uses the services provided by the Floodlight controller to find a path between the sender and the receiver. Floodlight finds that the appropriate routes are: ovs1, ovs2, ovs5, ovs6 to transfer between source

1 and destination, and ovs3, ovs2, ovs5, ovs6 to transfer between source 3 and

destination.

Given that both paths share nodes 2, 5 and 6, next we experiment bypassing node 5. First, individual bypasses are setup, one for all traffic coming from source

1 and another for all traffic coming from source 3. In this scenario, the gain in

transfer time when the bypass is pushed is similar to the results shown in Fig. 5.9. Here we focus on analyzing if the number of flows needed can be reduced. In ovs1, ovs3 and ovs6, the number of flows needed is the same as shown in Fig. 5.11. However, in ovs2 and ovs5, we achieve a reduction of 50% since the same flows are used to carry all traffic. Although this topology is small, it clearly shows how the number of flows can easily be reduced when two paths have more than two

hops in common.

5.6 Conclusion

In this chapter we proposed an approach to bypass the routing layer in Mobil- ityFirst using cut-through switching and OpenFlow. The advantage of such a bypass is to eliminate the delay introduced at that layer. We discussed how to use OpenFlow to bypass layer 3 routing in MobilityFirst using layer 2 VLAN tagging. Instead of pushing a flow rule to one switch only (as would be done to ensure a hop-by-hop communication), we push rules into all the switches of the path between the source and the destination. By doing this, we ensure that all data is forwarded at layer 2. We also discussed how this technique enables flow aggregation. By managing several data transfers using a small number of forwarding rules, we increase the scalability of the network.

The evaluation using the ORBIT testbed showed that the controller introduces a delay of 688 milliseconds for every 1000 chunks of data sent, in average. This delay is due to the first packet of each chunk having to be processed at the controller. Our experiments using the GENI testbed show how the number of packets processed by the controller can be significantly reduced by the cut-through technique proposed in this chapter. Finally, we show how the flow aggregation capability of SDN-based networks can be used to make this solution scalable. By aggregating flows from multiple sources to a single destination using the same flow rules, the number of rules that must be pushed into the switches is also reduced.

Given the performance gains achieved at intra-domain scale, in the next Chapter we investigate how to implement inter-domain cut-through switching in Mobility- First.

Chapter 6

Internet scale: Inter-Domain Routing with Cut-Through Switching in Mobili- tyFirst

6.1 Introduction

In this chapter we investigate how MobilityFirst can benefit from cut-through switching tunnels across multiple domains, given the benefits of intra-domain tunnels demonstrated in Chapter 5.

To motivate the need for inter-domain cut-through switching in SDN, we first model the dynamic creation of inter-domain tunnels as a linear optimization problem. Particularly, we describe this problem in the context of inter-domain SDN. The problem minimizes the total transfer time while considering the costs of creating inter-domain tunnels. Using this problem formulation, we demonstrate how inter-domain controller latency plays a key role on how tunnels are created. Indeed, we show how inter-domain tunnels are better when the latency is small, but intra-domain tunnels are better otherwise. Next, we propose a greedy heuristic that considers the inter-controller latency to decide how to create tunnels that scales much better than the optimization problem formulation. To the best of our knowledge, our work is the first one to formulate and solve the creation of inter-domain tunnels in SDN.

dynamic inter-domain cut-through switching. The framework is based on the fol- lowing design requirements: inter-domain topology visibility, naming the tunnels as network objects and per-flow traffic engineering. We first describe how Mobility- First uses aggregated nodes and virtual links to share topology information across domains using network state packets. Next, we propose a novel technique that names inter-domain tunnels as network objects to simplify how domain controllers create and maintain tunnel information. Finally, we incorporate the heuristic into this routing framework to decide when is it beneficial to create a new inter-domain cut-through tunnels and which flows should be forwarded through the tunnels.

To evaluate the proposed framework, we developed a prototype for Mobility- First using the GENI testbed based on the implementation described in Chapter 5. The results show that in-transit packet in messages can be reduced by 75% using inter-domain tunnels. Furthermore, naming tunnels as network objects scales better than current protocols such as label distribution protocol (LDP) to setup tunnels. Finally, we also demonstrate the scalability of the solution by showing that incoming packets face a small delay even when the traffic load increases to up to 1000 flow requests.

The remaining of this chapter is organized as follows. We first survey the related work in Section 6.2. Next we describe the optimization problem and heuristic in Section 6.3. Next, we describe the routing framework in Section 6.4. After that, we describe thes traffic engineering techniques using by the framework in Section 6.5. Finally, we evaluate our work in Section 6.6 and conclude in Section 6.7.