Internet DRAFT - draft-xie-supa-inter-dc-traffic-optimization

draft-xie-supa-inter-dc-traffic-optimization



Network Working Group                                            C. Xie
Internet-Draft                                                   Q. Sun
                                                          China Telecom
Intended status: Informational                             May 25, 2015
Expires: November 25, 2015

             Inter DC Traffic Optimization Using SUPA
          draft-xie-supa-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 November 25, 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