Internet DRAFT - draft-wang-sdnrg-deployment-sdn-vnf

draft-wang-sdnrg-deployment-sdn-vnf







sdnrg                                                            J. Wang
Internet-Draft                                                     R. Gu
Intended status: Informational                              China Mobile
Expires: April 16, 2016                                 October 14, 2015


         Practice of deploying SDN and VNFs in the data center
               draft-wang-sdnrg-deployment-sdn-vnf-00.txt

Abstract

   This document introduces a practice of deploying SDN and VNFs in the
   data center and discusses how SDN and VNFs can be combined in the
   data center.

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 April 16, 2016.

Copyright Notice

   Copyright (c) 2015 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.  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.





Wang & Gu                Expires April 16, 2016                 [Page 1]

Internet-Draft                                              October 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The deployment of SDN and VNFs  . . . . . . . . . . . . . . .   2
     2.1.  SDN controller  . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  VNF/VNFM  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Interfaces  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.3.1.  the interface between SDN controller and OVS  . . . .   5
       2.3.2.  the interface between SDN controller and VNFM . . . .   5
       2.3.3.  the interface between SDN controller and VNF  . . . .   5
   3.  The operation of the SDN controller and VNFs in the current
       deployment  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Combinations of SDN controller and VNFs . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   SDN (Software Defined Networking) and NFV (Network Functions
   Virtualization) have placed a critical role in today's data center.
   SDN decouples the network control from forwarding and makes the
   network programmable.  NFV uses the technologies of IT virtualization
   to virtualize entire classes of network node functions as the VNF
   (Virtual Network Function).  Deploying SDN and VNFs in the data
   center can make the network more flexible and increase the network
   utilization.

   This document first introduces a practice of deployment of SDN and
   VNFs in the data center, and then discusses how SDN and VNFs can be
   combined in the data center.

2.  The deployment of SDN and VNFs

   +-----------------+

   | openstack       |

   +--------+--------+

            |

   +--------+--------+           +-----------------+

   | SDN controller  +----------+ VNF Manager     |

   +----+-------+----+           +---------+-------+



Wang & Gu                Expires April 16, 2016                 [Page 2]

Internet-Draft                                              October 2015


         |      |                          |

         |      |                +---------+--------+

         |      |                |      VNF          |

         |      +---------------+   Router/NAT/FW/   |

         |                       |   LB/VPN          |

    +----+------------+          +------------------+

    |      OVS        |

    +---+-----------+-+

        |           |

   +----+---+   +---+---+

   |   VM   |   |  VM   |

   +--------+   +-------+

   The deployed data center includes OPENSTACK, SDN controller, OVS
   (Open Virtual Switch), VNFM (Virtualization Network Function Manager)
   and VNF (Virtualization Network Function).  The OPENSTACK manages the
   virtualization infrastructure include computing, storage and the
   network.  Neutron is the network component of the OPENSTACK which
   defines the abstract network API to describe the network.  SDN
   controller can be taken as the network solution deployed at the
   southbound of the Neutron.  On the one hand, the SDN controller
   receives the messages from the neutron which describes the virtual
   network operation (such as create a network/port/security group), on
   the other hand, it interprets this operations and maps them into real
   network operations (such as create a VLAN/ACL or set OPENFLOW tables
   on the OVS).  The OVS is deployed at the server and connects the VMs
   to the physical network.  In the SDN scenarios, the OVS is an
   OPENFLOW switch.  VNF is a VM/VMs which implements the network
   functions such as the Router/NAT/Firewall/LoadBalance/VPN.  VNFM is a
   centralized management entity which takes charge of
   creating/configuring/destroying the VNFs.

