Internet DRAFT - draft-lee-teas-cso-use-cases

draft-lee-teas-cso-use-cases



Teas Working Group                                               Y. Lee
Internet Draft                                                   Huawei
Intended status: Informational
Expires April 30, 2018                                  L. M. Contreras
                                                             Telefonica

                                                    Carlos J. Bernardos
                                                                   U3CM

                                                                  H. Xu
                                                          China Telecom



                                                       October 30, 2017



                Use Cases for Cross-Stratum Optimization

                      draft-lee-teas-cso-use-cases-00


Abstract

   This draft provides use-cases and requirements for cross-stratum
   optimization.



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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt




Lee & Contreras         Expires March 30, 2018                 [Page 1]

Internet-Draft              CSO Use-cases                  October 2017


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 30, 2018.

Copyright Notice

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


Table of Contents


   1  Introduction...................................................3
      1.1   Scope and Objectives.....................................3
      1.2   Common Terms, Abbreviations and Definitions..............3
   2  Use Cases......................................................4
      2.1   Game Server Application..................................4
      2.2   Automatic assignment of ICT resources to meet SLAs of App
      Orchestrator...................................................7
         2.2.1    ICT Auto-Scaling Monitoring........................7
         2.2.2    ICT Auto-Scaling Reservation.......................8
      2.3   Hybrid Cloud.............................................8
      2.4   Virtual CDN.............................................12
   3  Summary and Conclusions ......................................13
   4  References ...................................................13
   5  Contributors .................................................14
   Authors' Addresses...............................................14










Lee & Contreras         Expire April 30, 2018                  [Page 2]

Internet-Draft              CSO Use-cases                  October 2017


1  Introduction

1.1 Scope and Objectives
   Distributed computing environments allow end-users, from individual to
   enterprises,  to  access  to  large  pools  of  storage  resources,
   computational resources and various application services (e.g., Video
   Caching, Virtual Machine mobility, media content delivery, IoT, etc.).
   Data centers provide the physical and virtual infrastructure in which
   applications and services are provided.

   Since the data centers used to provide application services are
   distributed geographically around a network (or a set of interconnected
   networks), application service instantiation can have a significant
   impact  on  the  state  of  the  network  resources.  Conversely  the
   capabilities and current state of the network can have a major impact
   on the application performance.

   This draft is aimed to provide end-to-end orchestration, which is
   termed  as  Cross-Stratum  Optimization  (CSO)  across  Application
   orchestration,  Data  Center  SDN  orchestration,  and  WAN  SDN
   orchestration so that applications can be created seamlessly and
   optimally for operators and their customers.

   This document provides a set of use cases for Application-Driven Cross
   Stratum Orchestration, mainly provided by operators.

1.2 Common Terms, Abbreviations and Definitions
   CSO: It corresponds to Cross Stratum Optimization or Cross Stratum
   Optimizer, depending on the context. Due to historical reasons, it can
   also be expanded as Cross Stratum Orchestration/Orchestrator.

   Application Stratum: It is the functional grouping which encompasses
   application resources and the control and management of these
   resources. These application resources are used along with network
   services to provide an application service to clients/end-users.
   Application resources are non-network resources critical to
   achieving the application service functionality. Examples of
   application resources include: caches, mirrors, application specific
   servers, content, large data sets, and computing power. Application
   service is a networked application offered to a variety of clients
   (e.g., server backup, VM migration, video cache, virtual network on-
   demand, 5G network slicing, etc.). The entity responsible for




Lee & Contreras         Expire April 30, 2018                  [Page 3]

