TLEN 5710 Capstone. Final Paper. Date 4/25/2014. Defining a Routing Architecture for Multi-Tenant Virtual Data Centers to support Host.

Transcription

1 TLEN 5710 Capstone Final Paper Date 4/25/2014 Defining a Routing Architecture for Multi-Tenant Virtual Data Centers to support Host Migration Members - Amit Kolekar, Ebin George, Deepak Pishe, Dipesh Rathod Faculty Advisor Dr. David Reed Industry Advisor Mr. Richard Pomrenke (Principal Architect, CenturyLink)

2 Abstract The tremendous increase in video content and cloud based services over the Internet has led to an increasing demand for storage, bandwidth, and computational requirements in data centers. New business models are emerging where cloud providers offer data center services through the cloud, also known as Infrastructure as a Service (IaaS). This business model has led to the emergence of virtual data centers, which are similar to traditional data centers except that tenants connect to virtual networks. The IETF working group Network Virtualization Overlay (NVO3) defines the operational and architectural requirements for such multi-tenant virtual data centers. One of the key requirements is the ability to do host migration between geographically separate data centers in an efficient manner. Currently, there are a number of limitations for host migration, e.g. the need for layer 2 interconnects between data centers and the issues that arise with triangular routing. This paper uses a Locator Identity Separation Protocol (LISP) based model to design a routing architecture for multi-tenant virtual data centers to eliminate the current problems associated with Host Migration. ii

3 Table of Contents I. INTRODUCTION... 1 I. STATEMENT OF THE PROBLEM... 1 II. BASIC LISP CONCEPTS... 3 a. LISP Control Plane... 3 b. LISP Data Plane... 3 III. RESEARCH QUESTION... 4 II. LITERATURE REVIEW... 5 III. RESEARCH METHODOLOGY... 7 I. SCOPE AND ASSUMPTIONS... 7 II. METHODOLOGY... 8 IV. RESEARCH RESULTS V. DISCUSSION OF RESULTS I. ADVANTAGES II. COST-ANALYSIS OF DEPLOYMENT VI. CONCLUSIONS AND FUTURE RESEARCH VII. REFERENCES iii

4 Acknowledgments We would like to acknowledge our advisors Prof. David Reed and Mr. Richard Pomrenke for their support and guidance through the course of this capstone. We would like to specially acknowledge Prof. Mark Dehus for providing us with the infrastructure needed to create the test bed and for his suggestions and ideas. We would also like to acknowledge the support of Prof. Jose Santos through the course of the capstone. We would like to acknowledge the help of Mr. Peter Brecl in the cost analysis of our LISP-based model. We would like to specially mention the names of Mr. Dino Farinacci, Mr. Eric Gray, Mr. David Mayer and Mr. Damien Saucez who work with the LISP working group and NVO3 working group, for taking the time to answer our questions in spite of their busy schedules. iv

5 I. Introduction i. Statement of the Problem The explosion of video content and cloud-based services over the Internet has led to increasing demand for storage, bandwidth and computational requirements in data centers [1]. New business models are emerging where content providers are looking to outsource traditional data center services to cloud providers. This model reduces operational costs, improves application deployment time and offers scalable solutions for the ever increasing bandwidth and storage requirements [2]. In order to achieve this, cloud providers use server virtualization, where each physical server runs multiple Virtual Machines (VMs) capable of running their own operating systems, hosting applications and even acting as virtual routers or switches. Server virtualization provides advantages like reduced power usage, increased security and lower user downtimes [3]. This has led to the emergence of virtual data centers, which are much like the traditional data centers except that tenants connect to virtual networks, not physical networks [4]. The IETF working group Network Virtualization Overlay (NVO3) defines the operational and architectural requirements for such multi-tenant virtual data centers. One of the key requirements is the ability to do host (VM) migration between geographically separate data centers. Host migration refers to the process of moving a virtual machine from one data center to the other such that the critical network state, including IP and MAC address, is preserved. This is needed to keep existing TCP connection from breaking and having to restart[3] This has advantages in applications such as disaster recovery, infrastructure scalability, data center maintenance etc. 1

