Skip to main content

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

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 , JF Tremblay , Jun Bi
Last updated 2015-02-01
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-03
Network Working Group                                           Y. Cheng
Internet-Draft                                              China Unicom
Intended status: Informational                              JF. Tremblay
Expires: August 6, 2015                                         Viagenie
                                                                   J. Bi
                                                     Tsinghua University
                                                        February 2, 2015

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

Abstract

   Large scale DCs can provide various services and usually have a lot
   of internal and external links.  Service provisioning and network
   connectivity configuration are complex.  This draft analyzes some use
   cases in Distributed Data Centers (DDC), and the applicability of
   SUPA data models and platform which can be used for better resource
   usage and easy service/network configuration.

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 August 6, 2015.

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

Cheng, et al.            Expires August 6, 2015                 [Page 1]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

   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
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Challenges Faced by Data Center ISPs . . . . . . . . . . . . .  4
   5.  SUPA Benefits  . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  DDC Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  5
     6.1.  Inter DC Connectivity  . . . . . . . . . . . . . . . . . .  5
     6.2.  vDC Connectivity . . . . . . . . . . . . . . . . . . . . .  6
     6.3.  Dynamic Link Configuration for DC  . . . . . . . . . . . .  7
     6.4.  VPC to DC Connectivity . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Cheng, et al.            Expires August 6, 2015                 [Page 2]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

1.  Introduction

   The SUPA (Shared Unified Policy Automation) work aims at providing
   data models, including topology data models, network service specific
   data models, policy data models, for Operation and Management
   Application (OAMA) to easily, accurately, and efficiently select and
   use the available communication network capabilities.  An example of
   the data model can be found in
   [I-D.zaalouk-supa-configuration-model].  Operation and Management
   Application (OAMA) is used by an a communications service provider
   and/or operator to deploy and manage a communication network.  An
   example of OAMA 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, leased line, 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.

   DC and network may belong to different operators.  If a DC operator
   needs to configure network connecivity for DCs, they may need to
   coperate with network oprators.  Network operators can define and
   provide data models to enable this.

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

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   The terminology used in the SUPA problem statement draft
   [I-D.zhou-supa-framework] and

Cheng, et al.            Expires August 6, 2015                 [Page 3]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

   [I-D.karagiannis-supa-problem-statement] apply also to this draft.

   DDC       Distributed Data Center

   MA        Management Agent

   OAMA      Operation and Management Application

   vDC       virtual Data Center

   VPC       Virtual Personal Cloud (PC)

4.  Challenges Faced by Data Center ISPs

   There are many challenges in traditional data centers: 1)
   infrastructure and network link is usually leased, depending on
   manual planning and design, which leads to low resource usage and
   high cost; 2) Service expansion is limited in a single physical DC.
   Each DC resource is isolated, so service and resource can only be
   deployed in one single DC; 3) VAS (Value Added Service) is
   provisioned via static configuration, which brings complex training,
   long service TTM time and poor flexibility.  This could not meet the
   requirements of complex use cases, e.g., lot of VAS devices,
   significant differences between various services.

5.  SUPA Benefits

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

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

   o  SUPA provides overall DC resource integration: Network resource
      virtualization, inter-DC resource integration, virtual DC (vDC)
      service provisioning, unified inter-DC service, which reduces
      OPEX.

   o  SUPA provides automatic E2E service delivery: Network (including
      virtual network), computing, inter-DC management of storage
      resource, automatic service delivery, which improves operation
      efficiency.

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

Cheng, et al.            Expires August 6, 2015                 [Page 4]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

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

   The following sections will illustrate three typical cases in
   distributed data center which could benefit from SUPA architecture.

6.  DDC Use Cases

6.1.  Inter DC Connectivity

                   +--------------------------+
                   |    Service Management    |
                   +--------------------------+
                               ^
                               | Inter DC connectivity
                               | and policy
                               | data models
                               v
                   +--------------------------+
                   | Management Agent (MA)    |
                   +--------------------------+
                      /                   \
                     /                     \
              +---------+                   \
             /|  DC1    |\                   \
            / +---------+ \              +-----------+
           |      | d1     \___a1________|   DC-A    |
           |      |                      |           |
           |  +---------+                +-----------+
        d3 |  |  DC2    |\
           |  +---------+ \              +-----------+
           |      | d2     \___a2________|   DC-B    |
           |      |        ____a3________|           |
            \ +---------+ /              +-----------+
             \|  DC3    |/
              +---------+

                      Figure 1: Inter DC Connectivity

   There can be a lot of links between data centers.  Configuration of
   these links is complex.  As shown in Figure 1, connectivity data
   models and policy data models can be defined to automate the
   configuration procedures.  The service data model for connectivity

Cheng, et al.            Expires August 6, 2015                 [Page 5]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

   will specify attributes of links, e.g. the end points of links,
   bandwidth and QoS, etc.  The policy model can specify some high level
   requirements to the links, like routing strategy and price/cost
   stragety.

   Inter DC connections can be classified into to types: connections
   within a single administrative domain and connections across multiple
   administrative domains.  Links d1, d2 and d3 are within an
   administrative domain; and links a1, a2 and 3 are across domains.
   The difference between them is, connections across multiple
   administrative domain require extra negotiation and authentication/
   authorization, which can be achieved via communications between MAs.
   Data models for this purpose should also be defined.

