Network Working Group C. Xie Internet-Draft Q. Sun China Telecom Intended status: Informational Expires: September 05, 2015 March 05, 2015 Inter DC Traffic Optimization Using SUPA draft-xie-inter-dc-traffic-optimization-00 Abstract Data Centers may have many links between each other. Bandwidth over- provisioning sometimes is not a good solution to accommodate the traffic between DCs, especially for peak traffic. This draft analyze the use case of inter DC traffic optimization, and the applicability of SUPA for this case. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 27, 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. Xie, et al Expires September 05, 2015 Page 1 Internet-Draft Inter DC Traffic Optimization January 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. 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 RFC 2119 [RFC2119]. Table of Content 1. INTRODUCTION ............................................ 2 2. REQUIREMENTS LANGUAGE ................................... 3 3. TERMINOLOGY ............................................. 3 4. USE CASE ................................................ 3 4.1. SCENARIO - LINK BASED TRAFFIC OPTIMIZATION ........... 3 4.2. SCENARIO - INTERFACE BASED TRAFFIC OPTIMIZATION ...... 4 4.3. FLOW CLASSIFICATION FOR TRAFFIC STEERING ............. 5 5. SECURITY CONSIDERATIONS ................................. 6 6. IANA CONSIDERATIONS ..................................... 6 7. ACKNOWLEDGEMENTS ........................................ 6 8. NORMATIVE REFERENCES .................................... 6 9. INFORMATIVE REFERENCES .................................. 6 AUTHORS' ADDRESSES .......................................... 7 1. Introduction Simplified Use of Policy Abstractions (SUPA) [I-D.zhou-supa- framework] aims to provide a set of data models to simplify and automate network service provisioning. The SUPA topology data model describes the physical and virtual network topology including network device capabilities. The SUPA service data model defines a network service and the required network resources for this service. The SUPA policy data model help to manage the network service and map services dynamically to the network topology and network resources. Xie, et al Expires July 5, 2015 Page 2 Internet-Draft Inter DC Traffic Optimization January 2015 SUAP data models provide a simplified view of policy, service and network resource, which will make it easier to develop, deploy and manage a new network service. The standardized data models also make it possible for third party platform to integrate SUPA work. Large DCs may have many links between each other. Sometimes bandwidth over provisioning is not a reasonable solution to accommodate the traffic between DCs. Traffic steering is very necessary, which usually makes use of hash based load balancing or statistic based load balancing. Traffic steering can be dynamic and over interfaces or links. This memo will analyze the scenarios of inter DC traffic optimization use case and illustrate how SUPA help to achieve this. 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 DC Data Center SUPA Simplified Use of Policy Abstractions 4. Use Case 4.1. Scenario - Link based traffic optimization Sometimes DCs are inter-connected by links, which creates a full- mesh or partial-mesh network, as shown in Figure 1. The link can be either physical link or virtual link, for example a VPN. There can be multiple links between two DCs. Data traffic from one DC to another, for example from DC2 to DCx, can go through the direct link L6 between them. This is the traditional case, and in order to accommodate peek traffic, over provisioning is necessary. But if intelligent traffic steering is available, the traffic can also go through a third DC (e.g. DC3), via link L4 and L5. The traffic steering system will monitor the traffic on the links, and once it finds out the load on a link is higher than a threshold (e.g. 90%), it can direct some traffic to another link with lower load. Xie, et al Expires July 5, 2015 Page 3 Internet-Draft Inter DC Traffic Optimization January 2015 +-----------+ | DC1 | +-----------+ / \ L1/ \L2 / \ / \ +------------+ L6 +-------------+ | DC2 |-----------| DCx | +------------+ +-------------+ \ \ / \ \ / \L3 \L4 /L5 \ \ / \ +-----------+ \_____| DC3 | +-----------+ Figure 1 Link Based Traffic Optimization To support this function, the traffic steering system needs to know the network topology of the DC network, and it can monitor traffic load on each of the links in this topology. The DCs and/or the DC gateways need to be able to perform traffic classification and policy based routing. The above functions are not likely going to work well via manual configuration, which is slow, time consuming and error prone. If the network topology, traffic steering policy and service can be abstracted for an automated management application, which will greatly improve the efficiency of the network. SUPA topology data model can be used to describe the links between DCs, including attributes of the link, e.g. capacity, QoS, etc. A policy model can be used to describe the requirements of link selection, e.g. when load on a link exceed a threshold, an extra link should be used. Operators can make use of automated applications based on SUPA topology data model, policy data model and service specific data model. With the use of data models, application development work is greatly simplified. 4.2. Scenario - Interface Based Traffic Optimization Xie, et al Expires July 5, 2015 Page 4 Internet-Draft Inter DC Traffic Optimization January 2015 __+--------+ L3/ | | +--------------+ / __| DC2 | +---------+ L1 | |/ / | | | |-----| IP Network | /L4 +--------+ | DC1 | L2 | |/ | |-----| (Internet) |\ +---------+ | | \ +--------+ | |\ \__| | +--------------+ \ | DCx | \__| | +--------+ Figure 2 Interface Based Traffic Optimization Sometimes DCs are connected to large scale IP network, via multiple interfaces. In this case the link in the IP network is not manageable; the DC operator has no control over the link in the IP network, which means the DC operator cannot guarantee the bandwidth and other attributes of a link in IP network. For example, the bandwidth of the link from DC1 to DC2 (L1+L3) cannot be guaranteed, as shown in Figure 2. One reason of this is the IP network is very large. Sometimes the link between DCs needs to traverse many operators' network, which makes it very difficult to sign a SLA with network operator(s). The link bandwidth and QoS cannot be guaranteed. DC operators have no (full) control over the network, and then traffic optimization can only be configured locally rather than over the whole network. Traffic steering cannot be based on links any more, but have to be based on the load of the DC gateway interfaces. Compared to the scenario in section 4.1, interfaces rather than links should be modeled in SUPA data model; and also SUPA policy data model should be based on network interfaces. 4.3. Flow Classification for Traffic Steering Flow classification is necessary for some services, e.g. load balancing, policy routing, etc. Flow classification can be based on attributes of network packets, e.g. 5 tuples, VLAN, etc. Load balancing can use a hash algorithm to distribute network packets to a set of network interfaces or links in a (nearly) even manner; or using a statistic based method, for example, if the traffic load on a link is too high, then traffic with a specific IP address / prefix can be directed to another network interface. Xie, et al Expires July 5, 2015 Page 5 Internet-Draft Inter DC Traffic Optimization January 2015 Another possible flow classification method is based on tenants. DC operators do not have to acquire the same high quality links for all the users. DC tenants can be classified into several categories, for example bronze tenant, silver tenant and gold tenant, etc, each with different priority level. High priority tenants' traffic can be carried in a link with low traffic load and good QoS attributes, while common tenants' traffic can be carried in a common link. A tenant can be identified by IP address/prefix, VLAN/VXLAN, MAC address, etc, or any combination of these attributes. 5. Security Considerations This memo does 6. IANA Considerations No IANA considerations. 7. Acknowledgements N/A 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9. 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 Model for Configuration of Shared Unified Policy Automation (SUPA)", draft-zaalouk-supa-configuration- model-01 (work in progress), October 2014. Xie, et al Expires July 5, 2015 Page 6 Internet-Draft Inter DC Traffic Optimization January 2015 [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 Chongfeng Xie China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: xiechf@ctbri.com.cn Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Xie, et al Expires July 5, 2015 Page 7