6 One of the limitations with host migration today is that the server can only be migrated to locations within its own IP subnet. This is achieved by building layer 2 tunnels/interconnects between data centers for each customer subnet. This solution is neither scalable nor cost-effective. For a truly scalable multi-tenant virtual data center, the host should be able to migrate to any location independent of the subnet boundaries [3]. Another issue with host migration nowadays is triangular routing. Figure 1 - Triangular Routing Figure 1 illustrates how packets are transmitted in an asymmetric pattern during triangular routing. Consider that a VM is migrated from data center A to data center B. Now, the request packets traverses through link X and link Y before reaching VM1. In absence of a firewall, the response packets are sent back through link Z, thus forming a triangle. However, in the presence of a firewall, the response packets are sent through link X and link Y.[5]. The NVO3 working group makes the case that overlay-based solutions have advantages over traditional non overlay-based solutions to support their requirements [3]. LISP is an emerging overlay-based solution, which can address the architectural requirements of a virtual data center, 2

7 especially in the context of VM live migration [3]. LISP is an open IETF standard which was initially proposed as a solution to reduce the size of the Internet routing table. Many other applications for LISP have emerged such as multi-homing, mobility and VM live migration [6], however it has not been used in the field of data center networking. The basic functionality of the LISP protocol in the context of this capstone will be described in the next section. This paper seeks to extend the use-cases of LISP into data center networking. We propose a solution which is incrementally deployable, scalable and can address the requirements of host migration for multi-tenant virtual data centers. ii. Basic LISP Concepts a. LISP Control Plane The basic concept of LISP architecture is separating a device s identity from its location. Each end host device is identified by an endpoint identifier (EID) and is associated with a routing locator (RLOC). EIDs and RLOCs are just IP addresses, and RLOCs are globally routable. The LISP control plane consists of a map server (MS) that contains records of all EIDs mapped to their corresponding RLOCs. RLOCs are responsible for periodically updating MS with the EIDs associated with them [6]. b. LISP Data Plane When a host in a LISP site wants to communicate with a host in another LISP site, it sends the packet out to its own gateway, which acts as the Ingress Tunnel Router (ITR). This ITR queries the Map Resolver (MR) to find the RLOC associated with the destination host EID. The MR consults MS to resolve this query and replies back to the ITR. This packet is then encapsulated by 3

8 the ITR and forwarded to the corresponding RLOC of the destination LISP site. When the destination RLOC receives this packet, it acts as an Egress Tunnel Router (ETR) and decapsulates it. Finally, it forwards the decapsulated packet to the destination EID. The roles of the ETR and ITR are reversed for the return traffic. Thus, these routers are referred to as xtr. Now, when a host from a non-lisp site attempts to communicate with a host in a LISP site, it sends the packet to its gateway. In this scenario, the routing is performed in such a way that this packet reaches Proxy Ingress Tunnel Router (PITR) from the gateway. The PITR now acts as an ITR for non-lisp sites. The return traffic is forwarded natively to the non-lisp host. 3 1 EID host A initiates connection to EID host X 2 ITR sends a request to MR for RLOC id associated with EID host X MR performs a RLOC lookup and if it fails, it requests MS for the RLOC MS 5 ETR decapsulates the LISP header and performs routing to forward the packet to its destination EID Host A /24 MR / SA: S-RLOC: D-RLOC: DA: ITR SA: SA: DA: ETR DA: EID Host X After learning the Remote RLOC, ITR RLOC: encapsulates the RLOC: packet with RLOC header and forwards it to the ETR Figure 2 - LISP working iii. Research Question Based on the problem setting described, the question that this capstone tries to answer is the following To design an optimal routing architecture for Multi-tenant Virtual Data Centers (M- 4

9 VDC), to support the requirements for host mobility as mentioned by the NVO3 IETF working group. In this paper, we break down the research question to focus on the following sub-problems 1. Support VM live migration to any other location (across subnet boundaries), without change to VM network state or causing service disruption 2. Optimize the current implementation of VM live migration by eliminating triangular routing and the need for layer 2 tunnels between two data centers for production traffic. 3. Analyze the tradeoff between costs incurred and benefits gained by deploying a LISP-based solution. II. Literature Review The rate at which data centers are being deployed globally is increasing exponentially. However, these data centers use a blend of proprietary and standard architectures. Thus, it is important to standardize the architecture of data centers. The NVO3 working group has proposed an IETF draft with regards to the same [3]. The draft mentions many key requirements in order to achieve standardization. IETF working group [3] justifies the use of overlay-based networks to meet these requirements. It identifies protocols like LISP, BGP/MPLS VPNs, Provider Backbone Bridging (PBB), Overlay Transport Virtualization (OTV), Virtual Extensible LAN (VxLAN) and various others as possible multi-tenant virtual data center architectures [3]. [7] provides a framework for data center network virtualization over layer3 tunnels. NVO3 problem statement identifies seamless host migration as one of its major requirements. 5

