Network Working Group C. Xie Internet-Draft Q. Sun China Telecom Intended status: Informational May 07, 2015 Expires: November 07, 2015 Inter DC Traffic Optimization Using SUPA draft-xie-inter-dc-traffic-optimization-01 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 04, 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 - PORT BASED TRAFFIC OPTIMIZATION ................... 6 5. SECURITY CONSIDERATIONS ......................................... 8 6. IANA CONSIDERATIONS ............................................. 8 7. ACKNOWLEDGEMENTS ................................................ 8 8. NORMATIVE REFERENCES ............................................ 8 9. INFORMATIVE REFERENCES .......................................... 8 AUTHORS' ADDRESSES .................................................. 9 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 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. Example of SUPA data models can be found in [I-D.zaalouk-supa- vpn-service-management-model]. Xie, et al Expires November 07, 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 November 07, 2015 Page 3 Internet-Draft Inter DC Traffic Optimization January 2015 +---------------------------+ | Service Manager | | | | +----------+ +----------+ | | |Service | |Policy | | | |Data Model| |Data Model| | | +----------+ +----------+ | | | +---------------------------+ ^ | v +--------------------------+ | Network | | Manager / Controller | +--------------------------+ / ^ \ \ / | \ \ / | \ \ / v \ \ / +-----------+ \ \ / | DC1 | \ \ / +-----------+ \ \ / / \ \ \ | L1/ \L2 | \ | / \ | \ +------------+ L3 +-------------+ | | DC2 |-----------| DCx | | +------------+ +-------------+ | \ \ / | \ \ / | \L4 \L5 /L6 | \ \ / | \ +-----------+ | \------| DC3 |-------------+ +-----------+ Figure 1 Link Based Traffic Optimization To support this function, the dynamic traffic steering/load balance system needs to know the network connections of the DC network, and it can monitor traffic load on each of the links. 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 traffic steering policy and service can be abstracted for an automated management application, which will greatly improve the efficiency of the network. Xie, et al Expires November 07, 2015 Page 4 Internet-Draft Inter DC Traffic Optimization January 2015 SUPA service data model can be used to describe the links between DCs, including of the link, e.g. bandwidth, QoS, etc. A policy data model can be used to describe the requirements of traffic redirecting, 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 data model. With the use of data models, application development work is greatly simplified. As shown in Figure 1, for traffic from DC2 to DCx, if the load on link L3 exceeds a threshold (e.g., 90%), some (new) traffic can be redirect through link L5 + L6, via a third party DC. While for some other tenants, they would like to make the best use of bandwidth and QoS is not a key concern, overload on links and packet drop are acceptable. In such a case, load balancing through traffic steering when load exceed a threshold does not work very well because it cannot maximize the load on links. In the case, for example, traffic from 10.1.0.0/16 and 10.2.0.0/16 should go through link A, and traffic from 10.3.0.0/16 should go through link B, the bandwidth and load link A and B will not be consider. When defining the service data model and/or policy data model, load attribute will not be specified. A service data model for the above use case may look like: module: ietf-supa-ddc +--rw ddc-services +--rw ...... other possible attributes +--rw ddc-service* [name] | +--rw name string | +--rw connection-type? enumeration | +--rw connection-name string | +--rw bandwidth uint32 | +--rw latency uint32 +--rw ...... other possible attributes Figure 2 Simple Yang Tree of Service Data Model The connection-type can be native physical interface, L2VPN, L3VPN, etc. The connection-name can be the VPN instance ID, or the port ID, e.g. /frame/slot/port-num. Xie, et al Expires November 07, 2015 Page 5 Internet-Draft Inter DC Traffic Optimization January 2015 A policy data model can be used automate the traffic redirecting, and it may look like: module: ietf-supa-policy +--rw supa-policy +--rw ...... other possible attributes +--rw supa-policy-atomic | +--rw supa-ECA-policy-rule | +--rw policy-rule-name? string | +--rw has-policy-events? boolean | +--rw has-policy-conditions? boolean | +--rw has-policy-actions? boolean +--rw ...... other possible attributes Figure 3 Simple Yang Tree of Policy Data Model In the policy data model for the above case, "event" is the bandwidth of a link, "condition" is "load >= 80%", "action" is "redirect some traffic to another link". 4.2. Scenario - Port Based Traffic Optimization Xie, et al Expires November 07, 2015 Page 6 Internet-Draft Inter DC Traffic Optimization January 2015 +---------------------------+ | Service Manager | | | | +----------+ +----------+ | | |Service | |Policy | | | |Data Model| |Data Model| | | +----------+ +----------+ | | | +---------------------------+ ^ | v +--------------------------+ | Network | | Manager / Controller | +--------------------------+ / ^ \ \ / | \ ---------------+ / | ----------+ | / | | | / | __+--------+ | / v / | | | / +--------------+P3 __| DC2 | | +---------+P1 | |/ / | | | | |-----| IP Network | P4 +--------+ | | DC1 |P2 | |/ | | |-----| (Internet) |\ | +---------+ | | \ +--------+ | | |\ \__| | | +--------------+ \ | DCx |---+ \__| | +--------+ Figure 4 Port Based Traffic Optimization Sometimes DCs are connected to large scale IP network, via multiple ports. 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 (P1+P3) cannot be guaranteed, as shown in Figure 4. 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 attributes (e.g., bandwidth, QoS, etc) of links cannot be guaranteed. The attributes of port include less parameter than that of link. DC operators have no (full) control over the network, and then traffic optimization can only be configured locally rather than over the whole network. Xie, et al Expires November 07, 2015 Page 7 Internet-Draft Inter DC Traffic Optimization January 2015 Dynamic traffic steering cannot be based on links any more, but have to be based on the load of the DC gateway ports. Compared to the scenario in section 4.1, ports rather than links should be modeled in SUPA data model; and also SUPA policy data model should be based on network ports. Take a service policy example, as shown in Figure 2, if the load on port1 exceed a threshold (e.g., 90%), some (new) traffic will be redirected to port2. In service data model for this case, the connection-type as shown in Figure 2 should be "native physical port", and the connection- name can be "/frame0/slot1/port2". 5. Security Considerations If the Data Center and network belong to different parties, which means if the Data Center operator needs to send network configuration requirement via data models to network operator. In this case, authentication and authorization must be required to prevent potential attacks and abuse use. 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., Qiong, Q., Contreras, L., Yegani, P., and J. Bi, "Problem Statement for Simplified Use of Policy Abstractions (SUPA)", draft-karagiannis-supa-problem- statement-06 (work in progress), March 2015. Xie, et al Expires November 07, 2015 Page 8 Internet-Draft Inter DC Traffic Optimization January 2015 [I-D.zaalouk-supa-vpn-service-management-model] Zhang, D., Zaalouk, A., Pentikousis, K., and Y. Cheng, "VPN Service Management YANG Data Model", draft-zaalouk-supa-vpn-service-management-model-03 (work in progress), April 2015. [I-D.zhou-supa-framework] Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The Framework of Simplified Use of Policy Abstractions (SUPA)", draft-zhou-supa-framework-01 (work in progress), February 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 November 07, 2015 Page 9