2.1.  SDN controller

   SDN controller is the centralized control unit of the virtual
   network.  On the one hand, it receives the messages from the
   OPENSTACK NEUTRON which describes the virtual network (such as



Wang & Gu                Expires April 16, 2016                 [Page 3]

Internet-Draft                                              October 2015


   network/subnet created, VM port attached to the subnet).  On the
   other hand, the SDN controller reads the configuration from the OVS
   and knows the real deployment (such as VM attaches to which OVS).
   Then SDN controller takes charge of mapping the virtual network into
   the real deployment.

   SDN controller talks with the OVS via OVSDB and OPENFLOW protocol to
   handle the VM related network deployment operation.  When a new
   created VM is attached to the OVS, the OVS notifies the SDN
   controller through OVSDB.  Then the SDN controller sends OPENFLOW
   flow entry to the OVS to implement access policy control and routing.
   In our deployment, VXLAN is used and thus the SDN controller also
   configures the OVS to setup VXLAN tunnel with other OVS or VNF.

   SDN controller interacts with the VNF/VNFM to handle virtual network
   function (including vRouter/vFW/vLB/vVPN etc.) related operation,
   which includes create/delete/update/retrieve the virtual network
   function.  For example when a "Router" is created in OPENSTACK,
   NEUTRON notifies SDN controller, which then interacts with the VNFM
   to create a network function VM implementing the Router function.
   After that, the VNFM sends the feedback to SDN controller, which
   indicates the information (includes IP address, login username/
   password for authentication, etc) about the new created virtual
   Router.  Based on this information, SDN controller contacts the
   created virtual Router and then configures it to route VM's packets.

2.2.  VNF/VNFM

   VNF is a VM/VMs which implements the network function such as
   Router/FW/LB/VPN. VNFM is a management entity which takes charge of
   managing the VNF. First, the VNFM is responsible for creating or
   deleting the VNF VM. Second, the VNFM can configure the created VNF
   to implement specific function via NETCONF/RESTCONF/Rest API.  For
   example, the VNFM can configure the routing information for Routing
   function, configure the security/access policy for Firewall function
   and configure the virtual IP or policy for load balance function.
   Note that the VNF can also be configured by SDN controller.

   In our current deployment, the VNFM provides the Rest API to SDN
   controller in order to create/delete the VNF VM.  The VNF provides
   both NETCONF and OPENFLOW interface to SDN controller, where the
   NETCONF is used to set the network function related configuration
   such as the Firewall policy, LoadBalance virtual IP etc.  The
   OPENFLOW is used to configure the VM related routing information.
   For example when forwarding packets to the tenant VM, the OPENFLOW
   flow entry indicates which VXLAN tunnel to deliver the packets and
   how to set the VXLAN ID of the forwarded packets.




Wang & Gu                Expires April 16, 2016                 [Page 4]

Internet-Draft                                              October 2015


2.3.  Interfaces

2.3.1.  the interface between SDN controller and OVS

   OVSDB: protocol for configuring the OVS.

   OPENFLOW: protocol for setting flow entry to OVS, which takes charge
   of data forwarding.

   Since the OVS is the de-facto standard of the virtual switch, the
   OVSDB and OPENFLOW which is used by the OVS can be seem as the
   standard interface between SDN controller and virtual switch.

2.3.2.  the interface between SDN controller and VNFM

   NETCONF/RESTCONF/REST API:  Yang model extension is defined by vendor,
   REST API is vendor specific.

2.3.3.  the interface between SDN controller and VNF

   NETCONF/RESTCONF/REST API:  Yang model extension is defined by
   vendor, REST API is vendor specific.

   OPENFLOW: configure routing for VM

3.  The operation of the SDN controller and VNFs in the current
    deployment

   Create a Router

   +-----------+ +-------------+ +--------------+ +--------------+

   | OPENSTACK | | Controller  | | VNFM         | | VNF          |

   +-----+-----+ +------+------+ +------+-------+ +-------+------+

         |              |               |                 |

   Create Router/       |               |                 |

   Router Interface     |               |                 |

         |              |               |                 |

         1.Neutron:Router created       |                 |

         +-------------->               |                 |




Wang & Gu                Expires April 16, 2016                 [Page 5]