10 Cloud providers currently use technologies like OTV, VxLAN and the traditional layer 2 tunneling protocol (L2TP) to achieve host migration. OTV extends the Ethernet networks from one data center to the other by building a point-to-point OTV tunnel [8]. The most important requirement for OTV to work is to maintain IP connectivity between both the endpoints of the OTV tunnel [8]. Each OTV tunnel can be used for forwarding customer s production traffic as well as VMware s high availability traffic, however OTV adds around 42 bytes of overhead which can cause unnecessary fragmentation [9]. Also, OTV is Cisco proprietary. VxLAN is an open standard which is supported by all major device manufacturing companies. It uses a 24 bit field VxLAN identifier enabling 16 million VLANs [10]. The layer 2 interconnect is achieved via establishing connectivity between VxLAN Tunnel End Points (VTEP). However, VxLAN spanned layer 2 interconnect requires a vshield edge or a Vyatta router to communicate outside its subnet [10]. L2TP is a traditional way of deploying layer 2 interconnects across two or more data centers. L2TP requires a dedicated interface to connect the LAN segment that needs to be spanned across other datacenter and another interface for traffic flow to other subnets. In addition to L2TP, a bridged GRE tunnel can also be used to extend layer 2 across two data centers. However, bridging with GRE tunnel is not recommended because of issues like loop occurrence and ARP failures. Both L2TP and GRE only support a maximum of 4096 VLANs. All the problems mentioned above can be eliminated by using LISP. The LISP protocol is defined in RFC 6830[11] and has been standardized by IETF drafts [6] and [12]. The general design considerations for LISP are mentioned in [13]. A survey of mapping systems for LISP routing have been done in [14]. LISP Delegated Database Tree (LISP-DDT) is 6

11 the current mapping system [14]. The work done in the area of Inter-Domain routing using LISP include [15] and [16] and these focus primarily in the core routing architecture of ISPs. [15] focuses on using LISP as an Internet routing architecture that reduces the size of routing table. An analysis of security threats to LISP have been investigated in [17]. [18] focuses on adding an extension to the LISP Protocol to support sub-second downtime during VM live migration over the Internet. There has not been any work done on using LISP for multi-tenant virtual data centers. This capstone aims to use LISP as a possible solution to address the current problems associated with host migration, and to come up with the standardized architecture for multi-tenant virtual data centers based on NVO3 requirements. III. Research Methodology i. Scope and Assumptions There is a layer 2 interconnect between the two data centers for VMotion and Fault Tolerance to occur. The speed of the layer 2 interconnect would determine the rate at which VMotion and Fault Tolerance occurs. The design does not consider redundancy at the edge router level, i.e. we consider only one xtr at each data center site. However, in real production networks, xtr should be deployed in redundant pairs running a redundancy protocol like HSRP or VRRP. The design does not consider redundant storage. However, in production networks, redundant storage is recommended. Also, the design has both data centers connected to the same simulated ISP. Nevertheless, the solution is designed to work even if both data centers are connected to different ISP networks, as long as there is IP connectivity between the edge routers. 7

12 ii. Methodology The research methodology is divided into two phases. Phase 1 consists of designing a test bed to simulate the test environment. Phase 2 comprises of deploying LISP specific configurations to achieve results for sub-problem 1 and sub-problem 2. The costs analysis of this LISP based solution, i.e. sub-problem 3 is covered under the Discussion of Results section. Phase / / /24 MS/MR Cisco /31 PITR Cisco / /31 Non LISP site Host / /31 ISP- EDGE- 01 Cisco 7200 ISP Network Cisco 7200 ISP-EDGE / / / / / /32 CSR 1000v DC_A_Gateway DC_B_Gateway CSR 1000v / /24 Data Center A Data Center B Figure 3 - Capstone test bed This phase comprises of setting up a test bed to simulate a real life scenario where host migration is required. Due to resource constraints, we opted to go with a simulation which runs in a virtual 8

