Internet DRAFT - draft-gu-sdnrg-network-management-consideration

draft-gu-sdnrg-network-management-consideration






SDNRG                                                         R. Gu, Ed.
Internet-Draft                                                   R. Wang
Intended status: Informational                              China Mobile
Expires: April 4, 2017                                         Y. Zhuang
                                                                  Huawei
                                                                Oct 2016


                  SDN network management consideration
           draft-gu-sdnrg-network-management-consideration-02

Abstract

   This draft introduces consideration about SDN network management
   after the deployment of SDN and NFV in cloud datacenters.  The
   content of SDN network management and some specific technique are
   included from the network administrator's point of view.

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 4, 2017.

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



Gu, et al.                Expires April 4, 2017                 [Page 1]

Internet-Draft    SDN network management consideration          Oct 2016


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definition of terms  . . . . . . . . . . . . . . . . . . . . .  4
   4.  SDN network management architecture  . . . . . . . . . . . . .  4
   5.  SDN management usecases  . . . . . . . . . . . . . . . . . . .  5
     5.1.  Topology display . . . . . . . . . . . . . . . . . . . . .  5
     5.2.  Network detection  . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Network monitoring . . . . . . . . . . . . . . . . . . . .  8
     5.4.  Alarm and log of new SDN devices and network . . . . . . .  9
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
































Gu, et al.                Expires April 4, 2017                 [Page 2]

Internet-Draft    SDN network management consideration          Oct 2016


1.  Introduction

   In cloud datacenter, virtualized infrastructure of virtual machines
   and physcial infrastructure of bare-metal servers are both deployed
   in the network.  Actually Openstack K version, SDN controller, open
   virtual switch, SDN ToR (top of rack) switches and SDN gateways act
   as network devices.  In this cloud-based deployment, Openstack
   manages computing, storage and network of the entire system by its
   modules including neutron, nova, ironic, swift and so on.  SDN
   controller is responsible for the network provision and management.
   It receives messages of network operations from applications or
   Openstack neutron and translates them into commands/operations for
   forwarding devices such as open virtual switch, SDN ToR and SDN
   gateways.

   Network administrators face the task of SDN network management after
   the practical deployment of these heterogeneous devices and networks
   in several levels.  Up to now, our network administrator focuses SDN
   management on network topology, network detection and monitoring.

   During research we found out difficulties and confusions in several
   aspects:

   (1) Several network layers and virtualization enlarge the range and
   increase the difficulty in network mangement.

   (2) Network monitoring needs to be inserted into servers as
   virtualization is brought in which is different from traditional
   network devices monitoring.

   (3) Network management should be nearly real time as network is open
   to tenants which can be operated at real time.

   (4) New techniques about the SDN network detection as traditional
   ping or trace need to be discovered.

   This draft presents considerations about SDN datacenters management
   including architecture, use case and potential techniques.


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






Gu, et al.                Expires April 4, 2017                 [Page 3]

Internet-Draft    SDN network management consideration          Oct 2016


3.  Definition of terms

   NFV: network function virtualization

   NVE: network virtualization edge

   SDN: software defined network

   SFC: service function chaining

   ToR: top of rack

   VM: virtual machine

   VPC: virtual private cloud

   ovs: open virtual switch


4.  SDN network management architecture

   In considering SDN network management, we focus on the content of
   topology display, network detection and monitor.  In fabric networks,
   there are controlling nodes and forwarding nodes based on SDN.
   Besides, traditional physical devices such as normal physical
   switches for traditional network connection and servers are deployed
   whose information need to be collected for the topology display and
   network detection and monitoring.























Gu, et al.                Expires April 4, 2017                 [Page 4]