Internet-Draft                                              October 2015


         |             |2.REST: Create vRouter            |

         |             +---------------->                 |
 
         |             |         Create a VM implementing |

         |             |         Router function          |

         |             |               +------------------+

         |             |               |    vRouter is created

         |          3.REST:vRouter created                |

         |             <-------------- |                  |

      4.Neutron: created 200OK         |                  |

        <---------------+              |                  |

         |        5.NETCONF: general Router configuration |

         |             +----------------+------------------>

         |             |                |                 |
   
   o  When a "Router/Router Interface" is created in the OPENSTACK,
      Neutron notifies the SDN controller.
   o  SDN controller sends the virtual Router created event to the VNFM
      via the REST API.
   o  The VNFM creates a VM which implements the Router function.
   o  The VNFM notifies the SDN controller that a virtual Router is
      created successfully, at the meanwhile, it sends the information
      of the virtual Router (including IP address, login username/
      password) to SDN controller as the feedback.
   o  The SDN controller responds Router/Router Interface created
      successfully to the OPENSTACK.
   o  The SDN controller connects to the created virtual Router and sets
      the general configuration to the virtual Router via NETCONF.  The
      configuration includes Router interface configuration, vlan/vxlan
      configuration, etc.

   Create a VM

   +-----------+ +-------------+ +--------------+ +--------------+

   | OPENSTACK | |    OVS      | |  Controller  | |     VNF      |




Wang & Gu                Expires April 16, 2016                 [Page 6]

Internet-Draft                                              October 2015


   +-----------+ +------+------+ +-------+------+ +------+-------+

   Create a VM          |                 |               |

         |              |                 |               |

       1.VM attach to OVS                 |               |

         +-------------->                 |               |

       2.Neutron: Port created            |               |

         +-------------------------------->               |

        Neutron: 200 OK                   |               |

        <---------------------------------+               |

         |          3.OVSDB: VM attached  |               |

         |             +------------------>               |

         |             |          4.NETCONF:create tunnel to OVS

         |             |                  +--------------->

         |        5.OPENFLOW: create tunnel to vRouter    |

         |            <--------------------+              |

         |             |         6.OPENFLOW: configure routeing of VM

         |             |                   +--------------->

         |             |                   |               |

   o  When a VM is created in the OPENSTACK, the Nova attaches the VM to
      the OVS via OVSDB.  Then Neutron informs the SDN controller that a
      port related to the created VM is created.
   o  The OVS notifies SDN controller that a VM is attached.  At this
      moment, SDN controller knows that a tenant VM is created and which
      OVS the VM attaches to.
   o  The SDN controller instructs the virtual Router to create a vxlan
      tunnel towards the OVS via NETCONF.
   o  The SDN controller instructs the OVS to create a vxlan tunnel
      towards the virtual Router via OPENFLOW.
   o  The SDN controller configures the routing of VM in the virtual
      Router via OPENFLOW.



Wang & Gu                Expires April 16, 2016                 [Page 7]

Internet-Draft                                              October 2015


4.  Combinations of SDN controller and VNFs

   There are three possible ways of combining SDN controller and VNFs

   Option 1: Openstack -> SDN controller -> VNF

   OPENSTACK sends all events to the SDN controller via Neutron.  If the
   received events are related to the OVS (such as create security group
   /create port), the SDN controller sets the flow to OVS via OPENFLOW.
   On the other hand, if the received events are related to the VNF
   (such as create firewall/loadbalance), SDN controller interworks with
   VNFM to handle this events.  In this case, the SDN controller only
   needs to interwork with VNFM.  Since SDN controller and VNF/VNFM are
   often provided by different vendors, this way of combination makes
   the cooperation of SDN controller and VNFM simple.

   +--------------------+

   |     OPENSTACK      |

   +--------+-----------+

            |

   +--------+-----------+

   |     Controller     |

   +--------+-----------+

            |

   +--------+-----------+

   |      VNFM          |

   +--------+-----------+

            |

   +--------+-----------+

   |      VNF           |

   +--------------------+

   Note that in our current deployment, the combination of SDN
   controller and VNFM/VNF is slightly different from the Option 1.  The



