Network Working Group J. Yang Internet-Draft Huawei Intended status: Standards Track H. Xu Expires: March 12, 2012 C. Li China Mobile Oct 3, 2011 States Migration Use Case draft-yang-opsawg-policies-migration-use-case-00 Abstract Draft I-D.gu-opsawg-policies-migration makes general problem statement on state migration in Data Center (DC). This use case draft is composed to introduce the states on network devices that need to be migrated with VM and the scenario that requires states migration. The authors of this draft make a survey among several DC providers to make sure the use cases introduced in this draft are real problem from these DC providers' perspective, instead of technology driven. The purpose of this draft is to figure out which states should be considered in the beginning stage of state migration effort. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Yang, et al. Expires March 12, 2012 [Page 1] Internet-Draft Use Cases Sep 2011 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 4 3. States need to be migrated for service continuity . . . . . . 4 3.1. States On Switches . . . . . . . . . . . . . . . . . . . . 4 3.1.1. DHCP Snooping . . . . . . . . . . . . . . . . . . . . 4 3.1.2. IPV6 ND Snooping and DHCPv6 Snooping . . . . . . . . . 6 3.1.3. Scenarios for Migration of States on Switch . . . . . 7 3.2. States On Firewalls . . . . . . . . . . . . . . . . . . . 10 3.2.1. Session Table . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Cumulative Data . . . . . . . . . . . . . . . . . . . 11 3.2.3. Scenarios for Migration of States on Firewall . . . . 12 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Normative Reference . . . . . . . . . . . . . . . . . . . 18 4.2. Informative Reference . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Yang, et al. Expires March 12, 2012 [Page 2] Internet-Draft Use Cases Sep 2011 1. Introduction Draft I-D.gu-opsawg-policies-migration provides a general statement of policies migration, introducing the background knowledge of VM Migration, the need for state migration and the states that might need to be migrated. However, there are lots of arguments on SAMI mail list on whether these states are really existing on DCs. Hence the authors of this draft make research on existing DCs, communicate with relevant providers and vendors and write down the use cases in this draft for everyone's reference. The difference between problem statement and use case draft is as follows: Problem statement draft introduce the basic information for state migration, e.g. a brief background introduction on VM migration, the states that might need to be migrated, and the problems that need to consider when migrate polices in Data Center. Use case draft lists the states that exist on current DCs, the brief information about each states and the scenarios of state migration. Use case draft provides a startup list of states for state migration effort. The authors have communicated with DC providers, Firewall vendors and network devices vendors. The IDC providers checked their Data Centers to make sure the functions and corresponding states introduced in this draft indeed exist in their DCs, and provide some particular network architectures that are used in their DCs, and the scenarios which could raise requirements for state migration among Firewalls. The authors also communicated with and get positive response from Firewall vendors that states on Firewall described in this draft are valid and their opinions on state migration. The solutions of state migration, though mentioned during communication, are not introduced in this draft. These use cases, including states and scenarios, are extracted from large amount of DC networks, but it doesn't mean the states must exist in every DC. It depends on many factors, e.g. the scale of the DC, for what purpose the DC is built, and the budget for DC networking. However, the authors believe the use cases are meaningful for some DC providers and state migration will be helpful for these DC providers to increase their service flexibility and save energy. Though there are a lot of scenarios discussion on VM migrating between two physical DCs, and there also exist some public technologies to solve VM migration between DCs, e.g.[Vmotion_between_DCs], this draft currently only introduce the state migration scenarios within the same DC. This is the real Yang, et al. Expires March 12, 2012 [Page 3] Internet-Draft Use Cases Sep 2011 scenarios the DC providers are facing. The authors would like to extend the scope when they have more real requirements on state migration between DCs. The structure of this draft is as follows: o Functions and corresponding states on Network devices. o The necessity to migrate these states. o The scenarios of state migration. 2. Terminologies and concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The document uses terms defined in [I-D.gu-opsawg-policies-migration] 3. States need to be migrated for service continuity For this version, the authors only considers state migration within in the same Layer 2 DC. The Layer 2 DC could be on a single physical location, or on separated physical locations interconnected by technologies like VPLS (, [RFC4761][RFC4762]), Overlay Transport Virtualization ([OTV]) and etc. The states introduced in this section are extracted from a survey on some DCs. In addition, the function and migration necessity of each state is described. The following states are described: o States on switches o States on Firewalls 3.1. States On Switches 3.1.1. DHCP Snooping In typical DC, where only servers are placed in it to serve external clients, public IP address are assigned to multiple tenants. Then the tenants might place a Load Balancer to balance the traffic among all the servers. In this case, there is no DHCP service. However, in new DCs which are expected to support Cloud Service, not only Yang, et al. Expires March 12, 2012 [Page 4] Internet-Draft Use Cases Sep 2011 enterprise servers are placed into DC, but also individual clients. It's not reasonable for DC provider to assign a public IP Address to each VM. A way to resolve this problem is to use DHCP server to assign IP Address to each VM. DHCP server can assign public addresses or private addresses. Or allow tenant to place his own DHCP server to assign public or private IP Address. Take Amazon VPC service as an example. [Amazon_VPC_User_Guide] All Amazon EC2 instances are assigned two IP addresses at launch: a private address (RFC 1918) and a public address that are directly mapped to each other through Network Address Translation (NAT). Private addresses are only reachable from within the Amazon EC2 network. Public addresses are reachable from the Internet. All Amazon EC2 instances are allocated a private address by DHCP. ARP Spoofing is a typical attack in network. When a host receives an ARP Reply message, even if the ARP Reply is not what the host is expecting, it will record the IP and MAC mapping information. This mechanism creates chances for ARP Spoofing. For example, communication happens between Host-A and Host-C through Switch1. Attacker Host-B forges ARP Reply to both Host-A and Host-C to make them update IP-MAC mapping information in ARP cache. That means, in Host-A, Host-C's IP address is mapped to Host-B's MAC, and in Host-C, Host-A's IP Address is mapped to Host-B's MAC. Then the traffic between Host-A and Host-C will be eavesdropped by Host-B. A common method to protect network from ARP spoofing is DHCP snooping. DHCP snooping learned IP and MAC pairs, as well as VLAN, lease time and port, from DHCP ACK message. This information is put into DHCP snooping table. Then switches can check DHCP snooping table to make sure the IP and MAC pairs in ARP reply are valid. A typical DHCP snooping table includes the following information: (A common form extracted from various products, e.g.[Cisco_DHCP_SNP] ) +---------------+---------------------------------------------------+ | Items | Interpretation | +---------------+---------------------------------------------------+ | IP Address | The IP Address of the host or VM | | MAC Address | The MAC Address of the host or VM | | VLAN | VLAN ID | | Remaining | The remaining time that this mapping is valid | | Time | | | Interface | The interface that the ARP reply message is | | | expected from. | +---------------+---------------------------------------------------+ Table 1: Items in DHCP Snooping Table Yang, et al. Expires March 12, 2012 [Page 5] Internet-Draft Use Cases Sep 2011 As far as the authors know, DHCP snooping function could be executed by the following way: 1. DHCP snooping on host: None of the popular Hypervisor announce to support DHCP snooping function. Cisco Nexus 1000v, a kind of virtual switch, announce to support DHCP snooping, as well as IP Source Guard and Dynamic ARP Inspection. [Virtual_Network_Features] 2. DHCP snooping on network devices (switches): Most, if not all, switch products support DHCP Snooping function. DHCP snooping on host is software based DHCP snooping function, which consumes CPU processing capability to execute DHCP snooping. The problem with this kind of solution is the same as its feature: Consuming valuable CPU processing, witch could otherwise by used to support more VMs. Another problem of this solution is that it's lack of widely support. As far as the authors know, only Cisco Nexus 1000v announces to support DHCP snooping, IP source guard and dynamic ARP inspection. If VM is migrating from a DHCP-snooping-embedded server to a non- DHCP-snooping-embedded server, the DHCP snooping function may fail and the following packet from the VM could be dropped by the new Hypervisor or network device, because it fails to find a mapping item between the IP address and MAC address of the VM. A DC provider may choose to deploy DHCP snooping function on virtual switch or network devices. No matter where DHCP snooping function is deployed, the DHCP snooping table item need to be migrated when VM is migrated. Of course, different kinds of deployment acquire different solutions. Since this draft is aiming at use cases for state migration, instead of solutions, we wouldn't go into so much detail of the solutions. 3.1.2. IPV6 ND Snooping and DHCPv6 Snooping IPV6 ND snooping and DHCPv6 snooping protects IPV6 network from forged IPV6 address. Both IPV6 ND snooping and DHCPv6 snooping filter packets according to the recorded IP address and MAC address of a host. The difference between IPV6 ND snooping and DHCPv6 snooping is on generation mechanism. The configuration mechanism of IPV6 address and the corresponding snooping table is listed below. Yang, et al. Expires March 12, 2012 [Page 6] Internet-Draft Use Cases Sep 2011 +-------------------------------------------------+-----------------+ | Configuration Mechanism | Snooping table | +-------------------------------------------------+-----------------+ | Static configuration | Static bindings | | | table | | Dynamic Host Configuration Protocol (DHCP) in | DHCPv6 snooping | | the stateful version | table | | Stateless Address Auto-Configuration (SLAAC) | ND snooping | | | table | +-------------------------------------------------+-----------------+ Table 2: IPV6_configuration_table Use of Stateless Address Auto-Configuration (SLAAC) where a Router Advertisement message announces the on-link prefixes as well as the link-local address of the router. The prefix is then combined with either the node link-layer address to form a EUI-64 address or with a random number to form a privacy extension address. In this case, the ND snooping item is generated based on the Neighbor Discovery Protocol (NDP).[RFC4861] The typical DHCPv6 snooping table and ND snooping table are the same as DHCP snooping table in previous section, except that the IP address in DHCPv6 is IPV6 address. 3.1.3. Scenarios for Migration of States on Switch Typical DC used to serve only enterprise customers, who put their servers into DC and provide services to external clients. But this is not the only case in DC, especially cloud DC. Cloud DC not only lease computing resource to enterprise customers but also individual users. Assuming 1000 individual users lease 1000 Virtual Machines (VM) in the DC. A DHCP server is placed in the DC and each VM needs to request for a IP Address before it can connect to the internet. In order to protect network from ARP spoofing, DHCP Snooping function is enabled on access switch. Yang, et al. Expires March 12, 2012 [Page 7] Internet-Draft Use Cases Sep 2011 ----------------------------------------------------------------------------- | | | Layer 2 Network | | | ----------------------------------------------------------------------------- | | | \ -------------- | | | \ |DHCP Server | | /DHCP snooping | /DHCP snooping | -------------- | / |/ | ----DHCP snooping ---------------- ---------------- ---------------- |Access Switch1| |Access Switch2| |Access Switch3| ---------------- ---------------- ---------------- | | | | | | ---------------- ----------------- ----------------- | VM1 VM2 VM3| | VM10 VM11 VM12| | VM19 VM20 VM21| | VM4 VM5 VM6| | VM13 VM14 VM15| | VM22 VM23 VM24| | VM7 VM8 VM9| | VM16 VM17 VM18| | VM25 VM26 VM27| ---------------- ----------------- ----------------- Figure 1: VMs distribution at day time At day time, the VMs are quite active, but at midnight, e.g. from 1am to 6am, most VM is inactive or shutdown. In order to save electricity power, DC providers collect the active VMs into a few physical servers. Because there are DHCP snooping function on access switch to deny unknown IP and MAC pairs, the packets sent from migrated VMs will be dropped. In order to keep running service, the DHCP snooping item on original access switches must be migrated to new access switches. Yang, et al. Expires March 12, 2012 [Page 8] Internet-Draft Use Cases Sep 2011 ----------------------------------------------------------------------------- | | | Layer 2 Network | | | ----------------------------------------------------------------------------- | | | \ -------------- | | | \ |DHCP Server | | /DHCP snooping | /DHCP snooping | -------------- | / |/ | ----DHCP snooping ---------------- ---------------- ---------------- |Access Switch1| |Access Switch2| |Access Switch3| ---------------- ---------------- ---------------- | * * | /\ | | *********************|************************ | ---------------- ----------------- ----------------- | 'VM1' 'VM3'| | 'VM12'| | VM1 VM3 VM12| | | | 'VM14' | | VM14 VM23 VM24| | 'VM8' | | 'VM16 | | VM8 VM16 VM27| ---------------- ----------------- ----------------- * * /\ * * * ******************************************************** ******** VM/States Migration Figure 2: VMs migration at midnight ----------------------------------------------------------------------------- | | | Layer 2 Network | | | ----------------------------------------------------------------------------- | | | \ -------------- | | | \ |DHCP Server | | /DHCP snooping | /DHCP snooping | -------------- | / |/ | ----DHCP snooping ---------------- ---------------- ---------------- |Access Switch1| |Access Switch2| |Access Switch3| ---------------- ---------------- ---------------- | | | | | | ---------------- ----------------- ----------------- | | | | | VM1 VM3 VM12| | | | | | VM14 VM23 VM24| | | | | | VM8 VM16 VM27| ---------------- ----------------- ----------------- Yang, et al. Expires March 12, 2012 [Page 9] Internet-Draft Use Cases Sep 2011 Figure 3: VMs migration Completion The scenario can easily be transformed to show the scenario of ND snooping. In ND snooping case, DHCP server is not used. Instead, the network devices generate the ND snooping table based on NDP. Of course, not all of the information in the states table needs to be migrated, e.g. the interface information in DHCP snooping table. 3.2. States On Firewalls There are many kinds of physical Firewall deployment in DCs. One is to place a pair of centralized powerful Firewalls at WAN connect point. In this case, any traffic, even the traffic between VMs within the same LAN, need to pass the Firewall. The second way is to place multiple pairs of Firewalls at aggregation switches. In this case, Firewall is usually used to separate different security zones, e.g. R&D zone, Finance Zone and Web service zone, etc. The third way is distributed deployed Firewall. In stead of place a powerful centralized Firewall at the WAN connect point, Firewall is distributedly deployed at aggregation switches, even lower on access switches. The goal of this kind of distributed deployed Firewall is not to separate different security zones, but to off load the huge workload on centralized Firewall. This case is especially reasonable for large layer 2 network with tens even hundreds of thousands of Virtual Machines. To rely a centralized pair of Firewall to deal with traffic from such volume of VMs are not reliable and Firewall could be the bottleneck. The following states are dynamically generated on Firewall and should be migrated when VM migrate 3.2.1. Session Table Firewall will establish session state for each connection to host within the DC. The host could a physical server or a VM. The session state includes most related information of the connection. Yang, et al. Expires March 12, 2012 [Page 10] Internet-Draft Use Cases Sep 2011 +-------------+-----------------------------------------------------+ | Item | Interpretation | +-------------+-----------------------------------------------------+ | IP Address | Both source and destination IP Address of the | | | connection | | Port | Port Number used to establish the session | | Protocol | Protocol | | VLAN | VLAN ID | | Expiration | The time that the session will be broken if no | | Time | packet passes before that. | +-------------+-----------------------------------------------------+ 3.2.2. Cumulative Data In order to protect DC from attacks, Firewall will cumulate various kinds of data. Assuming a use case, where there are both individual clients and enterprise servers in the DC. An untrusted client might attack the servers in the same DC. One example of attacks is SYN Flooding. The client keeps sending SYN message to a specific server, which will be a DOS attack to the server, or to any server, which will become a DOS attack to the Firewall. Firewall cumulate the SYN message from a client. If the frequency of SYN message exceed a pre- defined rate, the IP address of this client will be drawn into a black list. Same situation to DNS Flooding attack. 1. Source IP filtering by Hypervisor: That is what Amazon is doing. An host-based Firewall infrastructure Each instance, i.e. VM, will check the packets sent by the instance to guarantee the source IP of the packets is the IP address of the instance. This function could be developed on top of open source Hypervisor, e.g. Xen.[Amazon_VPC_User_Guide] Yang, et al. Expires March 12, 2012 [Page 11] Internet-Draft Use Cases Sep 2011 3.2.3. Scenarios for Migration of States on Firewall 3.2.3.1. VM Migration between different DCs A DC provider has two DCs on different locations, e.g. the different buildings at the same campus. Two DCs are interconnected by VPLS to make them logically in the same LAN. Each DC has deployed several Firewalls to separate different security zones. Both DCs have the Finance Zone. ----------------------------------------------------------------------------- | | | Core Switch | | | ----------------------------------------------------------------------------- | | | | Transparent | Transparent | Transparent | /L2 Firewall-1 | /L2 Firewall-2 | /L2 Firewall-3 | / |/ |/ --------------------- --------------------- --------------------- |Aggregation Switch1| |Aggregation Switch2| |Aggregation Switch3| --------------------- --------------------- --------------------- | | | ---------------- ---------------- ---------------- |Access Switch1| |Access Switch2| |Access Switch3| ---------------- ---------------- ---------------- | | | ---------------- ----------------- ----------------- | VM1 VM2 VM3| | VM10 VM11 VM12| | VM19 VM20 VM21| | VM4 VM5 VM6| | VM13 VM14 VM15| | | | VM7 VM8 VM9| | VM16 VM17 VM18| | | ---------------- ----------------- ----------------- R&D Zone Finance Zone Web service Zone Figure 4: Firewall Deployment in one DC Transparent L2 Firewall is a kind of Firewall embedded on or one-arm connected to L2 switches. L2 Firewall has normal functions as L3 Firewall, except that L2 Firewall doesn't deal with routing issues. Assuming VM5 in R&D Zone is communicating with VM13 in Finance Zone 1, and states are generated on Firewall-1 and Firewall-2 Yang, et al. Expires March 12, 2012 [Page 12] Internet-Draft Use Cases Sep 2011 --------- |Gateway| --------- | | ------------------------------------------------ MPLS ----------- | VPLS PE1 |-----------|VPLS PE1'| ------------------------------------------------ ----------- | | | | Transparent | Transparent | Transparent | /L2 Firewall-1 | /L2 Firewall-2 | /L2 Firewall-2' |/ |/ |/ --------------------- --------------------- ---------------------- | (VPLS CE1) | | (VPLS CE2) | | (VPLS CE1') | |Aggregation Switch1|...> |Aggregation Switch2| |Aggregation Switch1'| --------------------- --------------------- ---------------------- | | | | | | ---------------- ---------------- ----------------- |Access Switch1| |Access Switch2| |Access Switch1'| ---------------- ---------------- ----------------- | | | | | | ---------------- ----------------- ----------------- | VM1 VM2 VM3| | VM10 VM11 VM12| | VM31 VM32 VM33| | VM4 VM5 VM6| | VM13 VM14 VM15| | | | VM7 VM8 VM9| | VM16 VM17 VM18| | | ---------------- ----------------- ----------------- R&D Zone Finance Zone 1 Finance Zone 2 .... VM Traffic Figure 5: Firewall Deployment in two DCs At payment day, a burst of access requests come to Finance Zone, the volume exceeds Server capability at Finance Zone 1. VM13 and some other VM are migrated to Finance Zone 2 to utilize the idle resources in Finance Zone 2. The existing service on VM13 should be kept without disruption. So that the states on Firewall-2 that is related to VM13 should be migrated to Firewall-2'. Yang, et al. Expires March 12, 2012 [Page 13] Internet-Draft Use Cases Sep 2011 --------- |Gateway| --------- | | ------------------------------------------------ MPLS ----------- | VPLS PE1 |-----------|VPLS PE1'| ------------------------------------------------ ----------- /\| :| *********************** | **-> :| Transparent :| Transparent | Transparent :| /L2 Firewall-1 :| /L2 Firewall-2 | /L2 Firewall-2' :|/ (States) V|/ (States) |/ --------------------- --------------------- ---------------------- | (VPLS CE1) | | (VPLS CE2) | | (VPLS CE1') | |Aggregation Switch1|...> |Aggregation Switch2| |Aggregation Switch1'| --------------------- --------------------- ---------------------- /\| :| | :| V| | ---------------- ---------------- ----------------- |Access Switch1| |Access Switch2| |Access Switch1'| ---------------- ---------------- ----------------- /\| :| | :| V| | ---------------- -------------------- ----------------- | VM1 VM2 VM3| | VM10 VM11 VM12 | | VM31 VM32 VM33| | VM4 VM5 VM6| |'VM13''VM14''VM15'| | VN13 VM14 VM15| | VM7 VM8 VM9| | VM16 VM17 VM18 | | | ---------------- -------------------- ----------------- * /\ ********************************** R&D Zone Finance Zone 1 Finance Zone 2 ******** VM/States Migration .... VM Traffic Figure 6: Firewall Deployment in one DC Yang, et al. Expires March 12, 2012 [Page 14] Internet-Draft Use Cases Sep 2011 --------- |Gateway| --------- | | ------------------------------------------------ MPLS ----------- | VPLS PE1 |-----------|VPLS PE1'| ------------------------------------------------ ----------- /\| | :| :| Transparent | Transparent :| Transparent :| /L2 Firewall-1 | /L2 Firewall-2 :| /L2 Firewall-2' :|/ (States) |/ V|/ (States) --------------------- --------------------- ---------------------- | (VPLS CE1) | | (VPLS CE2) | | (VPLS CE1') | |Aggregation Switch1|...> |Aggregation Switch2| |Aggregation Switch1'| --------------------- --------------------- ---------------------- /\| | :| :| | V| ---------------- ---------------- ----------------- |Access Switch1| |Access Switch2| |Access Switch1'| ---------------- ---------------- ----------------- /\| | :| :| | V| ---------------- -------------------- ----------------- | VM1 VM2 VM3| | VM10 VM11 VM12 | | VM31 VM32 VM33| | VM4 VM5 VM6| | | | VN13 VM14 VM15| | VM7 VM8 VM9| | VM16 VM17 VM18 | | | ---------------- -------------------- ----------------- R&D Zone Finance Zone 1 Finance Zone 2 ******** VM/States Migration .... VM Traffic Figure 7: VM Migration Completion 3.2.3.2. VM Migration under Distributed Deployed Firewalls In a DC with distributed deployed Firewalls on Aggregation Switches, an enterprise customer lease hundreds of physical servers, and each physical server carries 10 plus Virtual Machines (VM). Usually, the distributed deployed Firewalls are transparent L2 Firewall. HA is required, so that the physical servers must be placed in different section of the network. For example, some servers under TOR1 in Pod1 and others under TOR2 in Pod2. The VMs provide VDI service to employees. Yang, et al. Expires March 12, 2012 [Page 15] Internet-Draft Use Cases Sep 2011 ----------------------------------------------------------------------------- | | | Core Switch | | | ----------------------------------------------------------------------------- | | /\ VM traffic | | : | | : ---------------------- ---------- ---------------------- ---------- |Aggregation Switch |--|Firewall| |Aggregation Switch |--|Firewall| ---------------------- ---------- ---------------------- ---------- | \ | /\ States Generated | \ | : on Firewall ---------------- ---------------- ---------------- |Access Switch1| |Access Switch2| |Access Switch3| ---------------- ---------------- ---------------- | | | /\ | | | : ---------------- ----------------- ----------------- | VM1 VM2 VM3| | VM10 VM11 VM12| | VM19 VM21 | | | | | | VM22 VM24 | | VM7 VM8 VM9| | VM16 VM17 VM18| | VM25 VM27 | ---------------- ----------------- ----------------- \__________________________________________/ \_____________________/ Pod1 Pod2 .... VM Traffic Figure 8: VDI service in DC While network performance at Pod2 becomes unacceptable, VMs need to be migrated to Pod1, and the running service must be guaranteed. In this case, the states on Firewall need to be migrated. Yang, et al. Expires March 12, 2012 [Page 16] Internet-Draft Use Cases Sep 2011 ----------------------------------------------------------------------------- | | | Core Switch | | | ----------------------------------------------------------------------------- | | /\ | | : | | : ---------------------- ---------- ---------------------- ---------- |Aggregation Switch |--|Firewall| |Aggregation Switch |--|Firewall| ---------------------- ---------- ---------------------- ---------- | \ /\ | /\ States Generated | \ ****************************|*:*** on Firewall ---------------- ---------------- ---------------- |Access Switch1| |Access Switch2| |Access Switch3| ---------------- ---------------- ---------------- | | | /\ | | | : ---------------- ----------------- ----------------- | VM1 VM2 VM3| | VM10 VM11 VM12| | 'VM19' 'VM21'| | | | | | 'VM22' 'VM24'| | VM7 VM8 VM9| | VM16 VM17 VM18| | 'VM25' 'VM27'| ---------------- ----------------- ----------------- /\ /\ * * * * **************************************************** \__________________________________________/ \_____________________/ Pod1 Pod2 ******** VM/States Migration .... VM Traffic Figure 9: VM migration while Pod2 becomes unacceptable Yang, et al. Expires March 12, 2012 [Page 17] Internet-Draft Use Cases Sep 2011 ----------------------------------------------------------------------------- | | | Core Switch | | | ----------------------------------------------------------------------------- | /\ | | : | | : | ---------------------- ---------- ---------------------- ---------- |Aggregation Switch |--|Firewall| |Aggregation Switch |--|Firewall| ---------------------- ---------- ---------------------- ---------- | /\ \ /\ States Generated | | : \ : on Firewall | ---------------- ---------------- ---------------- |Access Switch1| |Access Switch2| |Access Switch3| ---------------- ---------------- ---------------- | /\ | /\ | | : | : | ---------------- ----------------- ----------------- | VM1 VM2 VM3| | VM10 VM11 VM12| | | |VM19 VM22 VM25| |VM21 VM24 VM27| | | | VM7 VM8 VM9| | VM16 VM17 VM18| | | ---------------- ----------------- ----------------- \__________________________________________/ \_____________________/ Pod1 Pod2 .... VM Traffic Figure 10: VM migration Completion 4. References 4.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", August 2002. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", Jan. 2007. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service Yang, et al. Expires March 12, 2012 [Page 18] Internet-Draft Use Cases Sep 2011 (VPLS) Using Label Distribution Protocol (LDP) Signaling", Jan. 2007. [RFC4861] "Neighbor Discovery for IP version 6 (IPv6)", Sep. 2007. 4.2. Informative Reference [I-D.gu-opsawg-policies-migration] Gu, Y. and Y. Fan, "I-D.gu-opsawg-policies-migration", 2011. [I-D.wang-opsawg-policy-migration-gap-analysis] Wang, D. and Y. Gu, "I-D.wang-opsawg-policy-migration-gap- analysis", 2011. [Vmotion_between_DCs] VMware, "VMotion between Data Centers--a VMware and Cisco Proof of Concept, (http://http://blogs.vmware.com/ networking/2009/06/ vmotion-between-data-centersa-vmware-and-cisco-proof-of- concept.html)", June 2009. [OTV] Grover, H., Rao, D., and D. Farinacci, "Overlay Transport Virtualization", July 2011. [Amazon_VPC_User_Guide] "http://docs.amazonwebservices.com/AmazonVPC/2011-07-15/ UserGuide". [Virtual_Network_Features] "http://www.vmware.com/files/pdf/technology/ cisco_vmware_virtualizing_the_datacenter.pdf". [Cisco_DHCP_SNP] "http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ ios/12.2SX/configuration/guide/snoodhcp.html#wp1101941" Authors' Addresses Jingtao Yang Huawei Email: yangjingtao@gmail.com Huiyang Xu China Mobile Email: xuhuiyang@chinamobile.com Yang, et al. Expires March 12, 2012 [Page 19] Internet-Draft Use Cases Sep 2011 Chen Li China Mobile Email: lichenyj@chinamobile.com Yang, et al. Expires March 12, 2012 [Page 20]