# GANA-VDC: Application-Aware with Bandwidth Guarantee in Cloud Datacenters
## 4 GANA-VDC System Architecture
However, with SDN technology development, the source routing approaches utilizing the controller network topology knowledge has gained attention thanks to its ability to better scale the traditional hop-by-hop routing approach [38]. The source routing component consists of three sub-components: _forwarding_ sub-component is used to forward packets from VMs; _path selection_ sub-component consults the SDN controller and then makes a source routing choice; and _encapsulation_ sub-component principally refers to Netlord [27], combining with Portland, the second and third layer (L2 and L3), which are virtualized efficiently and completely, allowing tenants to benefit from a simple and flexible network abstractions, eventually providing tenants simple and flexible network abstractions. Contrary to Netlord [27], we set _MAC.src = PMAC(SRC)_, _MAC.dst = PMAC(DST)_; encapsulation and decapsulation details are ignored to build source-routing, leveraging the method proposed in [38]. We elaborate a model where OpenFlow switches are activated for source routing. In addition, to encapsulate the matched packet with a new header, a novel action is expanded. The latter is referred to as a path header and encompasses the particulars deciding the controller-informed path to follow. An efficient mechanism analog to SecondNet Port Switching approach [13] is chosen rather than opting for the MPLS label stack. Our path headers contain the roadmap of interface numbers deciding how the flow ought to be forwarded between intermediate switches. The flow path between Node Aand Node B is highlighted in Figure 5 for the packet headers containing the path as a sequence of interface numbers [34]. In GANA-VDC, we divide the system into two modules to implement the approach shown in Figure 4: Flow Rate Limiting Model (FRLM) and Link Bandwidth Guarantee Model (LBGM). _FRLM_ emphasizes fine-grained traffic control with respect to flow rate, and _LBGM_ focuses on coarse-grained traffic control with respect to bandwidth guarantee. We describe the actual tenant packet forwarding procedure of FRLM and LBGM as the directed dashed lines. **Flow Rate Limiting Module:** In Figure 4, the blue dashed lines indicate the forwarding sub-component receives the packets from tenant VM; VN Tagging sub-component writes the VN ID into the Ethernet header to distinguish VDC networks, and then forwards it to the physical OpenFlow switches. In a situation where one cannot find a match between an entry from the flowtable and the packet, the standard option transfers the packet to the controller via the control channel deciding based on rules of FlowVisor how the packet-Out message should install flow rules. If not, the corresponding instruction set is executed. **Link Bandwidth Guarantee Module:** The red dashed lines in Figure 4 signify that the forwarding sub-component receives the packets from the tenant VM. The path selection component will choose an appropriate path, which the packets should flow through its path storage. Initially, path storage does not contain the required path, therefore it will send a Packet-In message to VDC controller under the supervision of FlowVisor, and then the interceptor component translates the Packet-Out message and responds with a path message to the path storage instead of writing flowtables, thus the ensuing packets will follow this path. Finally, the encapsulation component encapsulates the packet, using a source routing protocol. When a server sends a packet, the encapsulation component invokes a call to the fabric manager in Portland [16] to learn the real destination switch location and tunnels the original packet in accordance with the source routing protocol. Thereby, this eliminates the ARP in layer-2 networks scalability problems.