Wang & Gu                Expires April 16, 2016                 [Page 8]

Internet-Draft                                              October 2015


   SDN controller invokes the interface of VNFM to create/terminate the
   VNF, while talks to the VNF directly to configure it.  This way of
   combination is sub-optimized since the SDN controller not only needs
   to cooperate with VNFM but also needs to interwork with VNF, which
   increases the complexity of the entire system and the interface
   between SDN controller and VNFM/VNF.  We will move to the Option 1 in
   our next stage deployment.

       +--------------------+

       |     OPENSTACK      |

       +--------+-----------+

                |

       +--------+-----------+

    +--+   Controller       |

    |  +--------+-----------+

    |           |
 
    |  +--------+-----------+

    |  |       VNFM         |

    |  +--------+-----------+

    |           | 

    |  +--------+-----------+

    +--+       VNF          |

       +--------------------+

   Option 2: Openstack -> VNF -> SDN controller

   OPENSTACK sends all events to the VNFM via Neutron.  If the received
   events are related to the VNF (such as create firewall/loadbalance),
   the VNFM create/configure the VNF through internal interface.  At the
   same time, VNFM notifies the SDN controller of this event.  SDN
   controller then configures the routing in the OVS, such as creating
   tunnel to the created firewall.  On the other hand, if the received
   events are related to OVS (such as create security group /create
   port), the VNFM forwards this event to the SDN controller.



Wang & Gu                Expires April 16, 2016                 [Page 9]

Internet-Draft                                              October 2015


   This way of combination is more complex than Option1.  VNFM in this
   Option not only needs to handle the VNF related events but also needs
   to handle the OVS related events, which makes the VNFM more complex
   and inefficient (since handling the OVS related events makes no sense
   to VNFM).

      +--------------------+

      |   OPENSTACK        |

      +--------+-----------+

               |

      +--------+-----------+

   +--+       VNFM         |

   |  +--------+-----------+

   |           |

   |  +--------+-----------+

   |  |       VNF          |

   |  +--------------------+

   |

   |  +--------------------+

   +--+    Controller      |

      +--------------------+

   Option 3: OPENSTACK -> 1.  SDN controller 2.  VNFM

   OPENSTACK (actually the plugin provided to the OPENSTACK) needs to
   sends different events to different entities.  OPENSATCK sends the
   OVS related events to the SDN controller while sends the VNF related
   events to the VNFM.  Besides, the SDN controller needs to interact
   with VNFM.  For example, when receiving the Router/Router Interface
   created event, the VNFM needs to notify the SDN controller, which
   then configure the routing in the OVS, such as creating tunnel to the
   created virtual Router.





Wang & Gu                Expires April 16, 2016                [Page 10]

Internet-Draft                                              October 2015


   This way of combination is more complex.  OPENSTACK needs to send
   different events to different entities.  Since the SDN controller and
   VNFM are often provided by different vendors, Cooperation of SDN
   controller and VNFM in the OPENSTACK is hard to be achieved.

               +--------------------+

               |      OPENSTACK     |

               +-----+--------+-----+

                     |        |

             +-------+        +------------+

             |                             |

   +---------+---------+        +----------+--------+

   |     Controller    +--------+        VNFM       |

   +-------------------+        +----------+--------+

                                           |

                                +----------+--------+

                                |         VNF       |

                                +-------------------+

5.  Security Considerations

   TBA

6.  IANA Considerations

   None.

7.  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>.






Wang & Gu                Expires April 16, 2016                [Page 11]

Internet-Draft                                              October 2015


Authors' Addresses

   Jinzhu Wang
   China Mobile

   Email: wangjinzhu.ietf@outlook.com


   Rong Gu
   China Mobile

   Email: gurong_cmcc@outlook.com







































Wang & Gu                Expires April 16, 2016                [Page 12]