Skip to main content

Use Cases for Distributed Data Center Applications in SUPA
draft-cheng-supa-ddc-use-cases-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Ying Cheng , Cathy Zhou , Georgios Karagiannis , JF Tremblay
Last updated 2014-10-27
Replaces draft-cheng-aponf-ddc-use-cases
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cheng-supa-ddc-use-cases-01
Network Working Group                                           Y. Cheng
Internet-Draft                                              China Unicom
Intended status: Informational                                   C. Zhou
Expires: April 27, 2015                              Huawei Technologies
                                                          G. Karagiannis
                                                    University of Twente
                                                            JF. Tremblay
                                                                Viagenie
                                                        October 27, 2014

       Use Cases for Distributed Data Center Applications in SUPA
                 draft-cheng-supa-ddc-use-cases-01

Abstract

   This document provides several distributed data center (ddc) use
   cases and explains how an operator could use SUPA (Shared Unified
   Policy Automation) to provide these applications.

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 March 21, 2015.

Copyright Notice

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

Cheng, et al.            Expires April 27, 2015                 [Page 1]
Internet-Draft   Use cases for DDC Applications in SUPA   October 2014

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Challenges Faced by Data Center ISPs  . . . . . . . . . . . .   3
   4.  SUPA Benefits . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Bandwidth Usage Optimization between DCs. . . . . . . . . . .   4
   6.  Server Synchronization between Datacenters  . . . . . . . . .   5
   7.  Low Delay Link Selection between DCs  . . . . . . . . . . . .   6
   8.  On-demand Path Creation between Datacenters . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction

   The SUPA (Shared Unified Policy Automation) work aims at providing
   the network management application-based policy protocol(s),
   mechanisms and models required by network management applications to
   easily, accurately, and efficiently select and use the available
   communication network capabilities through the use of network
   management policies.  A Network Management Application is used by a
   communications service provider and/or operator to monitor, control,
   analyze and manage a communication network.  An example of a Network
   Management Application is a set of actions used by an Operational
   Support System (OSS) entity to perform network configuration.
   Several SUPA use cases have been introduced in the problem statement
   document.  This document reviews various use cases for Distributed
   Data Center (DDC) applications.

   Take a large-scale Internet Data Center (IDC) operator as an example,
   it provides server hosting, bandwidth, value-added services to
   enterprises and ISPs, and has more than 10 data centers using over
   one Tbps of bandwidth in a capital city.  In this IDC network,
   traffic at each site is routed via configuring policy routes and
   adjusting routes prioritization to choose an outgoing link.  This
   type of static provisioning comes with high costs and poor
   operability.  Furthermore, the link bandwidth resources in the data
   centers are not efficiently utilized.

   Services usually do not have consistent bandwidth requirements at all
   times of the day, e.g. a video service provider usually requires less
   bandwidth during business hours and more during evenings.  Some
Cheng, et al.            Expires April 27, 2015                 [Page 2]
Internet-Draft   Use cases for DDC Applications in SUPA   October 2014

   applications have relative high QoS requirements that may change over
   time. For example provisioning bandwidth and QoS for all clients of
   an Instant Messaging (IM) app is not reasonable and not a cost-
   effective solution.  The operator would like to be able to optimize
   traffic routes dynamically so as to have the ability to load balance
   between data centers and links, and direct customer traffic via
   policies (e.g., models, software programs routines) based on customer
   grade and QoS requirements. It will also be useful to monitor the
   real-time traffic flow and have a visualized report.

   Traffic engineering applications can provide dynamic traffic
   adjustment demands to the network based on link status reported by
   the network.

   SUPA will define network management application-based policy
   protocol(s), mechanisms and models required to map application's
   demands to network management policies en procedures (e.g. traffic
   redirection based on customer's grade and link status), which can be
   directly enforced by a network management system on network devices,
   to meet the operator's demands.

   This document illustrates several distributed datacenter (DDC)
   applications and explains how an operator could use SUPA to provide
   these applications.

2. Terminology

   The terminology used in the SUPA problem statement draft
   [ID.karagiannis-supa-problem-statement-00] applies also to this draft.

3. Challenges Faced by Data Center ISPs

      There are many challenges in traditional data centers: 1)
   Framework and bandwidth is mainly leased, depending on manual
   planning and design, which leads to low resource usage and high cost;
   2)Service expansion is limited in single physical DC.  Each DC
   resource is isolated, so service and resource can only be deployed in
   one single DC. On the other hand, multi-tenant service among
   different DCs are desirable for such communication between tenants or
   VMs located in different DCs; 3)VAS (Value Added Service) is
   provisioned via static configuration, which brings complex draining,
   long service TTM time and bad flexibility.  This could not meet the
   requirements of complex use cases, e.g., too many VAS devices, big
   difference of service requirements.

4. SUPA Benefits

   To solve the above challenges for data center ISPs, SUPA could be
   applied in the following ways:

Cheng, et al.            Expires April 27, 2015                 [Page 3]
Internet-Draft   Use cases for DDC Applications in SUPA   October 2014

      o  SUPA provides an open network architecture: Open architecture,
   fast interconnection with third party cloud platform, support fast
   service innovation, unified architecture and unified planning;

      o  SUPA provides overall DC resource integration: Network resource
   virtualization, inter-DC resource integration, vDC service
   provisioning, unified inter-DC service among different tenants or
   clients, which reduces opex;

      o  SUPA provides automatic E2E service delivery: Network
   (including virtual network), computing, inter-DC management of stored
   resource, automatic service delivery, automatic VPN connection
   configurations among DCs which improves operation efficiency;

      o  SUPA improves DDC network usage: Intelligent scheduling of DDC
   traffic, improving link usage efficiently.

      o  SUPA provides VAS service on-demand provisioning automatically:
   Create or delete VAS nodes on-demand, based on various service
   requirements; ABPD indicates network forwarding policy based on the
   VAS routing, to achieve automatic draining and automatic
   configuration of VAS device policy.

   The following sections will illustrate four typical cases in
   distributed data center which could benefit from SUPA architecture.
   The policies transmitted from Network Management Applications to the
   DCs will be represented by a network configuration model described
   in[ID.adel-supa-configuration-model].

5. Bandwidth Usage Optimization between DCs

   A large-scale data center may have more than one hundred links.  The
   network between data centers is often leased and the applied
   bandwidth is very expensive. Also the communication between different
   tenants or clients which located on multiple data centers has the
   same issue. If the traditional shortest path algorithm is used to
   calculate a path based on static cost, then the path calculation
   cannot be dynamically adjusted based on real-time bandwidth usage.
   This will result in bandwidth waste.

   Figure 1 shows how to improve the bandwidth usage efficiency between
   data centers in case of two users located on different DCs.  There
   are two paths from DC A to DC B, for example, A-->B (path 1) and A--
   >C-->B (path 2).  When the bandwidth between A and B is not
   sufficient, A will automatically transmit the traffic via C.  The
   network management applications will configure a threshold T (e.g.,
   80%) for the path bandwidth usage ratio and send it to A.  When an
   application request is received, A will detect the bandwidth usage of
   both paths.  When the bandwidth usage ratio of path 1 (T1) has
   exceeded value T (e.g., 90%), while the bandwidth usage ratio of path

Cheng, et al.            Expires April 27, 2015                 [Page 4]
Internet-Draft   Use cases for DDC Applications in SUPA   October 2014

   2 (T2) is much less than T (e.g., 10%), it will transmit the traffic
   to B via C, even though P1 is the shortest path between A and B.

   In this case, a VPN tunnel can be instantiated from A to B to setup
   the data path for the data transmission between data centers. The VPN
   request only specify the starting point and the termination point and
   the controller will make the decision which way to go based on the
   policy and the link state. And also it will configure the
   corresponding network elements and setup the VPN tunnel. In this way,
   the available bandwidth between A and B will be used efficiently, and
   risks of congestion between the datacenters will be avoided.

                     +-------------------+
                     |Network Management |
                     |                   |
                      |Applications       |
                      +--------+----------+
                            |                 +----------+
                Policy      |                 |          |
             (Threshold, T) |                ->    B     |
                            |              /  |          |
                            |        T1   /   +----^-----+
                            |            /            |
                            +---v-----+ /             |
                            |         |/              |
                            |   A     +               | T2
                            |         |\              |
                            +---------+ \             |
                                         \            |
                                       T2 \    +----+-----+
                                           \   |          |
                                              ->    C     |
                                               |          |
                                               +----------+
   Figure 1: Bandwidth usage optimization for DC Interconnection

6. Server Synchronization between Datacenters

   A Data center involves many systems and the server synchronization is
   specifically important for DCs.  Once there is error in server
   synchronization, the system will not run regularly, which brings
   mistakes and failures.  However, the server synchronization is not
   easy to be realized during the daytime when the Data Center servers
   are fully loaded services.  Instead, many operators choose to make
   the synchronization in the evening at some regular intervals. Figure
   2 shows how server synchronization between datacenters can be
   realized.  Two servers separately in DC A and DC B are required to
   synchronize daily.  The Network Management Applications, as defined
   in the SUPA architecture, are configured with several Policies, e.g.,
   syn time (2am to 3am everyday for instance) on when to synchronize
Cheng, et al.            Expires April 27, 2015                 [Page 5]
Internet-Draft   Use cases for DDC Applications in SUPA   October 2014

   the servers, BW (a required bandwidth to be maintained between the
   period), and the path information (which path between the two DCs
   costs lower).  The Network Management Applications will send this
   policy information to both DC A and DC B.  In this case, the
   controller will make the decision for the best time to start a VPN
   connection between the data centers and the VPN request should
   contain related information such as time, duration, BW, all of which
   are decided by the policy based on the network traffic condition. In
   this way, the two servers synchronize automatically everyday from 2am
   to 3am, which will guarantee the normal operation of the servers.

                       +--------------------+
                       |Network Management  |
                       |                    |
                       |Applications        |
                       |                    |
                       +---------+----------+
                           /            \
                          /              \
                         /                \
                        /        Policy    \
                        /     (Syn Time,BW,  \
                      /      Path)           \
                      |                       |
                +-----v----+              +---v------+
                |          |  VPN tunnel  |          |
                |   A      +--------------+    B     |
                |          |              |          |
                +----------+              +----------+

             Figure 2: Server Synchronization between DCs