13 environment. Also, the test bed was designed with the goal of incremental deployment. We consider a basic scenario where a cloud provider has two data centers that are geographically separated. We used two EXSi hosts to simulate two LISP-aware data centers, connected to a simulated ISP network. Two Dell PowerEdge R620 servers running Intel Xeon(R) CPU 2.90GHz were used for the same. A concern for new cloud providers is initial deployment where communication between a non-lisp site and a LISP site becomes crucial. Therefore, we also included a non-lisp aware site which simulates the rest of the Internet. As shown in Figure 3, the edge router for each LISP site is the CSR-1000v, running IOS XE version csr1000v-universalk s s-std, which acts as the xtr for the site. CSR- 1000v is a virtual router, i.e. it can be deployed like a virtual machine. Premium license is required on the CSR-1000v routers in order to support LISP functionality. We used the 60 day premium evaluation license provided by Cisco. A Cisco 7200 router acting as both the MS and MR was connected to the simulated ISP network. Also, another Cisco 7200 acting as a Proxy ITR was connected to the same. The idea was to simulate the functionality of MS/MR and Proxy ITR virtually due to resource constraints. So, we selected the Cisco 7200 router running IOS version c7200-advipservicesk9-mz m5, as it can be simulated on GNS3 and supports LISP feature. Appropriate routing was configured inside the ISP network to ensure IP connectivity between MS/MR, xtrs and the Proxy ITR. We ensured that the traffic from non-lisp site towards the LISP site is routed via the Proxy ITR. We also created 10 VMs which were Fault Tolerance enabled across the two data centers. 9

14 Phase 2 In order to solve Sub-problem 1 and Sub-problem 2, we enabled LISP on top of the simulated network. There are three key components which were configured xtr, MS/MR and PITR. The following are the steps to do the same: 1. Configure the following commands on Cisco CSR-1000v to enable it as an xtr. The configuration snippets below are only from xtr at data center A. Similar configurations are present on the xtr at data center B as well. Enable ITR capability and specify the IP address of the MR to query the authoritative RLOC for the destination EID. ipv4 itr ipv4 itr map-resolver Enable ETR capability and specify the IP address of the MR to register the IP subnet for which the RLOC is authoritative. Also, configure an authentication key to validate the MS. ipv4 etr ipv4 etr map-server key capstone Configure the IP address of RLOC. router lisp locator-set RLOC priority 1 weight 50 Specify the IP subnet for which the RLOC is authoritative. In our scenario, DC_A_Gateway is authoritative for /16 and DC_B_Gateway is authoritative for /16. router lisp database-mapping / priority 1 weight

15 Specify the dynamic EIDs, i.e. the IP subnet of the hosts that will be mobile in both the datacenters. This will be a subset of the subnet for which xtr is authoritative. The xtr will keep track of the dynamic EID hosts that are active in its datacenter. If a host moves out or else a new host moves in, it will update the MS. router lisp dynamic-eid LISP_ACROSS_SUBNET database-mapping /24 locator-set RLOC dynamic-eid LISP_ACROSS_SUBNET_2 database-mapping /24 locator-set RLOC The interface facing the data center on the xtr is configured to monitor the above specified dynamic EIDs. interface GigabitEthernet1 ip address negotiation auto lisp mobility LISP_ACROSS_SUBNET lisp mobility LISP_ACROSS_SUBNET_2 The interface facing the data center on the xtr requires a static MAC address. This is to ensure that once the host migrates to a new data center, there is no change to its ARP cache. If the host s ARP cache expires, the xtr should respond to ARP requests from a host in a different subnet. For this, the command ip proxy-arp should be enabled on the interface. interface GigabitEthernet1 mac-address abcd ip proxy-arp 2. Configure the following commands on Cisco 7200 so that it acts as the MS/MR - Enable MS/MR capability. ipv4 map-server ipv4 map-resolver Specify the LISP sites which will register with this MS, along with the authentication key. router lisp site DC_A authentication-key capstone eid-prefix /16 accept-more-specifics 11