Internet-Draft              CSO Use-cases                  October 2017


   application stratum control and management of its resources is
   referred to as application orchestrator.

   Network Stratum: It is the functional grouping which encompasses
   network resources and the control and management of these resources
   providing transport of data between clients/end-users and application
   sources. Network resources are resources of any layer 3 or below
   (L0/L1/L2/L3)  such  as  bandwidth,  links,  paths,  path  processing
   (creation,  deletion,  and  management),  network  databases,  path
   computation, admission control, and resource reservation. In some
   cases, network resources may include L4 service functionality such as
   firewall, load balancing, etc. as part of path computation constraints.
   There     are     different     types     of     network     stratum
   controllers/orchestrators.


   ICT: It refers to Information and Communication Technology.

   Orchestration: The ongoing selection and use of resources by a server
   to satisfy client demands according to optimization criteria (as
   defined in [SDN-Arch].

   SDN Controller: The SDN controller is at the heart of the SDN
   architecture. It is the intelligent entity that controls resources to
   deliver services. Its core function is the real-time multi-dimensional
   convergence of a changing resource environment and a changing service
   demand environment toward an optimum, where the optimization criteria
   may also change in time as defined in [SDN-Arch].


2  Use Cases
   This section provides a set of CSO-related use cases and their
   requirements, mainly provided by operators.

2.1 Game Server Application
   Online gaming business is one of the fastest growing areas in the ICT
   market around the world, breaking down the barriers between nations to
   increase the number of multi-national game users. Gaming traffic is
   generated from a huge number of players' interactions during game
   sessions that can vary dynamically in terms of time or geographic
   scale. In addition, due to the nature of real-time online gaming
   characterized as a time critical service, game users are very sensitive
   to some ICT parameters such as server response time, delay, jitter,
   and synchronization time between users. Therefore, it is desirable


Lee & Contreras         Expire April 30, 2018                  [Page 4]

Internet-Draft              CSO Use-cases                  October 2017


   that the game service provider has its servers located close to the
   game users in order to guarantee quality of service by using
   distributed data centers for fast and reliable networking. This is one
   driver that is causing Provider ICT resources to move from data centers
   to areas in access networks such as a Telco DSLAM or a cable headend.

   Three terms will be used to describe this use case: ICT resource, ICT
   provider, and Game service provider. The ICT resource refers to storage,
   compute, and networking resources across WAN. The ICT provider is a
   CSO operator that provides ICT resources for its clients including
   game service providers. The Game service provider, for example an App
   owner, is a client of the CSO operator to consume ICT resources from
   the ICT provider.

   The Game service provider that uses the public cloud from an ICT
   provider to build out its game infrastructure will commonly lease
   adaptive ICT resource to save operational costs. However, the current
   static or manual resource allocation cannot meet the dynamic time-
   varying demands with unexpected changing traffic and access patterns
   from users. As a result, most of the game service providers need a
   solution to dynamically configure their ICT resources according to
   status of resource usage such as the number of active users, server
   and storage load, and network performance. It is necessary that the
   ICT provider monitor those leased ICT resources for status, and report
   the information to the game service provider for on-demand resource
   control.

   If the game service provider wants to expand the existing ICT
   infrastructure across multi-nations for its global game business,
   there is one of two options as follows. Firstly, the game service
   provider could make direct contract with each of the multiple ICT
   providers located in other countries to purchase ICT services. However,
   that requires time, effort and coordination for each ICT provider, not
   only to explore business relationships with new ICT providers, but
   also to have multiple different API interfaces for access to ICT
   resources from multiple ICT providers. Secondly, the game service
   provider can ask for dedicated ICT service from a primary ICT provider
   with which it has already an established business relationship for its
   existing ICT infrastructure. The second option enables the game service
   provider to receive full ICT services from a delegated ICT provider on
   behalf of other ICT providers, reducing operational complexity by
   eliminating multiple API interfaces from many ICT providers. Generally,
   the delegated operator can purchase network services for its customers
   at a wholesale price from other network operators, which is more
   economical than having individual small and medium game service
   providers purchase it directly from them. The delegated ICT provides
   customers with the delegated network service at a reasonable price


Lee & Contreras         Expire April 30, 2018                  [Page 5]

Internet-Draft              CSO Use-cases                  October 2017


   while being profitable. Therefore, the delegated ICT provider is
   beneficial to both the delegated operator and the game service provider.
   When we consider current international leased line service mostly
   provided manually by the delegated network operator, it is natural
   that the game service provider would also choose the second option
   because of its convenience and business economy reasons.

   The main high-level requirements of this use case include:

   . Shared information between the delegated CSO and the sub-
     contracted CSO before the delegated ICT service is requested

       - Directory information of ICT resources, available ICT resource,
          policy (such as price) etc.

   . Federation of CSOs to reserve ICT resources including computer,
     storage, and network

       - Sequential control from the delegated CSO to the sub-contracted
          CSO to reserve ICT resources

       - Reservation parameters: user ID, computing power, amount of
          storage,  network  bandwidth,  and  customized  fault  and
          performance parameters to be reported to each App Owner, etc.

   . Customized status report of assigned ICT resources to each App
     Orchestrator

       - Fault parameters: failures of server, network (link & node),
          and storage

       - Performance parameters: server load, storage load, network
          bandwidth load, etc.

   . Dynamic control of ICT resources resulting from the reported status
     data

       - Recovery (restoration and protection) of failures according to
          SLAs









Lee & Contreras         Expire April 30, 2018                  [Page 6]

Internet-Draft              CSO Use-cases                  October 2017


2.2 Automatic assignment of ICT resources to meet SLAs of App
    Orchestrator

2.2.1     ICT Auto-Scaling Monitoring
   Some network services like gaming and CDN have rapidly time-varying
   traffic patterns, making it difficult to estimate traffic levels in
   order  to  reserve  ICT  resources.  Therefore,  The  Application
   orchestrator  that  leases  ICT  resources  from  CSOs  can  easily
   oversubscribe ICT resources in order to provide services such as QoS.
   If the Application Orchestrator adaptively leases its ICT resources
   from the CSO to optimize resource usage for cost savings, it will incur
   significant overhead to monitor real-time status of its ICT resources
   to achieve this control, resulting in raising OPEX costs. Therefore,
   some ICT customers may want to avoid the costs of the management of
   these ICT resources, and will use the CSO to perform this task on their
   behalf. This use case requires an ICT auto-scaling (i.e., self-
   organizing) function to automatically scale in and out ICT resources
   according to the SLA.

   The implementation of the ICT auto-scaling function should be combined
   with several sub-functions such as monitoring network resource usage
   in real-time, analyzing optimal resource levels, and then adjusting
   those  levels  of  resource  usage.  For  example,  the  Application
   orchestrator can initiate the ICT auto-scaling service to the CSO with
   a server load level that passes a threshold value to increase the
   number of servers. Though the CSO does not receive any request to
   increase capacity of the server resources from the Application
   orchestrator, it automatically increases the number of servers to lower
   the resource load of the servers when it reaches the server load
   threshold.

   This use case can also be applicable to the delegated service described
   in the previous section. Receiving a request of the ICT auto-scaling
   service from the Application orchestrator, the delegated CSO may
   request the service to a subcontracted CSO to provide complete auto-
   scaling service over whole leased ICT resources. After receiving the
   request,  the  subcontracted  CSO  automatically  controls  the  ICT
   according to status of the ICT resources assigned.

   The main high-level requirements of this use case include:

   . Auto-scaling policy negotiated between the Application
     orchestrator and the delegated CSO, or between the delegated CSO
     and the subcontracted CSO



Lee & Contreras         Expire April 30, 2018                  [Page 7]

Internet-Draft              CSO Use-cases                  October 2017


   . Create, read, update and delete the dedicated resources as needed
     (including network, compute and storage) requested by the
     application orchestrator
   . Analytics function to determine when auto-scaling policy should be
     deployed
   . Resource usage report including current usage and billing change
     information
   . Performance and fault management of the assigned resources

2.2.2     ICT Auto-Scaling Reservation
   A further example offers high quality forwarding service through CSO.
   An Application Orchestrator can submit a forwarding guarantee request
   to a CSO if it finds there have been some problems on the forwarding
   path such as packet loss or unacceptable time delay.

   This request includes the start and end points of the path, bandwidth
   demand, and time delay requirements (actually there may be dozens of
   start points and end points when we offer service from several data
   centers to dozens of nodes on the WAN network), then the request will
   be sent to a WAN Controller and operated by a path computation element
   (PCE).

   The main high-level requirements of this use case include:

     . APIs between CSO/WAN controllers of MPLS TE, such as LSP design
        and stream Steering.
     . WAN controllers should support : Open flow/ BGP FlowSpec /path
        computation element (PCE)

2.3 Hybrid Cloud
   Hybrid cloud combines the use of both public cloud and private clouds
   and is the main development direction of cloud computing services
   today. Because of security and privacy considerations, enterprise
   customers generally prefer to store critical data and core business
   transactions in their private cloud facilities when adding public cloud
   computing resources. They use the public cloud to run the other non-
   core business and non-critical transactions for an on-demand resource
   delivery mode to reduce the overall cost of resources and add the
   flexibility they need.

   Hybrid cloud is not just a simple addition of private cloud and public
   clouds, and it always has the following three features:


Lee & Contreras         Expire April 30, 2018                  [Page 8]

Internet-Draft              CSO Use-cases                  October 2017


     (1)Unified resource view: A hybrid cloud needs to have a unified
       service portal which includes a unified monitoring interface of
       all resources being used. This is a unified display of the
       customer resources located in both the public cloud and private
       cloud.
     (2) Unified management of resources: A hybrid cloud should handle
       the life-cycle management of all resources deployed in both the
       private cloud and public clouds through the unified portal
       described above. All customer resources are presented, searched
       and monitored at the portal as well as unifying resource
       application and billing processes.
     (3)Unified inter cloud networking: in hybrid cloud scenarios,
       customers always lease Virtual Private Cloud (VPC) resources in
       a public cloud, and then connect the resources to their own
       private cloud. It requires an interconnection between private
       cloud and VPC in public cloud, and it needs to choose an
       appropriate networking solution.
   With the support and cooperation of the cloud management platform, the
   unified view and management of the hybrid cloud can be implemented by
   calling an open API from the management platform of the hybrid cloud
   to the public cloud. Currently, unified networking has become the key
   requirement of a Hybrid Cloud. For different business demands, there
   are different inter cloud networking solutions for a hybrid cloud. For
   example, if hybrid cloud customers want to use the public cloud for
   data backup, then it only needs a layer 3 connection between the
   private and public clouds; on the other hand, if the customers want to
   achieve a virtual machine resource expansion or virtual machine
   migration, then it needs a layer 2 connection. Hybrid cloud networking
   based on layer 2 connections is more challenging today.

   The traditional networking solutions of a Hybrid Cloud always use VPN
   and leased line technologies to establish a network connection between
   private and public clouds. For example, the direct connect service
   launched by Amazon Web Services (AWS) is a networking solution between
   the customer private cloud and AWS public cloud. Essentially, direct
   connect is a leased line service that can support hourly billing, so
   it requires the operator partners of Amazon to provide the support of
   network connections. Comparing the two techniques, VPN is more mature,
   easier to configure, and has a lower cost than a leased line service.
   However,  VPN  has  some  disadvantages:  it  has  relatively  lower
   performance and availability than a leased line service and its
   implementation depends on the underlying physical network, which is
   difficult to guarantee QoS in a consistent manner. Compared to a VPN,


Lee & Contreras         Expire April 30, 2018                  [Page 9]

Internet-Draft              CSO Use-cases                  October 2017


   leased line has high performance and availability, but it requires
   customers to pay a higher cost, and its configuration is not flexible.
   Therefore, neither the VPN nor leased line is unable to fully meet
   networking requirements in hybrid cloud scenarios.

   For hybrid cloud services provided by operators, introducing SDN to
   build and manage connection between private cloud and public cloud is
   valuable. It can realize a coordinated scheduling among private cloud,
   public cloud and inter cloud networking under the drive of business,
   and  solves  the  problems  faced  by  the  traditional  networking
   technologies.

   The hybrid cloud resources orchestrator schedules cloud and network
   resources by calling the management platform API of the private cloud
   and public cloud and the north bound interface of the inter cloud
   networking controller. Among them, the status of all cloud and network
   resources can be displayed and managed. When the hybrid cloud business
   needs a network connection between private cloud and public cloud, the
   request will be sent to orchestrator, and the orchestrator can then
   drive the controller to establish an on-demand inter cloud connection
   between private cloud and public cloud.

   Currently, some operators, such as China Telecom, are actively
   developing hybrid cloud services based on SDN. The core idea is
   developing a hybrid cloud resource orchestrator base on the OpenStack
   cloud management platform, to achieve unified management and display
   customer private cloud and OpenStack public cloud resources. To
   simplify the implementation, the orchestrator is developed based on
   the OpenStack-based private cloud management platform. Meanwhile, the
   orchestrator will adapt to multi-vendor SDN network solutions, to build
   network connection between the private and public clouds on demand.

   SDN-based hybrid cloud solutions focus on the following:

 (1)           Hybrid cloud resource orchestrator
     A Hybrid cloud resource orchestrator can be developed based on
     OpenStack, and it can support all of the hybrid cloud resources to
     be displayed, managed and connected on-demand. OpenStack is a
     mainstream open source cloud management platform technology, with
     comprehensive cloud resource management capabilities. The hybrid
     cloud resource orchestrator drives cloud and network resources by
     calling restful APIs of OpenStack and the SDN controller, but there
     are problems need to be solved, namely:





Lee & Contreras         Expire April 30, 2018                 [Page 10]

Internet-Draft              CSO Use-cases                  October 2017


     . Unified authentication: The hybrid cloud resource orchestrator
        can simultaneously display and manage private and public cloud
        resources, which will need a Security Assertion Markup Language
        (SAML) 2.0-based authentication mechanism.  This mechanism in a
        cloud federation environment will first enable trust between
        private cloud and public cloud interfaces, and then support inter
        cloud resources access.
     . Network Mapping: The orchestrator needs to access the network
        segment identification of private cloud, public cloud and inter-
        cloud network connections, and then do a mapping of those network
        segments IDs to build an end-to-end connection, which establishes
        a network resource information library.

 (2)           Inter-cloud SDN solution
     In a hybrid cloud network, the gateway and WAN devices are controlled
     by a corresponding SDN controller(s). Compared to other network
     scenarios, an operator's network is complex. For example, there are
     multiple technologies, vendors, models and other aspects that
     present challenges in building efficient network connections between
     clouds. In order to deal with this situation, hybrid cloud networking
     requires adapting various SDN network programs, such as adapting
     specific areas and vendor-specific controllers.

     The hybrid cloud resource orchestrator drives SDN solutions by
     calling restful APIs of the SDN controller(s). In order to achieve
     interoperability between the cloud's internal network and the inter-
     cloud SDN network, a restful API should minimally include the
     following   information:   NETWORK_TYPE,   PHYSICAL_NETWORK   and
     SEGMENTATION_ID.  This  information  will  be  provided  to  the
     orchestrator by the inter-cloud SDN network controller(s).

 (3)           IDC SDN Controller
     In order to achieve communication between the Intra Data Center (IDC)
     internal network segment (including private and public clouds) and
     the external inter-cloud SDN network segment, the network controller
     within the IDC should provide the necessary network information to
     the orchestrator.  Therefore, it needs to provide the restful north-
     bound API as an Inter-cloud SDN controller.

     In  addition,  the  IDC  SDN  Controller  is  responsible  for  the
     configuration and deployment of the cloud network in the VPC resource
     pool of the public cloud, and should provide an NBI to the hybrid
     cloud resource orchestrator.


Lee & Contreras         Expire April 30, 2018                 [Page 11]

Internet-Draft              CSO Use-cases                  October 2017


 (4)           Heterogeneous resource management
     Currently, VMware resources are widely used in the enterprise private
     cloud. For implementing heterogeneous resources management, the
     OpenStack-based  hybrid  cloud  orchestrator  should  resolve  the
     problems as to how OpenStack can manage VMware resources by calling
     VMware open APIs and it relies on the joint efforts of VMware and
     the OpenStack community.

     From the research and practice based on SDN Hybrid Cloud done by
     China Telecom, it can be seen that the system architecture has great
     similarity with the CSO project, which proves the rationality and
     feasibility of the CSO architecture.

   The main high-level requirements of this use case include:

  . APIs between CSO controller/hybrid cloud resource orchestrator and
     management platform of private cloud and public cloud for hybrid
     cloud resource unified management and display.
  . Southbound interface model of CSO controller/hybrid cloud resource
     orchestrator for adapting various SDN solutions use to connect
     private cloud and public cloud on demand.
  . Workflow design of CSO controller/hybrid cloud resource orchestrator
     for hybrid cloud management and operation, which includes: user
     authentication, resource allocation, connection establishment, and
     application deployment.
  . End to end system architecture design to meet carrier grade service
     requirements, such as high performance, high availability, high
     scalability and high interoperability.

2.4 Virtual CDN
   CDN providers can be willing to deploy virtualized CDN (vCDN) end
   points internally to the facilities of network providers in order to
   improve the experience perceived by end customers when accessing cached
   content.

   The  CDN  application  will  interact  with  the  Network  Provider
   Orchestrator (as CSO Orchestrator in this case) in order to get access
   to both DC and network resources and/or capabilities for the mentioned
   functionalities. The CDN application will be required access to the
   virtual CDN end point in order to handle the virtual cache. Such access
   could be indirect (via the Network Provider Orchestrator itself) or
   direct (having access to the DC Controller), getting access to
   management interfaces that can permit remote management and control of


Lee & Contreras         Expire April 30, 2018                 [Page 12]

Internet-Draft              CSO Use-cases                  October 2017


   the virtual cache functionality for the consistency of the CDN service
   end-to-end.

   This situation necessarily requires agreement between parties, which
   introduces as main high-level requirements:

  . Deployment  of  specific  virtualized  capabilities  for  traffic
     distribution in the form of specialized network functions, i.e.
     virtual cache, to be deployed in DCs of the network providers
  . Configuration of circuits needed for feeding and connecting the
     virtual caches to the origin server (in CDN provider's network)
  . Configuration of QoS, SLAs, etc., as guaranteed capabilities to
     ensure proper service offering
  . Mechanisms for scaling-in and/or -out according to changing demand
     dynamics
  . Virtual cache relocation for the same reasons, or even for making
     some content closer to the final user.


 Summary and Conclusions


   In this document, we have discussed a set of use-cases to which the
   CSO concept is well applied. A set of requirements are identified for
   each use-case. From an implementation standpoint, these requirements
   will be the basis for data modeling and protocol design for the CSO
   interfaces identified in this document.

 References


   [SDN-Arch] SDN Architecture, Issue 1.1, 2016, ONF TR-521.














Lee & Contreras         Expire April 30, 2018                 [Page 13]

Internet-Draft              CSO Use-cases                  October 2017


 Contributors

Authors' Addresses

   Young Lee
   Huawei Technologies

   Email: leeyoung@huawei.com

   L. M. Contreras
   Telefonica

   Email: luismiguel.contrerasmurillo@telefonica.com

   Carlos J. Bernardos
   UC3M

   Email: cjbc@it.uc3m.es

   Honglei Xu
   China Telecom

   Email: xuhl.bri@chinatelecom.cn

























Lee & Contreras         Expire April 30, 2018                 [Page 14]