Network Working Group Y. Cheng Internet-Draft China Unicom Intended status: Informational JF. Tremblay Expires: October 5, 2015 Viagenie J. Bi Tsinghua University L. M. Contreras Telefonica I+D April 3, 2015 Use Case for Distributed Data Center in SUPA draft-cheng-supa-ddc-use-cases-06 Abstract Large scale DCs can provide various services and usually have a lot of internal and external links, and these links are usually VPNs. The Service provisioning and network connectivity configurations are complex and sometimes dynamic, for which manual configuration is not suitable. This draft analyzes the use case in Distributed Data Centers (DDC), in which some VPN scenarios are covered, and the applicability of Simplified Use of Policy Abstractions (SUPA) data models which can be used for better and automated 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 October 4, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Cheng, et al. Expires October 4, 2015 [Page 1] Internet-Draft Use cases for DDC Applications in SUPA April 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Challenges Faced by Data Center ISPs . . . . . . . . . . . . 4 5. SUPA Benefits . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Scenario:Inter DC Connectivity . . . . . . . . . . . . . 5 6.2. Scenario:vDC Connectivity . . . . . . . . . . . . . . . . 7 6.3. Scenario:Dynamic Link Configuration for DC . . . . . . . 9 6.4. Scenario:DC Connectivity for Virtual Private Clouds (VPC) 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.2. informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The SUPA (Simplified Use of Policy Abstractions) work aims at providing data models, including topology data models, network service specific data models, policy data models, 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]. Service Manager (SM) is used by an a communications service provider and/or operator to deploy and manage services on top of network facilities. An example of SM is a set of applications 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 scenarios for Distributed Data Center (DDC) use case. Take a large-scale Distributed Data Center (DDC) operator as an example, it provides server hosting, leased line, value-added Cheng, et al. Expires October 4, 2015 [Page 2] Internet-Draft Use cases for DDC Applications in SUPA April 2015 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. In quite some of the scenarios, the links between DCs are VPNs, including L2VPN, L3VPN, etc. SUPA will be mainly used for those VPN configurations. Although there may be some cases where physical links are used, but those are out of the scope of this draft. DC and network may belong to different operators. If a DC operator needs to configure network connectivity for DCs, it may need to cooperate with network operators providing such connectivity. 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 [I-D.karagiannis-supa-problem-statement] apply also to this draft. DC Data Center DDC Distributed Data Center NM/NC Network Manager / Controller OSS Operational Support System SM Service Manager SUPA Simplified Use of Policy Abstractions TTM Time to Market Cheng, et al. Expires October 4, 2015 [Page 3] Internet-Draft Use cases for DDC Applications in SUPA April 2015 VAS Value Added Service vDC virtual Data Center VPC Virtual Private 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. In consequence, the operator that rent these resources has to offer SUPA data models for facilitating control of them (for instance, by the DC operator). 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 In quite some cases, DC oprators need to optimize and automate service deployment for them serlfves or for customers. While in some cases, DC tenants also need to perform some optimization, e.g. a vDC tennant may want traffic steering to make full use of links. To solve the above challenges for data center oerators and tenants, SUPA could be applied in the following ways: o SUPA supports an open network architecture: standardizaed data models enable an open architecture and make it possible for unified service / network planning, which can interconnect with third party cloud platform, supporting fast service innovation. o SUPA supports overall DC resource integration: SUPA data models can be used for network resource virtualization; inter-DC resource, virtual DC (vDC) resource, etc, can be integrated and controlled by a centralized functional entity. o SUPA supports automatic E2E service delivery: Network (including virtual network), computing, inter-DC management of storage Cheng, et al. Expires October 4, 2015 [Page 4] Internet-Draft Use cases for DDC Applications in SUPA April 2015 resource, automatic service delivery, automatic VPN connection configurations between DCs, which improves operation efficiency. o SUPA contributes to improve DDC network usage by means of Intelligent scheduling of DDC traffic, improving link usage. o SUPA supports 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. Please refer to [I-D.zhou-supa-framework] and other SUPA related documents for more details of SUPA features. The following sections will illustrate three typical cases in distributed data center which could benefit from SUPA architecture. 6. Scenarios In the following uses, Service Manager (SM) is used for service and policy definition; and Network Manager (Controller) is used for network topology maintenance and mapping data models to detail network configruations, as defined in [I-D.zhou-supa-framework]. 6.1. Scenario:Inter DC Connectivity Cheng, et al. Expires October 4, 2015 [Page 5] Internet-Draft Use cases for DDC Applications in SUPA April 2015 +---------------------------+ | Service Manager | | | | +----------+ +----------+ | | |Service | |Policy | | | |Data Model| |Data Model| | | +----------+ +----------+ | | | +---------------------------+ ^ | | | v +--------------------------+ | Network | | Manager / Controller | +--------------------------+ / \ / \ +---------+ \ /| DC1 |\ \ / +---------+ \ +-----------+ | | d1 \___a1________| DC-A | | | | | | +---------+ +-----------+ d3 | | DC2 |\ | +---------+ \ +-----------+ | | d2 \___a2________| DC-B | | | ____a3________| | \ +---------+ / +-----------+ \| DC3 |/ +---------+ Scenario:Inter DC Connectivity There can be a lot of links between data centers. Configuration of these links is complex. As shown in Figure 1, service data models and policy data models can be defined to automate the configuration procedures. The service data model for connectivity will specify attributes of (virtual) links, e.g. the end points of links, bandwidth, QoS and availability parameters, etc. The policy model can specify some high level requirements to the links, like routing strategy (via and not via) and price/cost strategy. The policy data model can also define the policy rules that drive the security requirements. Cheng, et al. Expires October 4, 2015 [Page 6] Internet-Draft Use cases for DDC Applications in SUPA April 2015 Inter DC connections can be classified into two 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 that connections across multiple administrative domain require extra negotiation and authentication/ authorization, which can be achieved via communications between SMs. Data models for this purpose should also be defined. The links interconnecting two DCs together should guarantee a minimum bandwidth, certain QoS parameters, and provide availability guarantees. As a service policy example in Figure 1, for traffic from DC2 to DC-B, if the load on a link exceeds a threshold (e.g., 90%), some (new) traffic can be redirect to another link. 6.2. Scenario:vDC Connectivity +---------------------------+ | Service Manager | | | | +----------+ +----------+ | | |Service | |Policy | | | |Data Model| |Data Model| | | +----------+ +----------+ | | | +---------------------------+ ^ | | | v +--------------------------+ | Network | | Manager / Controller | +--------------------------+ / | \ / | \ / | \ / +-------------------+ \ / | DC2 | \ / | +---------------+ | \ / | |Tenant1 (vDC) | | \ / | +---------------+ | \ / | | \ / | +---------------+ | \ / | | Tenantn (vDC) | | \ | | +---------------+ | | | +-------------------+ | Cheng, et al. Expires October 4, 2015 [Page 7] Internet-Draft Use cases for DDC Applications in SUPA April 2015 | |vDC link | | +-------------+ | | | | | | /| Cloud |\ | | / +-------------+ \ | | vDC link / \vDC link| | / \ | +-------------------+ +-------------------+ | DC1 | | DC3 | | +---------------+ | | +---------------+ | | | Tenant1 (vDC) | | | | Tenant1 (vDC) | | | +---------------+ | | +---------------+ | | | | | | +---------------+ | | +---------------+ | | | Tenantk (VDC) | | | | Tenantn (vDC) | | | +---------------+ | | +---------------+ | +-------------------+ +-------------------+ Scenario:vDC Connectivity A DC tenant may have resources, e.g. network, computing, storage, etc, in multiple physical DCs. DC operators will provide internal network connectivity for these distributed resources, and make it look like one seamless entity, which can be called as virtual DC (vDC). The internal links for vDC can be implemented via tunneling overlay technologies, e.g. VPN or VxLAN, etc. The tunnels need to be dynamically established, managed and released. As show in Figure 2, service data model and policy data model can be defined to automate the links configuration for vDCs. A policy model should specify the attributes of the tunnels, e.g., bandwidth, QoS and availability parameters, the interaction with policy systems that dynamically scale the DC resources assigned to a tenant, and the policy rules that drive the prioritization of resource assignments. The networking resources assigned to a tenant should scale proportionally to the compute resources assigned to a tenant. The traffic should be prioritized to resources owned by tenants that offer interactive services according to the time zone the DC is located in. Cheng, et al. Expires October 4, 2015 [Page 8] Internet-Draft Use cases for DDC Applications in SUPA April 2015 6.3. Scenario:Dynamic Link Configuration for DC Static and over provisioning for DC links is not always a good solution. Sometimes dynamic configuration is necessary. +---------------------------+ | Service Manager | | | | +----------+ +----------+ | | |Service | |Policy | | | |Data Model| |Data Model| | | +----------+ +----------+ | | | +---------------------------+ ^ | | | v +--------------------------+ | Network | | Manager / Controller |______________ +--------------------------+ \ / \ \ / \ \ / \ | +--------------+ +-------------------+ | | | | | | | | | DC2 | | |--------------- | | | | DC1 | +-------------------+ | | | | | | \ | | | \ +-------------------+ | | | \ | | / | | \__________| DC2 |/ +--------------| | | +-------------------+ Scenario:Dynamic Link Configuration for DC 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 Cheng, et al. Expires October 4, 2015 [Page 9] Internet-Draft Use cases for DDC Applications in SUPA April 2015 have large bandwidth but last for a limited time period. An alternative is to create short-term dedicated links for backups and migrations. As shown in figure 3, data models can help to automate these kind of configurations. In the data models, the attributes of links (bandwidth, QoS and availability parameters) should be specified. The policy concerning strict and soft bounds on the lifetime of such links, and the policy concerning the scheduling of dedicated links (e.g., based on the current load) and the services using the dedicated links can also be specified. When the traffic volume between DCs exceeds a certain threshold, the policy-driven service manager requests that traffic schedules may be adjusted within bounds in order to balance load on the links (e.g., delay backups and migrations until the network has the necessary capacity). 6.4. Scenario:DC Connectivity for Virtual Private Clouds (VPC) Cheng, et al. Expires October 4, 2015 [Page 10] Internet-Draft Use cases for DDC Applications in SUPA April 2015 +---------------------------+ | Service Manager | | | | +----------+ +----------+ | | |Service | |Policy | | | |Data Model| |Data Model| | | +----------+ +----------+ | | | +---------------------------+ ^ | | | v +--------------------------+ | Network | | Manager / Controller |______________ +--------------------------+ \ / \ \ / \ \ / \ | +-------------------+ +-------------------+ | | Cloud for VPCs | | | | | +---------------+ | VPC link | DC1 (Database) | | | | VPC1 |-----------------| | | | +---------------+ \ +-------------------+ | | +---------------+ |\ | | | VPC2 | | \ | | +---------------+ | \ +-------------------+ | | +---------------+ | \ VPC link | | / | | ...... | | \__________| DC2 (Storage) |/ | +---------------+ | | | +-------------------+ +-------------------+ Scenario: 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 Cheng, et al. Expires October 4, 2015 [Page 11] Internet-Draft Use cases for DDC Applications in SUPA April 2015 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 DCs, or even provided by different vendors. VPNs are configured for the VPCs to provide connection to the internal services, and to create and manage VPNs to internal services. The access of virtual PCs to data resources is often controlled by underlying projects. As shown in figure 4, service data models and policy data models can be defined to automate the configurations of links between VPC and DC where service is located. The data models should specify the policy controlling authentication and authorization concerning access to data residing in internal services. During the duration of project X, ensure that the virtual PCs used by the project members have secure access to the data resource Y. 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, Bob Natale. 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. Cheng, et al. Expires October 4, 2015 [Page 12] Internet-Draft Use cases for DDC Applications in SUPA April 2015 [I-D.zaalouk-supa-configuration-model] Zaalouk, A., Pentikousis, K., and W. Will, "YANG Data 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 Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com Cheng, et al. Expires October 4, 2015 [Page 13]