# GANA-VDC: Application-Aware with Bandwidth Guarantee in Cloud Datacenters
## 4 GANA-VDC System Architecture  
The GANA-VDC model provides a guaranteed bandwidth a VDC specifies and supports more fine-grained VDC service traffic control. This system is built based on Portland layer-2 fabric considerations. Contrary to Portland [16], in our underlying physical network topology, we use interconnected OpenFlow switches instead of commodity switches. The main work of GANA-VDC implemented in the hypervisor contains four main components (Figure 4):  
1. Forwarding Pattern Dispatcher component
2. Flow Split component
3. OpenFlow component
4. Source routing component  
Figure 4: GANA-VDC system architecture. Figure 3: GANA Switch-Centered VN to PN mapping. **Forwarding Pattern Dispatcher:** Two forwarding patterns are provided in GANA-VDC where tenants can determine which pattern to use. A parameter passed to Forwarding Pattern Dispatcher component marks the forwarding pattern. Subsequently, GANA-VDC forwards tenant traffic. **Flow Split:** In accordance with Clos network theory [36], since Portland epitomizes a de facto rearrangeable non-blocking network, a non-negligible amount of bandwidth is lost to the collisions on a longer time scale through the number \(k^{2}/4\) of paths existing between possible sources and possible destinations where an ECMP-style of flow hashing is leveraged [1]. Nevertheless, if one carefully schedules the packets sent through possible paths, one can achieve a non-blocking situation. Nevertheless, this remains a challenging problem. To alleviate network blocking, we assume any flow can be split into several smaller flows; the Flow Split component is designed to implement that. The main technique of splitting flow depicts Multipath TCP (MPTCP) [37]. A Sender must segment and then distribute across multiple sub-flows transmitting a data stream to MPTCP by a VM source. It then must be reassembled into a single data stream before delivering it back to the destination VM. To split flow and define how many sub-flows, we modify the multipath congestion control algorithm in MPTCP in light of the global status of underlying physical network resource utilization. We merely split best-effort flow service with no bandwidth guarantee to achieve an actual non-blocking network, but that discussion will be reserved for future work. **OpenFlow:** The OpenFlow component operates according to SDN specifications. Tenants use OpenFlow to control flowtable to offer intra-VDC fine-grained QoS. When different VDCs follow the same devices for forwarding purposes, a conflict in the flowtable entries results due to associated application interference. Consequently, we introduce sub-component named _VN Tagging_ to distinguish tenants flow entries. However, if the VLAN ID field is used for writing 12-bit-long VN-ID, only allowing up to 4094 VLANs, this proves insufficient for such a large-scale cloud data center. Temporarily, we define a VN-ID, as 24-bit label, which is stored in IPv4 header options. At the same time, the addition of the VN-ID information extends the flowtable. Tenants demanding fine-grained traffic control is feasible and efficient in practice. Moreover, this component displays a prerequisite to provide fine-grained traffic control by leveraging the OpenFlow v1.3 protocol [18] standard with already added Meter/Band functions to support various simple QoS operations, such as rate limitation, QoS remarking, or packet drop functionalities. A meter measures the packets rate assigned and enables packets control rates. When installing flows, a tenant controller can attach meters directly to each flow entry as opposed to queues associated with ports. Data plane traffic generated based on matching endpoints ensure the switch strictly forwards traffic based on the configured meter rate. **Source Routing:** Source routing is considered an inefficient and expensive networking technology.