Internet-Draft    SDN network management consideration          Oct 2016


      +---------------------------------------------------------------+
      |SDN network management                                         |
      |       ------------         ------------        ------------   |
      |       | topology |         | detection|        |  monitor |   |
      |       ------------         ------------        ------------   |
      +------------^-----------------------^--------------------------+
                   |                       |
   |---------------|                       |
   |                                       |
   |            |-------------------------+---------------------|
   |            |                         |                     |
   |            |                         |                     |
   | +----------+---------+ +-------------+------+ +------------+------+
   | | fabric 1 |         | | fabric 2    |      | | fabric N   |      |
   | |          |         | |             |      | |            |      |
   | | ---------+-------- | | ------------+----- | | -----------+------|
   | | |controlling node| | | |controlling node| | | |controlling node||
   | | ---------+-------- | | ------------+----- | | -----------+------|
   | |          |         | |             |      | |            |      |
   | | ---------+-------- | | ------------+----- | | -----------+------|
   | | | forwarding node| | | | forwarding node| | | | forwarding node||
   | | ------------------ | | ------------------ | | ------------------|
   | |                    | |                    | |                   |
   | | ------------------ | | ------------------ | | ------------------|
   | | |physical devices| | | |physical devices| | | |physical devices||
   | | ---------+-------- | | ----------+------- | | ----------+-------|
   | +----------|---------+ +-----------|--------+ +-----------|-------+
   |            |                       |                      |
   |------------+-----------------------+----------------------|

               Figure 1: SDN network management architecture


5.  SDN management usecases

5.1.  Topology display

   Commonly, several levels of network is involved which we call tenants
   network, logical network and physical network.  Tenants network is
   connected with tenants with their network displaying as the abstract
   models such as the vitual machines, virtual links and virtual
   gateways which is known as VPC.  The difference between tenants
   network and logical network lies in that tenants network faces to
   tenants while logical network faces to network administrators.  As a
   result, logical network is displayed as the connection between all
   the NVE (Network Virtualization Edge).  Thus controlling nodes and
   forwarding nodes are related with logical network.  Physical network
   means the network provides the basic connections between physical



Gu, et al.                Expires April 4, 2017                 [Page 5]

Internet-Draft    SDN network management consideration          Oct 2016


   devices.  All the three networks need to be cooperated with each
   other.  In providing the network topology, logical network needs to
   be related with physical network in order to provide the overall
   information including the NVE and its corresponding physical devices.
   Besides, tenants view their network mainly focusing on their created
   virtual network.

                ------------------
                |     vrouter    +------------+-------+---------|
                -----+------+-----            |       |         |
                     |      |                 |       |         |
                   --|      |--          -----+-----  |         |
                   |          |          |    FW   |  |         |
              -----+-----  -----+-----   -----------  |         |
              | vbridge |  | vbridge |           -----+-----    |
              --+-----+--  --+-----+--           |    LB   |    |
                |     |      |     |             -----------    |
              --+-- --+--  --+-- --+--                     -----+-----
              |V M| |V M|  |V M| |V M|                     |   NAT   |
              ----- -----  ----- -----                     -----------

                         Figure 2: Tenants network


                     -----------------------------------------------
                     |                 Core SW                     |
                     -----+---------------+----------------+--------
                          |               |                |
                        --|               |                |--
                        |                 |                  |
                   -----+-----     -------+--------   -------+--------
                   |   ToR   |     | hardware vtep|   | hardware vtep|
                   -----+-----     -------+--------   -------+--------
                        |                 |                  |
                 -------+-------   -------+-------    -------+--------
                 | ----------- |   | ----------- |    |   physical   |
                 | |   vtep  | |   | |   ovs   | |    |    devices   |
                 | --+-----+-- |   | --+-----+-- |    |              |
                 |   |     |   |   |   |     |   |    |     NAT/     |
                 | --+-- --+-- |   | --+-- --+-- |    |      FW/     |
                 | |V M| |V M| |   | |V M| |V M| |    |      LB/     |
                 | ----- ----- |   | ----- ----- |    |      VPN     |
                 ---------------   ---------------    ----------------

                         Figure 3: Overall network






Gu, et al.                Expires April 4, 2017                 [Page 6]

Internet-Draft    SDN network management consideration          Oct 2016


5.2.  Network detection

   Network detection aims at trouble-shooting automatically and fault
   prediction.  Traditional detection technologies such as ping and
   trace can be used in the physical network detection.  While in the
   logical network, detection should also be provided including the
   connection between NVE and NVE (vtep detection)and connections inner
   a VPC (service detection).

   The vtep detection can detect the time delay and packet-loss between
   vteps.  If packet loss are found out in vteps, fault point can be
   found.  Based on this, adminitrators can locate the fault point and
   be more efficient in recovering the network.

       - -----------------------------------------------------------
         |                       Core switch                       |
         -----+--------------------+-----------------------+--------
              |  ...(detection)... |                       |
              |  .               . |                       |
         -----+--.--          ---.-+------           ------+------
         |   ToR . |          |  . ToR   |           |    ToR    |
         -----+--.--          ---.-+------           -------------
              |  .               . |                       |
              |  .                .|                       |
        ------+-.---          --- .+------           ------+-----
        |  -----V- |          |  -V----- |           | Physical |
        |  | vtep| |          |  | vtep| |           | devices  |
        |  +-----+ |          |  +-----+ |           |          |
        |  |     | |          |  |     | |           |   NAT/   |
        |--+-  --+-|          |--+-  --+-|           |   FW/    |
        ||VM|  |VM||          ||VM|  |VM||           |   LB/    |
        |----  ----|          |----  ----|           |   VPN    |
        ------------          ------------           ------------

                         Figure 4: vtep detection

   Service detection verifies the service availability such as VPC or
   service function chain.  Traffic flow inner virtual private cloud of
   one tenant is simulated in order to get the information of packet
   loss and time delay.  With the collected information of traffic, the
   availability of tenants' service is detected.