6.2.  vDC Connectivity

                   +--------------------------+
                   |    Service Management    |
                   +--------------------------+
                               ^
                               | vDC connectivity
                               | and policy
                               | data models
                               v
                   +--------------------------+
                   |          Network         |
                   |  Manager / Controller    |
                   +--------------------------+
                      /                    \
                     /                      \
                    /                        \
    +-------------------+               +-------------------+
    | DC1               |               | DC2               |
    | +---------------+ |   vDC link    | +---------------+ |
    | | Tenant1 (vDC) |<----------------->| Tenant1 (vDC) | |
    | +---------------+ |               | +---------------+ |
    |                   |               |                   |
    | +---------------+ |               | +---------------+ |
    | | Tenantk (VDC) | |               | | Tenantn (vDC) | |
    | +---------------+ |               | +---------------+ |
    +-------------------+               +-------------------+

                        Figure 2: vDC Connectivity

   A DC tenant may have resources, e.g. network, computing, storage,
   etc, in multiple physical DCs.  DC operators will provide internal
   network connections for these distributed resources, and make it look
   like one seamless entity, which can be called as virtual DC (vDC).

Cheng, et al.            Expires August 6, 2015                 [Page 6]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

   The internal links for vDC can be implemented via tunneling
   technologies, e.g.  VPN or VxLAN, etc.

   As show in Figure 2, connectivity data model and policy can be
   defined to automate the links configuration for vDCs.  A policy model
   may contain information like user's grade which will be use to derive
   service level parameters, including bandwidth, QoS, etc.  The
   connectivity data model may provide the information about the
   resource location for tunnel setup.

6.3.  Dynamic Link Configuration for DC

   Static and over provisioning for DC links is not always a good
   solution.  Sometimes dynamic configuration is necessary.

   One case is virtual machine migration and large amount of data
   transfer between DCs.  But this kind of activity does not happen
   frequently.  A dedicated link with constant bandwidth for this
   purpose is too expensive.  The network operator should allow the DC
   operator to create a link on demand when necessary.  This link may
   have large bandwidth but last for a limit time period.  An
   alternative is to have a static link but with limited bandwidth; and
   the bandwidth can be increased on demand for a short period.

   Data models can help to automate these kind of configurations.  These
   data models will help DC operators to add and remove links, change
   the attributes of links.

Cheng, et al.            Expires August 6, 2015                 [Page 7]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

6.4.  VPC to DC Connectivity

                   +--------------------------+
                   |    Service Management    |
                   +--------------------------+
                               ^
                               | VPC to DC connectivity
                               | and policy
                               | data models
                               v
                   +--------------------------+
                   |          Network         |
                   |  Manager / Controller    |______________
                   +--------------------------+              \
                      /                    \                  \
                     /                      \                  \
                    /                        \                 |
    +-------------------+               +-------------------+  |
    | Cloud for VPCs    |               |                   |  |
    | +---------------+ |   VPC link    |  DC1 (Database)   |  |
    | |     VPC1      |-----------------|                   |  |
    | +---------------+ \               +-------------------+  |
    | +---------------+ |\                                     |
    | |     VPC2      | | \                                    |
    | +---------------+ |  \            +-------------------+  |
    | +---------------+ |   \  VPC link |                   | /
    | |    ......     | |    \__________|  DC2 (Storage)    |/
    | +---------------+ |               |                   |
    +-------------------+               +-------------------+

                     Figure 3: VPC to DC Connectivity

   As virtualization technology becomes more and more popular, some
   organizations and companies now begin to use cloud platform to
   support their computer desktop, rather than using physical personal
   computers and workstations.  The kind of cloud platform can be a
   commercial solution, e.g.  Amazon's cloud platform.  VPCs at cloud
   service providers' DC may keep on running for a long time even if no
   user is actually accessing it; but the cloud platform may bring VPCs
   into power saving mode when there is little or no load in it.

   The organizations and companies, e.g. a university, sometimes provide
   some internal services like database which is only available to the
   VPC but not available to users in the public network.  These kind of
   services can be located in an cloud operator's DC.

   The VPC and the internal services sometimes are located in different

Cheng, et al.            Expires August 6, 2015                 [Page 8]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

   DCs, or even provided by different vendors.  VPNs are configured for
   the VPCs to provide connection to the DCs where services are hosted.

   As shown in Figure 3, connectivity data models and policy data models
   can be defined to automate the configurations of links between VPC
   and DC where service is located.  In the data models, the location
   where internal service is located should be specified; a user/VPC's
   access rights can also be specified.

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

8.  IANA Considerations

   Not applicable.

9.  Acknowledgements

   The authors of this draft would like to thank the following persons
   for the provided valuable feedback: Cathy Zhou, Georgios Karagiannis,
   Scott O. Bradner, James Huang.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  informative References

   [I-D.karagiannis-supa-problem-statement]
              Karagiannis, G., Will, W., Tsou, T., Qiong, Q., Contreras,
              L., and P. Yegani, "Problem Statement for Shared Unified
              Policy Automation (SUPA)",
              draft-karagiannis-supa-problem-statement-02 (work in
              progress), October 2014.

   [I-D.zaalouk-supa-configuration-model]
              Zaalouk, A., Pentikousis, K., and W. Will, "YANG Data

Cheng, et al.            Expires August 6, 2015                 [Page 9]
Internet-Draft   Use cases for DDC Applications in SUPA    February 2015

              Model for Configuration of Shared Unified Policy
              Automation (SUPA)",
              draft-zaalouk-supa-configuration-model-01 (work in
              progress), October 2014.

   [I-D.zhou-supa-framework]
              Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The
              Framework of Shared Unified Policy Automation (SUPA)",
              draft-zhou-supa-framework-00 (work in progress),
              January 2015.

Authors' Addresses

   Ying Cheng
   China Unicom
   P.R. China

   Email: chengying10@chinaunicom.cn

   JF Tremblay
   Viagenie

   Email: jean-francois.tremblay@viagenie.ca

   Jun Bi
   Tsinghua University
   Bei Jing
   China

   Email: junbi@cernet.edu.cn

Cheng, et al.            Expires August 6, 2015                [Page 10]