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, . [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, November 1997, . 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]