Internet DRAFT - draft-yang-opsawg-policies-migration-use-case
draft-yang-opsawg-policies-migration-use-case
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]