7. Low Delay Link Selection between DCs

   Traditional routing algorithms do not consider real-time link
   conditions, some requirements of specific applications cannot be met
   timely, e.g., delay is a key requirement for the audio services
   (Skype for example).  How to select a better link based on the delay
   of each link becomes important for the application. Figure 3 shows an
   example of link selection between datacenters according to the delay
   of each link.  A value "d" is configured in the Network Management
   Applications for the specific applications, e.g., less than 100 ms.
   The value "d" will be sent to the ingress data center A for the A to
   detect the delays in both links between A and B.  A will transmit the
   traffic via the link 1 to B if d1 is less than d and d2 is larger
   than d.  In this case, the service quality and QoE user experience
   will be enhanced.

Cheng, et al.            Expires April 27, 2015                 [Page 6]
Internet-Draft   Use cases for DDC Applications in SUPA   October 2014

                +--------------------+
                |Network Management  |
                |                    |
                |Applications        |
                |                    |
                +--------+-----------+
                         |
                         |
                         | Policy (delay value "d")
                         |
                   |
                         |            d2
                      +----v----+  ------------   +----------+
                      |         |/              \ |          |
                      |   A     |----------------->    B     |
                      |         |      d1         |          |
                      +---------+                 +----------+

       Figure 3: Low Delay Link Selection between Datacenters

8. On-demand Path Creation between Datacenters

   Figure 4 illustrates a problem related to bandwidth fragmentation.
   There are two users located on DC A and DC B, respectively. From DC A
   to DC B, two paths (A-->B, A-->C-->B) can be reached.  From A to B,
   only 2Gbps bandwidth is left and 8Gbps is used, and from A to B via C,
   the link capacity is 2Gbps.  So there is no bandwidth to transmit the
   traffic when there is a 4Gbps requirement from A to B, which causes
   that the bandwidth is not effectively used.

                            There is no
                            bandwidth to
             +----------+   transmit 4G    +----------+
             |          |   traffic        |          |
             |    A     +------------------+    B     |
             |          |10G link (8G used,|          |
             +----------+ 2G left)         +----------+
                     \                        /
                       \                    /
                         \2G            2G/
                           \            /
                             \        /
                            +----------+
                            |          |
                            |    C     |
                            |          |
                            +----------+

Cheng, et al.            Expires April 27, 2015                 [Page 7]
Internet-Draft   Use cases for DDC Applications in SUPA   October 2014

           Figure 4: Bandwidth Fragmentation Problem

   Figure 5 provides a method to create on-demand path and bundle the
   path capabilities between datacenters.  The bandwidth bundle
   capability is configured and sent to the DC A by the network
   management applications.  When the bandwidth is not sufficient to
   meet the requirements for a specific application, A could bundle the
   bandwidth in the two links. More specifically, the on-demand path
   creation can be implemented via a VPN tunnel start from A to B. The
   network management application will tell the controller to start a
   VPN connection between A to B, and the controller will make the
   decision for the bandwidth request of the VPN service according to
   the policy and the current link state. In addition, the network
   capability, e.g., bandwidth bundle capability, is firstly negotiated
   between network management applications and the network element via
   other methods, which are out of the scope of this document.

           +--------------------+
           |Network Management  |
           |                    |
           |Applications        |
           |                    |
           +---------+----------+
                     |
                     |Policy (Bundle two paths)
                     |
                     |
               +-----v----+              +----------+
               |          |  2G  VPN     |          |
               |    A     +-------------->    B     |
               |          |              |          |
               +----------+              +----^-----+
                     \                       /
                       \                    /
                         \  2G VPN        / 2G VPN
                           \            /
                             \        /
                            +----------+
                            |          |
                            |    C     |
                            |          |
                            +----------+
         Figure 5: On-demand Path Creation between DCs

9. Security Considerations

   Security is a key aspect of any protocol that allows state
   installation and extracting of detailed configuration states.  More
   investigation remains to fully define the security requirements, such
   as authorization and authentication levels.
Cheng, et al.            Expires April 27, 2015                 [Page 8]
Internet-Draft   Use cases for DDC Applications in SUPA   October 2014

10.  IANA Considerations

      Not applicable

11.  Acknowledgments

   N/A.

12.  Authors' Addresses

      Ying Cheng
      China Unicom
      P.R. China
      Email: chengying10@chinaunicom.cn

      Cathy Zhou
      Huawei Technologies
      Bantian, Longgang District
      Shenzhen  518129
      P.R. China
      Email: cathy.zhou@huawei.com

      Georgios Karagiannis
      University of Twente
      Email: g.karagiannis@utwente.nl

      JF Tremblay
      Viagenie
      Email: jean-francois.tremblay@viagenie.ca

Cheng, et al.            Expires April 27, 2015                 [Page 9]