16 site DC_B authentication-key capstone eid-prefix /16 accept-more-specifics 3. Configure the following commands on Cisco 7200 so that it acts as the Proxy ITR - Enable Proxy ITR capability and specify the IP address of the MR which will be queried while encapsulating a data packet. router lisp ipv4 proxy-itr ipv4 itr map-resolver Specify the IP subnet of the EIDs that this Proxy ITR should expect. If any packets with destination IP address from these subnets arrive at the PITR, it will act as ITR thereby enabling non LISP sites to communicate with these subnets. router lisp map-cache /16 map-request map-cache /16 map-request IV. Research Results The LISP-based model solves sub-problem 1 and sub-problem 2. This section discusses the results and the working of this model. Each data center has five EIDs associated with their respective xtr. As shown in Figure 4 and 5, hosts are associated with DC_A_Gateway, and hosts are associated with DC_B_Gateway. Figure 4 - Output of 'show lisp dynamic-eid summary' on DC_A_Gateway 12

17 Figure 5 - Output of 'show lisp dynamic-eid summary' on DC_B_Gateway The xtr will keep track of the dynamic EID hosts that are active in its datacenter. If a host moves out or else a new host moves in, it will update the MS using Map-Register message. Map-Register is a LISP-control message which ITR sends to MS in order to register or drop the EIDs, along with the IP address of the authoritative RLOC. In Figure 6, we can see that DC_A_Gateway has updated MR that it is authoritative for /16 and hosts which are part of the same subnet. Similarly, DC_B_Gateway has updated MR that it is authoritative for /16 and hosts which are part of the same subnet. Figure 6 - Initial EID to RLOC mapping on MS/MR 13

18 Now, let us see how a packet from a non-lisp site reaches the host in a LISP site ( ). As shown in Figure 7, the path that the packet takes is via i.e. DC_A_Gateway, where the host resides. Figure 7 - Initial traceroute from PITR to Now, let s migrate the host from data center A to data center B. As shown in Figure 8 and 9, the host is now associated with DC_B_Gateway. Figure 8 - DC_B_Gateway shows the newly learned EID /32 Figure 9 - DC_A_Gateway no longer has the EID /32 After DC_B_Gateway detects the migration, the following set of events occurs: 14

19 DC_B_Gateway sends a Map-Register message to MS stating that it is authoritative for EID and the host can be reached via RLOC DC_A_Gateway sends a Map-Register message to MS stating that it is no longer authoritative for EID MS sends Map-Notify message to DC_B_Gateway and DC_A_Gateway as an acknowledgement to their Map-Register message. The updated mapping can be seen in Figure 10, where the registration for host is by Figure 10 - Updated mapping on MS/MR after the host is migrated to data center B DC_A_Gateway sends a Solicited Map-Request message to PITR. This message is sent so that in spite of having the EID and RLOC mapping for , the PITR initiates a new Map- Request to find the RLOC for the EID PITR then sends an Encapsulated Map-Request for to MR. This message is to obtain the new RLOC for EID

20 MR then forwards this Encapsulated Map-Request to DC_B_Gateway, which responds to the PITR directly by sending a Map-Reply. This message informs that the EID can be reached via RLOC , and that DC_B_Gateway is the authoritative xtr for the same. After PITR receives the Map-Reply message, it updates its map-cache. As seen from the traceroute in Figure 11, the path that packet takes now is via i.e. DC_B_Gateway, where the host is located after migration. Figure 11 Trace route from PITR to after migration While the above test was performed, a file transfer was initiated from non-lisp site host to EID The state of the VM was preserved during the migration and file transfer continued without any interruption. Also, it was observed that once the hosts are completely migrated, only in-flight packets to data center A are lost before LISP converges, and PITR starts sending the packets to data center B. Thus, we can say that we were able to successfully perform VMotion across subnet without any change in state of the VM and preserve all the TCP connections currently active on the VM. Also the traceroute results show that after migration, PITR successfully updates its mapping to the new RLOC. Now, PITR forwards the packets destined for EID to DC_B_Gateway directly, eliminating triangular routing. 16

