Inter DC Traffic Optimization Using SUPA
draft-xie-inter-dc-traffic-optimization-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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 | Chongfeng Xie , Qiong Sun | ||
| Last updated | 2015-03-07 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-xie-inter-dc-traffic-optimization-00
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