Soutenance mémoire
SDN protocol: OpenFlow
There are many standard protocols used by SDN to ensure the communication between the control plane and the data plane, the most popular one is the “OpenFlow” which allows SDN implementation in both hardware and software devices (Lara, Kolasani et Ramamurthy, 2014). OpenFlow is flow-oriented protocol; it is used for communication between the infrastructure layer and the control layer. In fact, the controller communicates with switches and manages them through OpenFlow. An OpenFlow switch can contain multiple flow tables, a group table and an OpenFlow channel; therefore, OpenFlow switches in the data plane are connected to each other via the OpenFlow ports. To understand the different functionalities of OpenFlow, it is primordial to explain first the following key words: Flow tables: contains a set of flow entries, the flow table is used to match or to specify an action to incoming packets and to direct them to its destination based on its header. A flow table entry is identified by its match fields and priority: the match fields and priority taken together identify a unique flow entry in the flow table (TS-007, 2012). Group tables: contains a set of group entries, a flow table may direct a flow to a group Table, which may execute a variety of actions that affect one or more flows. OpenFlow channel: is the interface used for communication between an OpenFlow switch and an SDN controller. First, the controller uses this interface to configure and to manage switches. Second, it uses it to receive events from switches. OpenFlow ports: there are physical network interfaces used to pass packets between OpenFlow processing and the rest of the network.
Contributions of SDN
SDN concept is a strong candidate to replace existing architectures because it has many advantages that can overtake limitations of traditional technologies used in WAN to interconnect DCs. So in this section, we will expose the most important advantages of SDN which encourage SPs to think about using to this new approach: Intelligence and speed: SDN is able to optimize the distribution of the workload in the network thanks to the centralized control and the global knowledge of the current state of different links and nodes in the topology. This optimization can lead to a high-speed transmission in the network and enhance the efficiency of resource allocation. Easy network management: There is a remote and global control over the network and there is also the possibility to change the network characteristics based on the workload patterns. This is the main advantage of the centralized architecture proposed by SDN. Additionally, the centralized architecture proposed by SDN is a motivation for researchers in traffic characterization and prediction field. In fact, they can develop advanced algorithms to predict failures or link overutilization and based on this prediction module, the controller can update in a real time some rules in different switches in the data plane. Multi-tenancy: SDN ensures that all tenants have good cross site performance isolation, unlike existing architectures which do not support control network ability between different intra-tenants and inter-tenants. These advantages listed above present a really good motivation for researchers who are looking for a solution to control and manage their networks in an optimal and efficient way, to minimize the total cost of resource allocation and to achieve the required level of scale. So, using the new concept of SDN in inter-DC WAN will remedy to some limitations of traditional or even virtual technologies used nowadays to interconnect DCs.
Advantages and limitations This work uses Game Theory to optimize hosting costs dynamically over time based on both demand and price fluctuations. Game Theory in this case is used to control the network’s state when the centralized control defined in SDN concept is absent. In case of uncoordinated SPs which can act in a selfish way, the resulting NE can be significantly suboptimal. So, Qi Zhang et al propose to take into consideration the contribution of InP in order to maximize the social welfare.Obviously, this framework has achieved its main goal which is the ability to adjust resource allocation based on the dynamicity of resource prices. But the proposed algorithm is very complicated and can generate a huge overhead in the network, especially when the number of players (SPs) that are competing for resources is important, in this case the convergence of the proposed algorithm can take time. In addition, algorithms proposed in case of single SPs or multiple SPs do not take into consideration the difference between price models used in different DCs while solving the placement problem, which can have an important impact on the stable outcome of this competition. Finally, this work does not take into account the minimization of the total energy consumption while allocating resources to different SPs, it just consider the load balancing as a main objective. SD-WAN There are two approaches to build an SD-WAN network: Google’s approach (Jain et al., 2013) which is to design the network from scratch as a SD-WAN network with OpenFlow switches and a centralized controller and the second approach is Microsoft’s approach (Hong et al., 2013) which is to build SD-WAN on the top of the existing network. The second approach is more complicated because, in this case, there is a need to add network elements (NE) (brokers or aggregators) in the existing topology in order to interconnect the infrastructure plane with the SDN control plane as shown in Figure 3.4. In our work, we adopt the second approach which aims to optimize resource allocation and to ensure efficiency, flexibility and scalability in Inter-DC WAN using existing resources (Gouveia et al., 2014) .
QoS for interactive application MCTEQ takes into consideration explicitly the constraint of delay for interactive traffic. The end-to-end delay on a given path is characterized by the sum of the propagation delays for all the links and the queuing delays for all the nodes on the path (Wang et al., 2014). In fact, propagation delay is simple to compute, however, queuing delay is more complicated because it depends on various factors such as bandwidth allocated in each link and scheduling policies used in each link. That’s why there is a need to bound the queuing delay for interactive flows. This work assumes that the service discipline used on all devices in the network is guaranteed rate (GR) schedulers. Based on this assumption, the end-to-end delay of each packet can be bounded. To guarantee QoS requirement for interactive flows in terms of delay, it is about ensuring that the end-to-end delay respects a tolerable delay bound. This constraint must be respected when a fraction of an interactive flow ݅ use a specific path .
That’s why it is SDN protocol: OpenFlow There are many standard protocols used by SDN to ensure the communication between the control plane and the data plane, the most popular one is the “OpenFlow” which allows SDN implementation in both hardware and software devices (Lara, Kolasani et Ramamurthy, 2014). OpenFlow is flow-oriented protocol; it is used for communication between the infrastructure layer and the control layer. In fact, the controller communicates with switches and manages them through OpenFlow. An OpenFlow switch can contain multiple flow tables, a group table and an OpenFlow channel; therefore, OpenFlow switches in the data plane are connected to each other via the OpenFlow ports. To understand the different functionalities of OpenFlow, it is primordial to explain first the following key words: Flow tables: contains a set of flow entries, the flow table is used to match or to specify an action to incoming packets and to direct them to its destination based on its header. A flow table entry is identified by its match fields and priority: the match fields and priority taken together identify a unique flow entry in the flow table (TS-007, 2012). Group tables: contains a set of group entries, a flow table may direct a flow to a group Table, which may execute a variety of actions that affect one or more flows. OpenFlow channel: is the interface used for communication between an OpenFlow switch and an SDN controller. First, the controller uses this interface to configure and to manage switches. Second, it uses it to receive events from switches. OpenFlow ports: there are physical network interfaces used to pass packets between OpenFlow processing and the rest of the network.
Contributions of SDN
SDN concept is a strong candidate to replace existing architectures because it has many advantages that can overtake limitations of traditional technologies used in WAN to interconnect DCs. So in this section, we will expose the most important advantages of SDN which encourage SPs to think about using to this new approach: Intelligence and speed: SDN is able to optimize the distribution of the workload in the network thanks to the centralized control and the global knowledge of the current state of different links and nodes in the topology. This optimization can lead to a high-speed transmission in the network and enhance the efficiency of resource allocation. Easy network management: There is a remote and global control over the network and there is also the possibility to change the network characteristics based on the workload patterns. This is the main advantage of the centralized architecture proposed by SDN. Additionally, the centralized architecture proposed by SDN is a motivation for researchers in traffic characterization and prediction field. In fact, they can develop advanced algorithms to predict failures or link overutilization and based on this prediction module, the controller can update in a real time some rules in different switches in the data plane. Multi-tenancy: SDN ensures that all tenants have good cross site performance isolation, unlike existing architectures which do not support control network ability between different intra-tenants and inter-tenants. These advantages listed above present a really good motivation for researchers who are looking for a solution to control and manage their networks in an optimal and efficient way, to minimize the total cost of resource allocation and to achieve the required level of scale. So, using the new concept of SDN in inter-DC WAN will remedy to some limitations of traditional or even virtual technologies used nowadays to interconnect DCs.
Advantages and limitations
This work uses Game Theory to optimize hosting costs dynamically over time based on both demand and price fluctuations. Game Theory in this case is used to control the network’s state when the centralized control defined in SDN concept is absent. In case of uncoordinated SPs which can act in a selfish way, the resulting NE can be significantly suboptimal. So, Qi Zhang et al propose to take into consideration the contribution of InP in order to maximize the social welfare.Obviously, this framework has achieved its main goal which is the ability to adjust resource allocation based on the dynamicity of resource prices. But the proposed algorithm is very complicated and can generate a huge overhead in the network, especially when the number of players (SPs) that are competing for resources is important, in this case the convergence of the proposed algorithm can take time. In addition, algorithms proposed in case of single SPs or multiple SPs do not take into consideration the difference between price models used in different DCs while solving the placement problem, which can have an important impact on the stable outcome of this competition. Finally, this work does not take into account the minimization of the total energy consumption while allocating resources to different SPs, it just consider the load balancing as a main objective. SD-WAN There are two approaches to build an SD-WAN network: Google’s approach (Jain et al., 2013) which is to design the network from scratch as a SD-WAN network with OpenFlow switches and a centralized controller and the second approach is Microsoft’s approach (Hong et al., 2013) which is to build SD-WAN on the top of the existing network. The second approach is more complicated because, in this case, there is a need to add network elements (NE) (brokers or aggregators) in the existing topology in order to interconnect the infrastructure plane with the SDN control plane as shown in Figure 3.4. In our work, we adopt the second approach which aims to optimize resource allocation and to ensure efficiency, flexibility and scalability in Inter-DC WAN using existing resources (Gouveia et al., 2014) .
QoS for interactive application MCTEQ takes into consideration explicitly the constraint of delay for interactive traffic. The end-to-end delay on a given path is characterized by the sum of the propagation delays for all the links and the queuing delays for all the nodes on the path (Wang et al., 2014). In fact, propagation delay is simple to compute, however, queuing delay is more complicated because it depends on various factors such as bandwidth allocated in each link and scheduling policies used in each link. That’s why there is a need to bound the queuing delay for interactive flows. This work assumes that the service discipline used on all devices in the network is guaranteed rate (GR) schedulers. Based on this assumption, the end-to-end delay of each packet can be bounded. To guarantee QoS requirement for interactive flows in terms of delay, it is about ensuring that the end-to-end delay respects a tolerable delay bound. This constraint must be respected when a fraction of an interactive flow ݅ use a specific path . That’s why it is primordial to use a Boolean parameter to indicate paths usage by different flows in the network.primordial to use a Boolean parameter to indicate paths usage by different flows in the network.
|
Table des matières
CHAPTER 1 INTRODUCTION
1.1 Context
1.2 Problem statement
1.3 Research questions
1.4 Objectives
1.5 Hypothesis
1.6 Research originality
1.7 Plan
CHAPTER 2 BACKGROUND AND MOTIVATIONS
2.1 Introduction
2.2 Traditional solutions for Inter-DC WAN
2.2.1 Layer 3 Virtual Private Network: L3 VPN
2.2.2 Multi-Protocol Label Switching Traffic Engineering: MPLS-TE
2.2.3 VPN over MPLS
2.2.4 VPLS
2.3 Software Defined Networking
2.3.1 Overview
2.3.2 SDN protocol: OpenFlow
2.3.3 Contributions of SDN
2.4 Comparative study between traditional solutions for Inter-DC
2.5 Conclusion
CHAPTER 3 RELATED WORKS
3.1 Introduction
3.2 Virtual WAN
3.2.1 DSPP
3.2.2 ViNEYard
3.3 SD-WAN
3.3.1 Google’s solution B4
3.3.2 Microsoft’s solution: SWAN
3.3.3 SDN-based multi-class QoS-guaranteed inter-data center traffic management
3.3.4 Delay-Optimized video traffic routing
3.4 Comparative study between existing solutions for DCs interconnection
3.5 Conclusion
CHAPTER 4 METHODOLOGY
4.1 Introduction
4.2 Throughput maximization modeling
4.3 Energy consumption modeling
4.3.1 The fully proportional model for energy consumption
4.3.2 The idle model for energy consumption
4.3.3 The agnostic model for energy consumption
4.3.4 Discrete step increasing model for energy consumption
4.4 MPLS network modeling
4.5 Optimization model
4.5.1 Objective function
4.5.2 Constraints
4.6 Deterministic solution
4.7 Greedy heuristic
4.8 Conclusion
CHAPTER 5 RESULTS AND VALIDATION
5.1 Introduction
5.2 Validation protocol
5.3 Implementation and test
5.3.1 Test with SWAN topology
5.3.2 Test with NSF topology
5.3.3 Impact of the energy consumption model in the optimization model
5.3.4 Large scale cloud services
5.3.5 Implementation of the greedy heuristic
5.4 Conclusion
CONCLUSION
BIBLIOGRAPHY
Télécharger le rapport complet