21 V. Discussion of Results i. Advantages The ability to perform VM live migration without subnet restrictions is a significant advantage to cloud providers. Current implementations of VM live migration has the restriction that VM can only be moved to the same IP subnet. Due to this, a layer 2 tunnel would have to be provisioned by the cloud provider for each subnet per customer. This adds complexity for the cloud provider while provisioning new customers. Our model eliminates this requirement, thereby increasing flexibility and saving time while provisioning new customers. VMware has a requirement that to perform Fault Tolerance, the physical ESXi hosts should be a part of same IP subnet. Thus, we cannot avoid a layer 2 interconnect for the VMotion control plane specific traffic. Generally, cloud providers would lease a dedicated line from the ISP for this purpose. Due to triangular routing in current implementations, the customer s production traffic would also flow through this leased line, which is supposed to be dedicated for VMotion control traffic only. An advantage of our solution is the fact that we eliminate the flow of production traffic through the layer 2 tunnel. This means that the cloud provider would reduce costs by leasing a dedicated line of smaller bandwidth. Or, the same high bandwidth line can be used to provide more Fault Tolerant VMs for customers. The elimination of triangular routing also decreases the overall latency in the communication path, because the Request/Response does not have to go till the data center core router and through the tunnel each time. This becomes critical for latency sensitive applications. Consider an example of two data centers separated by a distance of about 1000 miles ~ 1600kms. Assume that they are connected by an optical fiber provided by an ISP. Due to triangular routing, in a simple case, the 17

22 round trip distance that would be added because of the tunnel is 1600*2 kms (Request + Response). We can calculate the propagation delay in this scenario as (Total Distance/Speed). The speed of light through optical fiber is about 2*10 8 m/s (Refractive Index of glass ~ 1.5). Thus, we end up with total propagation delay of about ((1600*2*10 3 )/ (2*10 8 )) = 16 milliseconds. Packets flowing through the tunnel also incur serialization and queuing delays in addition to the propagation delay. In case of latency sensitive applications, this total delay amounts to a substantial loss of revenue. ii. Cost-Analysis of deployment This section analyzes the costs associated with deploying such a solution. We first conducted a performance analysis to understand the impact of LISP on CPU utilization. We did the analysis on the MS/MR as it would be the router that has maximum amount of state among all the LISP devices. The graph in Figure 12 shows that LISP process does not impact the overall CPU utilization. Thus, LISP is not a CPU intensive process. Figure 12 - CPU Utilization vs Time In order to perform cost analysis, we assume that a cloud provider has two data centers geographically separated. Also, they have customers with critical fault tolerant VMs that require 100% uptime and 1 Gbps connection to the Internet. The provider would need to lease a dedicated 18

23 line from an ISP to provision one layer 2 tunnels between the data centers for Fault Tolerance specific traffic. During capacity planning for a disaster scenario, the cloud provider would need to provision another layer 2 tunnel for each customer s production traffic. The cost of such a dedicated line is around $12000 per year per 1 Gbps connection[19]. Thus, in case of a non-lispbased solution, for each new customer that is added, the cost involved with provisioning a new tunnel for its production traffic will be $12000 per year per 1 Gbps connection. This cost is in addition to factors like man power associated with provisioning and maintenance of new tunnels for each new customer. As the number of customers increase, the cloud provider will incur this incremental cost to lease larger bandwidth and invest more resources on tunnel maintenance. Also, during the disaster scenario, the network latency increases. Thus, the cloud provider will not be able to attract customers having latency sensitive applications. Let us now run LISP on top of this network. The first hop router attached to each customer subnet would have to be LISP enabled. The first hop router can be a Cisco CSR-1000v or Nexus 7000k depending on factors like the number of customers, total throughput required, and business needs. The MS/MR can be a router like the Cisco This network would require a pair of xtrs at each data center site, and a pair of MS/MR for the sake of redundancy. The initial costs of deploying the solution involve buying and provisioning these routers. However, when new customers are added, the cloud provider does not need to worry about planning, provisioning and maintenance of layer 2 tunnels for each customer subnet for the production traffic. Thus, new customers can be provisioned much faster. Also, the cloud provider does not need to lease higher bandwidth from the ISP. Thus, the incremental cost for each new customer is significantly lesser. 19

