This section analyzes the number of network events processed in the control planes (i.e. controllers) of each ASes in the proposed hierarchic architecture and as well as non-hierarchic (distributed, as shown in Fig. 4.4) architecture. For the distributed setting, state sharing and not-sharing case are considered in network setup phases. The following metric have been chosen to assess the scalability performance of the proposed hierarchic SDN architecture since the goal is to reduce the number of mes- sages the controllers exchanges.
• Number of Messages per Control Plane - measures the number of messages handled per control plane in proposed hierarchic and distributed architecture. In Fig. 4.5, the number of messages the Broker exchanges is not same with the number of connections it handles. So there is not a linear relation between the number of messages and number of connections at Broker. This happens because for each connection request from source to destination, the Broker calculates an optimal path. This optimal path may include more than 2 ASes (at least 2 ASes including source AS and destination AS). The flow (actually any flow) will go through at least 2 ASes (transiting 2 ASes). Therefore, the Broker will exchange 1 message for each transit AS controller on the path to set the path and make the reservation. Hence, the number of messages the Broker exchanges depend not only number of connections it
0 1000 2000 3000 4000 5000 6000 7000 8000 Number of Connections 0 0.25 0.5 0.75 1 1.25 1.5 1.75 2 Number of Messages 104 Broker
Figure 4.5.: Number Connections vs. Number of Messages at Broker in hierarchy. There is no sharing of state between controllers of ASes.
handles but also the number of ASes each path includes for each flow. For example, for a request from the source (in AS1) and destination (in AS4), the flow may go through AS1 – AS2 – AS4 which requires the Broker to exchange 3 messages with corresponding controllers (one for each).
0 1000 2000 3000 4000 5000 6000 7000 8000 Number of Connections 0 2500 5000 7500 10000 12500 15000 17500 Number of Messages
w/o Hierarchy, w/o Sharing w/o Hierarchy, w/ Sharing
Figure 4.6.: Number of Connections vs. Number of Messages at controller of AS1. In this architecture, there is no hierarchy. There are two cases: 1) State sharing with each other controller, 2) No state sharing with each other controller.
Fig. 4.6 shows how the AS1 controller messages are affected in the case of no hierarchy, i.e. there is no Broker on top of the AS controllers. The architecture would be similar to the hierarchic setting. The only difference is not that there is Broker over the AS controllers and the AS controllers are connected to only their neighbor
AS controllers as in the Fig. 4.4. That setting is in distributed fashion and two cases have been considered: 1) w/o state sharing, 2) w/ state sharing. In the first case (i.e. w/o state sharing), the AS controllers do not exchange their states such as reachable network addresses in advance. Therefore they do not know anything about each other. They are able to communicate with each other in case of a connection request to out of their domains (i.e. inter AS traffic). When a connection request comes to the controller, it will talk to their neighboring AS controllers to check whether they are able to send the request to the destination. For example, as in the Fig. 4.4, the controller of AS1 is only connected to controllers of AS2 and AS3.
When a source from AS1 wants get a connection to a destination from AS4, the AS1 controller will just exchange messages with neighbor AS controller (i.e. A2 and AS3). In this case, the number of messages will be 2 times of number connections. In the second case (i.e. w/ state sharing), the controllers share some of their network states as indicated before (e.g. reachable network addresses). This state sharing brings the extra message exchanges for each controller in advance. Handling with a connection request is the same procedure as explained in the case of no sharing. They still need to talk to their neighbor AS controllers if they can send the request to the destination. As shown in the Fig. 4.6, there will be some number of messages that AS1 controller has already exchanged with others beforehand in case of sharing setting although there is no connection request.
Fig. 4.7 shows the comparison of the number of messages at controller of AS with hierarchy and without hierarchy. In case of an hierarchic architecture, the bot- tom level controllers like AS1 controller will not handle with their inter-AS traffic connection requests. If the destination in the request is from another AS, then the controller will forward the request to the Broker so that it calculate an optimal path for it since it has the global view of the entire architecture. Therefore, the AS1’s controller exchanges only 1 message, which is forwarding it to the Broker. Hence, there is a one-to-one ratio between number of connection and number of messages the AS1’s controller exchanges in a hierarchic architecture. The without hierarchy
0 1000 2000 3000 4000 5000 6000 7000 8000 Number of Connections 0 2500 5000 7500 10000 12500 15000 17500 Number of Messages
w/o Hierarchy, w/o Sharing w/ Hierarchy, w/o Sharing
Figure 4.7.: Number of Connections vs. Number of Messages at controller of AS1 in the hierarchic and non-hierarchic architectures. There is no state sharing in each case.
case is the same with case explained above and there is no sharing. As shown in the Fig. 4.7, the number messages that AS1’s controller exchange in the no hierarchy case is 2 times of the hierarchy case. A hierarchic architecture reduces 50% of the number of messages that a controller handles.
4.7 Chapter Summary
This chapter have presented a hierarchical SDN architecture and inter-AS QoS based routing approach. The purpose of the proposed architecture is to improve the scalability of the control plane (i.e. controller) in an SDN network by reducing the number of messages that a controller deals with. The experiment results have shown that a network controller will handle 50% less messages for inter-AS traffic in a hierarchic environment compared to non-hierarchic environment since they do not need to keep global network view and synchronize with other states. This situation reduces the number of messages although the number of connections increase in a network.
5 MEASURING SCALABILITY IN SDN 5.1 Abstract
SDN architecture promises to mitigate limitations of traditional networking archi- tectures in order to satisfy today’s complex networking needs. However, as all new networking architectures, SDN also presents several inevitable technical challenges to be addressed by researchers. Control plane scalability is one of the crucial issues deserving more attention from both academia and industry in SDN as well. There are many existing solutions proposing a way to alleviate the control plane scalability in SDN. However, one prominent common ground they share is that they measure the control plane scalability performance in terms of typical network QoS parameters such as throughput and latency. Although these metrics may be a good performance indi- cators for quality of service measurement in mid-term and long-term, they may not reflect real scalability performance of control planes in SDN environments. However, a metric for scalability of control plane in SDN can provide network administrators some insights while they construct their SDN networks. This chapter firstly explore the roots of control plane scalability problem in SDN as well as proposed existing solutions. A metric is then proposed in order to evaluate the control plane scalability in SDN. This chapter also gives mathematical models of the proposed metric over different control plane designs. Furthermore, the performance of these control plane designs is compared by extensive experiments.
5.2 Introduction
Traditional networks have reached their architectural limitations. Increasing cloud services, server virtualization, sharp growth of mobility and content-like video have
led researchers to rethink today’s network architectures. In traditional architectures, network devices and appliances are complex and difficult for (re)configuration and (re)installation since they require highly skilled persons. Adding or moving a device from a network requires extra costs. It is also time-consuming because IT people need to deal with multiple switches, routers, etc. and update ACLs, VLANs and some other mechanisms. Furthermore, as business demands or user needs increase day by day, application developers, carriers, and enterprises need to delve into evolving new services and facilities. However, vendor dependency is an obstacle deterring them from developing new networking applications and services for their networks due to slow equipment product cycle, application testing and deployment. Therefore, data centers, carriers, and campuses need more dynamic architectures today.
SDN architecture has emerged in response to aforementioned limitations of tra- ditional networking architectures. SDN aims to decouple the controller plane and data plane. This separation provides network operators/administrators efficient use of network resources and eases provisioning of resources. Also, SDN brings ease of programmability to change the characteristics of whole networks. This simplifies the management of the network since it is decoupled from the data plane. Therefore, network operators can easily and quickly manage, configure, and optimize network resources with dynamic, automated and proprietary-free programs written by them- selves in SDN architecture. In addition, since network is logically centralized in SDN, controllers have a global visibility of the whole network unlike conventional network- ing. Hence, they can dynamically optimize flow-management and resources.
However, SDN also presents several technical challenges. Sezer et. al [1] states that these challenges can be classified in four different categories. The first one is how to deal with high-performance packet processing in a flexible/programmable manner. The second is interoperability or standardization that needs to be addressed in SDN infrastructure. The third is security issues in SDN. The final category is the scalability issue in SDN, which especially needs more attention by researchers.
Scalability proposals in SDN study the problem in terms of improving the scala- bility of control plane with respect to some network metrics such as throughput and latency and do not propose a metric to quantify the scalability [51, 59]. However, a metric for scalability of control plane in SDN can provide network administrators some insights while they construct their SDN network. This chapter firstly explores the roots of control plane scalability problem in SDN as well as proposed existing solutions. A metric is then proposed in order to evaluate the control plane scalability in SDN. This chapter also gives mathematical models of the proposed metric over different control plane designs. Furthermore, the performance of these control plane designs is compared by extensive experiments.
In the remaining of the chapter, the chapter digs out the roots of SDN control plane scalability issues and presents some existing solutions alleviating the problems in Section 5.3. In addition, the chapter gives a snapshot of several research attempts proposing a scalability metric to measure the scalability of systems. Section 5.4 de- scribes the proposed scalability metric in a general perspective. In Section 5.5, the chapter models the metric by a mathematical methods over different SDN control plane designs throughout in corresponding subsections. After discussing the experi- mental results in Section 5.6, the chapter is summarized with concluding remarks in Section 5.7.