Gu, et al.                Expires April 4, 2017                 [Page 7]

Internet-Draft    SDN network management consideration          Oct 2016


          ----------------------------------------------------------
          |                    Controlling node                    |
          -----------------------------V----------------------------
                     |                 |
                     |traffic          |information
                     |simulation       |collection
         ------------V---------------------------------------------
          |  VPC                 --------------                   |
          |                      |  vRouter1  |                   |
          |                      --V.--------V-                   |
          |                        .   |   | . (detection)        |
          |                .........   |   | ...........          |
          |               .  -----------   ----------- .          |
          |               .  |                       | .          |
          |            ---V-+-----              -----+-V---       |
          |            | vBridge1|              | vBridge1|       |
          |            -----+-----              -----+-----       |
          -----------------/-\----------------------/-\------------
                     ------   ------           -----   ---------
                     |             |           |               |
                 ----+---      ----+---     ---+----       ----+---
                 |  VM1 |      |  VM2 |     |  VM3 |       |  VM4 |
                 --------      --------     --------       --------


                        Figure 5: service detection

5.3.  Network monitoring

   Network administrator needs to monitor the network in several sides.
   On one side, administrator can get information of logical network
   resouces such as subnets, traffic path with the help of data derived
   from network detection.  Besides, administrator needs to monitor
   physical network devices such as controlling nodes and forwarding
   nodes with their configurations and status such as performance.  From
   the other side, system resources need to be monitored as well
   including the tenants information and physical fabric resource
   information.  Real-time monitoring is required.













Gu, et al.                Expires April 4, 2017                 [Page 8]

Internet-Draft    SDN network management consideration          Oct 2016


          ----------------------------------------------------------
          | Network Monitoring        |           Contents         |
          |--------------------------------------------------------|
          | logical network resources |   subnets, traffic path,   |
          |                           |   virtual interface...     |
          |--------------------------------------------------------|
          |                           |   controlling nodes,       |
          | physical network resources|   physical interface,      |
          |                           |   forwarding nodes...      |
          |--------------------------------------------------------|
          | system resource           |tenants related information,|
          |                           |fabric information...       |
          ----------------------------------------------------------

                       Figure 6: Network monitoring

   Some uniform network monitoring model needs to be designed for the
   SDN network monitoring from the management platform.

5.4.  Alarm and log of new SDN devices and network

   From the summary of network topology, network detection and
   monitoring, changes on the network should be reported as log of SDN
   network.  If network abnormal phenomenon happens, alarm should be
   reported.  The content and form of alarm and log needs to be
   designed.  And the pull or push method needs to be recommend.


6.  Conclusion

   In SDN network deployment,new challenages are brought in such as
   several levels of network layers and large-scale range.  Network
   topology, network detetion and monitoring are concentrated by network
   administrators as netowrk management use case.  Uniform models such
   as topology display and network monitoring are in absence.


7.  Security Considerations

   None.


8.  IANA Considerations

   None.






Gu, et al.                Expires April 4, 2017                 [Page 9]

Internet-Draft    SDN network management consideration          Oct 2016


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

   Rong Gu (editor)
   China Mobile
   32 Xuanwumen West Ave, Xicheng District
   Beijing  100053
   China

   Email: gurong_cmcc@outlook.com


   Ruixue Wang
   China Mobile
   32 Xuanwumen West Ave, Xicheng District
   Beijing  100053
   China

   Email: wangruixue@chinamobile.com


   Yan Zhuang
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: zhuangyan.zhuang@huawei.com












Gu, et al.                Expires April 4, 2017                [Page 10]