Internet DRAFT - draft-gu-sdnrg-decoupling-scheme-hypervisor-sdn
draft-gu-sdnrg-decoupling-scheme-hypervisor-sdn
SDNRG R. Gu, Ed.
Internet-Draft C. Li
Intended status: Informational China Mobile
Expires: September 17, 2016 March 16, 2016
Decoupling scheme for hypervisor from SDN architecture
draft-gu-sdnrg-decoupling-scheme-hypervisor-sdn-00
Abstract
Different hypervisors are used in SDN network in cloud datacenters,
such as KVM, VMware ESXi and Xen. However, different hypervisors are
not well supported by SDN network to some degrees. In order to solve
the problems with hypervisor VMware ESXi and Xen, decoupling schemes
for hypervisor from SDN architecture are presented. Through
different decoupling schemes, we want to find a better way in order
to get the overall view by the SDN network.
Status of This Memo
This Internet-Draft is submitted to IETF 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 September 17, 2016.
Copyright Notice
Copyright (c) 2016 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
(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.
Gu & Li Expires September 17, 2016 [Page 1]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Definition of terms . . . . . . . . . . . . . . . . . . . . . 2
4. SDN architecture based on KVM . . . . . . . . . . . . . . . . 3
5. SDN architecture based on VMware ESXi . . . . . . . . . . . . 4
6. SDN architecture based on Xen . . . . . . . . . . . . . . . . 8
7. SDN architecture based on network card under distinction of
hypervisors . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Nowadays in cloud datacenters, the SDN architecture includes the
application to tenants, orchestration layer, SDN controller and the
forwarding layer. In forwarding layer, some forwarding nodes such as
virtual switch and virtual machines are included. However, the
virtual switch and virtual machines are based on hypervisor, which
creates and runs virtual machines. The open source KVM is the most
widely used hypervisor in SDN network as Openstack is the most
popular orchestrator which is developed on KVM. Besides KVM, there
are other widely used hypervisors such as VMware ESXi and Xen.
According to the survey of three hypervisors adopted in our cloud
datacenter, different hypervisors are not well supported to different
degrees. KVM is the first one to be well supported, VMware ESXi the
second, while Xen is the last. Thus the hypervisor chosen has an
impact on SDN network. In other words, if VMware ESXi or Xen is
chosen as the hypervisor, SDN vendors are limited or parts of
functions are limited. In order to find out the solution to the
limitation, decoupling scheme for hypervisor from SDN architecture is
presented.
2. Terminology
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].
3. Definition of terms
KVM: kernal-based virtual machine
OVS: open virtual switch
Gu & Li Expires September 17, 2016 [Page 2]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
SDN: software defined network
VM: virtual machine
VSW: virtual switch
4. SDN architecture based on KVM
KVM hypervisor is well supported. Thinking about the hypervisor,
open virtual switch (ovs) or commercial virtual switch are deployed
on hypervisor. In order to control the whole SDN network, drivers
need to be installed in the Openstack neutron module, with controller
driver responsible for the controller and virtual switch drivers for
virtual switch. If the virtual switch is managed by the controller,
then controller driver and virtual switch driver may belong to only
one driver. If the virtual switch is ovs which is open source and
can not be managed by controller, then the neutron manages ovs by the
ovs driver which is open source as well. In this two scenarios, KVM
hypervisor is chosen and the whole SDN architecture is widely used.
Gu & Li Expires September 17, 2016 [Page 3]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
------------------------------------------------------------------
| openstack |
| -------- --------------------------------------------------- |
| | | | neutron | |
| | nova | | -------------------- ------------------------ | |
| | | | | Controller driver| | virtual switch driver| | |
| | | | ---------+---------- ---------------+-------- | |
| ---+---- -----------|---------------------------|----------- |
-----|-----------------|---------------------------|--------------
| | |
| | |
| -----------+--------------- |
| | | |
| | SDN controller | |
| | | |
| --------------+------------ |
| | |
| | |
-----|--------------------|------------------------|---------------
| | KVM hypervisor | | |
| | ---+------------------------|------------- |
| | | virtual switch ---------+----------- | |
| | | | switch agent | | |
| | | --------------------- | |
| --+-------------- -----+--------------+---------------+----- |
| | nova compute | | | | |
| ----------------- ----+----- ----+----- ----+----- |
| | VM1 | | VM2 | | VM3 | |
| ---------- ---------- ---------- |
-------------------------------------------------------------------
Figure 1: SDN architecture based on KVM
5. SDN architecture based on VMware ESXi
When the hypervisor changes into VMware ESXi, things are different.
As VMware has its own virtual switch and its own SDN solution,
internal interface is not open to the public. In this situation, you
can choose the entire SDN solution based on VMware ESXi with its own
controller, and virtual switch, which is shown in the below.
Gu & Li Expires September 17, 2016 [Page 4]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
------------------------------------------------------------------
| openstack |
| ------------------ ----------------------------------------- |
| | | | neutron | |
| | nova | | | |
| | | | | |
| | -------------- | | -------------------------- | |
| | | nova driver| | | | entity driver | | |
| | ------+------- | | ------------+------------- | |
--------|--------- ------------------------|---------------- |
----------|-----------------------------------|-------------------
| |
| |
---+-----------------------------------+-----
| |
| VMware controller |
| |
----------------------+----------------------
|
|
-----------------------------|-------------------------------------
| VMware ESXi hypervisor | |
| ------+----------------------------------- |
| | | |
| | VMware virtual switch | |
| | | |
| -----+--------------+---------------+----- |
| | | | |
| ----+----- ----+----- ----+----- |
| | VM1 | | VM2 | | VM3 | |
| ---------- ---------- ---------- |
-------------------------------------------------------------------
Figure 2: SDN solution based on VMware ESXi
However, there is a problem esisted in this solution. If another
party's devices such as the opendaylight controller or the ovs want
to take a place,there are limitations. The limitation relies on that
the hypervisor VMware ESXi is binding with its virtual switch without
the control by another party's controller. Total solutions in order
to solve this problem are eager to be found out.
One of the idea is about separating the hypervisor from the SDN
network, there is controller driver for the SDN controller and VMware
virtual switch driver for its virtual switch. However, the traffic
across the virtual switch is escaped from SDN controller as SDN
controller can not receive the information about the virtual
Gu & Li Expires September 17, 2016 [Page 5]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
switch.Then if the SDN controller can get back the power of virtual
switch, question may be answered.
(1) Substitution of virtual switch belongs to SDN network
For the overall view of SDN network, virtual switch should be
monitored or managed by SDN network. For example, it's better for
SDN controller to gather information of virtual switch for the reason
that traffic inner a server or out of the server can be reflexed on
the virtual switch. For this purpose, a scheme by the substitution
of virtual switch is proposed. The VMware switch is out of control
of another party's controller, which can be resolved by virtual
switch controlled by controller replacing the VMware switch. As the
VMware switch and the VMware ESXi can be regarded as an integral
whole, the difficulty of substitution rests in private interfaces
with some development on integrating another party's switch on the
non-open source hypervisor.
Gu & Li Expires September 17, 2016 [Page 6]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
------------------------------------------------------------------
| openstack |
| -------- --------------------------------------------------- |
| | | | neutron | |
| | nova | | -------------------- ------------------------ | |
| | | | | Controller driver| | virtual switch driver| | |
| | | | ---------+---------- ---------------+-------- | |
| ---+---- -----------|---------------------------|----------- |
-----|-----------------|---------------------------|--------------
| | |
| | |
| -----------+--------------- |
| | | |
| | SDN controller | |
| | | |
| --------------+------------ |
| | |
| | |
-----|--------------------|------------------------|---------------
| | VMware ESXi | | |
| | hypervisor ---+------------------------|------------- |
| | | virtual switch ---------+----------- | |
| | | | switch agent | | |
| | | --------------------- | |
| --+-------------- -----+--------------+---------------+----- |
| | nova compute | | | | |
| ----------------- ----+----- ----+----- ----+----- |
| | VM1 | | VM2 | | VM3 | |
| ---------- ---------- ---------- |
-------------------------------------------------------------------
Figure 3: SDN architecture based on VMware ESXi with the substitution
(2) Virtual machine added acting as the virtual switch
In the prior method, there is risk on non-open source hypervisor open
to virtual switch with construction of hypervisor changed. In order
to keep the native hypervisor, changes can be made on the virtual
machines. In order to get the information from virtual switch with
virtual switch based on ESXi hypervisor unchanged, we can add a new
virtual machine. By traffic redirection, traffic from the virtual
switch on hypervisor is firstly transmitted into the virtual machine.
In this case, the virtual machine acts as another switch which can be
controlled by the SDN controller. However, the performance of
virtual switch is the bottleneck.
Gu & Li Expires September 17, 2016 [Page 7]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
------------------------------------------------------------------
| openstack |
| -------- --------------------------------------------------- |
| | | | neutron | |
| | nova | | -------------------- ------------------------ | |
| | | | | Controller driver| | virtual switch driver| | |
| | | | ---------+---------- ---------------+-------- | |
| ---+---- -----------|---------------------------|----------- |
-----|-----------------|---------------------------|--------------
| | |
| | |
| -----------+--------------- |
| | | |
| | SDN controller | |
| | | |
| --------------+------------ |
| | |
| | |
-----|--------------------|------------------------|---------------
| | VMware ESXi | | |
| | hypervisor ---+------------------------|------------- |
| | | VMware ---------+----------- | |
| | | virtual switch | switch agent | | |
| | | --------------------- | |
| --+-------------- -----+-------+--------+-----------+------- |
| | nova compute | | | | | |
| ----------------- ----+--- ---+---- ---+---- ------+----- |
| | VM1 | | VM2 | | VM3 | | VM as vsw| |
| -------- -------- -------- ------------ |
-------------------------------------------------------------------
Figure 4: SDN architecture based on VMware ESXi with virtual machine
added
6. SDN architecture based on Xen
As Xen is the same situation as VMware ESXi, the solutions are the
same dividing into Separation of hypervisor and SDN, Substitution of
virtual switch belongs to SDN network and Virtual machine added
acting as the virtual switch.
7. SDN architecture based on network card under distinction of
hypervisors
SDN architecture based on network card under distinction of
hypervisors may be a complete solution. In this way, network card of
the server docks with hypervisor with traffic on virtual switch
submitting to the network card. Thus the network card receives and
Gu & Li Expires September 17, 2016 [Page 8]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
forwards traffic rather than the virtual switch resulting in overall
view of SDN network in SDN controller. However, specific network
card is required.
8. Conclusion
Comparing with the KVM hypervisor, we have presented serveral
different decoupling schemes of hypervisor from SDN architecture.
There are some development on all these schemes. One is to separate
the hypervisor from SDN with virtual switch driver for virtual switch
and controller driver for SDN driver, with the shortage of virtual
switch exception from the whole SDN network. Another is to
substitution the virtual switch based on hypervisor with another
virtual switch controlled by SDN controller, thus the development
needs to be done. In the third way, we can add a new virtual machine
acting as the virtual switch with all traffic directing into the
virtual machine. Thus the virtual machine can be the bottleneck.
The last way is to use the physical network card replaces the
function of virtual switch, while the specific physical network card
is required. Besides all these methods, we are still trying to find
out a complete solution of separation of hypervisor with SDN
architecture in order to make it more flexible.
9. Security Considerations
None.
10. IANA Considerations
None.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
November 1997, <http://www.rfc-editor.org/info/rfc2234>.
Authors' Addresses
Gu & Li Expires September 17, 2016 [Page 9]
Internet-Drafdraft-gu-sdnrg-decoupling-scheme-hypervisor-00 March 2016
Rong Gu (editor)
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing 100053
China
Email: gurong_cmcc@outlook.com
Chen Li
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing 100053
China
Email: lichenyj@chinamobile.com
Gu & Li Expires September 17, 2016 [Page 10]
