Internet DRAFT - draft-xie-inter-dc-traffic-optimization
draft-xie-inter-dc-traffic-optimization
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