24 Unlike the previous case, the cloud provider can attract the section of customers having latency sensitive applications. In summary, a LISP-based solution will save the incremental cost incurred traditionally while deploying new customers. Also, the advantage of decreased latency will help attract new customers, which is an indirect cost benefit. Both these factors together will outweigh the initial deployment costs. VI. Conclusions and Future Research The LISP-based model successfully eliminates the current problems associated with host migration between data centers. We solved the following Support VM live migration to any other location (across subnet boundaries), without change to VM network state or causing service disruption Optimize the current implementation of VM live migration by eliminating triangular routing and the need for layer 2 tunnels between two data centers for production traffic. The LISP-based model will best serve a new entrant since it has a high initial deployment cost and low incremental cost per customer. In addition, existing cloud providers can migrate to a LISPbased solution if the expected increase in customers outweighs initial deployment costs. The future research includes performance analysis of the model using physical devices in a lab environment before deploying it in production. Other areas that can be explored are scalability and the working of LISP with firewalls at each site. The LISP based model can also be used as a possible solution to meet the other requirements of the NVO3 working group. 20

25 VII. References [1] N. Bitar, S. Gringeri, and T. J. Xia, Technologies and protocols for data center and cloud networking, IEEE Commun. Mag., vol. 51, no. 9, pp , [2] D. Cai and S. Natarajan, The Evolution of the Carrier Cloud Networking, in 2013 IEEE 7th International Symposium on Service Oriented System Engineering (SOSE), 2013, pp [3] M. Napierala, L. Kreeger, T. Narten, D. Black, E. Gray, and L. Fang, Problem Statement: Overlays for Network Virtualization, 31-Jul [Online]. Available: [Accessed: 17-Oct- 2013]. [4] M. Gurusamy, T. N. Le, and D. M. Divakaran, An integrated resource allocation scheme for multi-tenant data-center, in 2012 IEEE 37th Conference on Local Computer Networks (LCN), 2012, pp [5] T. Sanguankotchakorn and P. Jaiton, Effect of Triangular Routing in Mixed IPv4/IPv6 Networks, in Seventh International Conference on Networking, ICN 2008, 2008, pp [6] N. J. Chiappa, An Architectural Introduction to the LISP Location-Identity Separation System, Oct [Online]. Available: [Accessed: 17-Oct-2013]. [7] F. Balus, T. Morin, Y. Rekhter, M. Lasserre, and N. Bitar, Framework for DC Network Virtualization, 12-Nov [Online]. Available: framework-04. [Accessed: 01-Dec-2013]. [8] V. Moreno, D. Farinacci, D. Rao, and H. Grover, Overlay Transport Virtualization. [Online]. Available: [Accessed: 20-Apr-2014]. [9] Reply, Five Functional Facts about OTV packetmischief.ca.. [10] Digging Deeper into VXLAN, Part 1, - Cisco Blogs. [Online]. Available: [Accessed: 20-Apr-2014]. [11] D. Farinacci, D. Lewis, D. Meyer, and V. Fuller, The Locator/ID Separation Protocol (LISP), Jan [Online]. Available: [Accessed: 17- Oct-2013]. [12] N. J. Chiappa, An Architectural Perspective on the LISP Location-Identity Separation System, 16-Jul [Online]. Available: [Accessed: 18-Oct-2013]. [13] D. Saucez, L. Iannone, O. Bonaventure, and D. Farinacci, Designing a Deployable Internet: The Locator/Identifier Separation Protocol, IEEE Internet Comput., vol. 16, no. 6, pp , Nov [14] M. Hoefling, M. Menth, and M. Hartmann, A Survey of Mapping Systems for Locator/Identifier Split Internet Routing, IEEE Commun. Surv. Tutorials, pp. 1 17, [15] F. Coras, D. Saucez, L. Jakab, A. Cabellos-Aparicio, and J. Domingo-Pascual, Implementing a BGP-free ISP core with LISP, 2012, pp [16] X. Misseri, J.-L. Rougier, and D. Saucez, Internet routing diversity for stub networks with a Map-and-Encap scheme, 2012, pp

26 [17] D. Saucez, O. Bonaventure, and L. Iannone, LISP Threats Analysis, 29-Aug [Online]. Available: [Accessed: 18-Oct- 2013]. [18] P. Raad, G. Colombo, D. P. Chi, S. Secci, A. Cianfrani, P. Gallard, and G. Pujolle, Achieving sub-second downtimes in internet-wide virtual machine live migrations in LISP networks, in 2013 IFIP/IEEE International Symposium on Integrated Network Management (IM 2013), 2013, pp [19] P. Brecl, Query of cost of a 1Gbps dedicated line between data centers, 18-Apr