One document matched: draft-cheng-supa-ddc-use-cases-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-cheng-supa-ddc-use-cases-00"
ipr="trust200902">
<front>
<title abbrev="Use cases for DDC Applications in SUPA">
Use Cases for Distributed Data Center Applicatinos in SUPA
</title>
<author initials="Y." surname="Cheng" fullname="Ying Cheng">
<organization>China Unicom</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country>P.R. China</country>
</postal>
<email>chengying10@chinaunicom.cn</email>
</address>
</author>
<author initials="C." surname="Zhou" fullname="Cathy Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<author initials="G." surname="Karagiannis" fullname="Georgios Karagiannis">
<organization>University of Twente</organization>
<address>
<postal>
<street> </street>
<city> </city>
<code> </code>
<country> </country>
</postal>
<email>g.karagiannis@utwente.nl</email>
</address>
</author>
<author initials="JF." surname="Tremblay" fullname="JF Tremblay">
<organization>Viagenie</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
</postal>
<email>jean-francois.tremblay@viagenie.ca</email>
</address>
</author>
<date year="2014" />
<abstract>
<t>This document provides several distributed data center (ddc) use cases and explains how an operator could use SUPA (Shared Unified Policy Automation) to provide these applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The SUPA (Shared Unified Policy Automation) work aims at providing the network management application-based policy protocol(s), mechanisms and models required by network management applications to easily, accurately, and efficiently select and use the available communication network capabilities through the use of network management policies. A Network Management Application is used by an a communications
service provider and/or operator to monitor, control, analyze and
manage a communication network. An example of a Network Management
Application is a set of actions used by an Operational Support System
(OSS) entity to perform network configuration. Several SUPA use cases have been introduced in the problem statement document. This document reviews various use cases for Distributed Data Center (DDC) applications.</t>
<t>Take a large-scale Internet Data Center (IDC) operator as an example, it provides server hosting, bandwidth, value-added services to enterprises and ISPs, and has more than 10 data centers using over one Tbps of bandwidth in a
capital city. In this IDC network, traffic at each site is routed via
configuring policy routes and adjusting routes prioritization to
choose an outgoing link. This type of static provisioning comes with high costs and poor operability. Furthermore,
the link bandwidth resources in the data centers are not efficiently
utilized. </t>
<t>Services usually do not have consistent bandwidth requirements at
all times of the day, e.g. a video service provider usually requires
less bandwidth during business hours and more during evenings. Some applications have relative high QoS requirements that may change over time., For example provisioning bandwidth and QoS for all clients of an Instant Messaging (IM) app
is not reasonable and not a cost-effective solution. The operator would like to be able to optimize traffic routes
dynamically so as to have the ability to load balance between data
centers and links, and direct customer traffic via policies (e.g.,
models, software programs routines) based on customer grade and QoS requirements.It will also be useful to monitor the
real-time traffic flow and have a visualized report.
</t>
<t> Traffic engineering applications can provide dynamic traffic
adjustment demands to the network based on link statuss reported by
the network. </t>
<t>SUPA will define network management application-based policy
protocol(s), mechanisms and models required to map application's
demands to network management policies en procedures (e.g. traffic
redirection based on customer's grade and link status), which can be
directly enforced by a network management system on network devices,
to meet the operator's demands.
</t>
<t>This document illustrates several distributed datacenter (DDC) applications and explains how an operator could use SUPA to provide these applications. </t>
</section>
<section title="Terminology">
<t> The terminology used in the SUPA problem statement draft [ID.karagiannis-aponf-problem-statement-00] applies
also to this draft.
</t>
</section>
<section title="Challenges Faced by Data Center ISPs">
<t>There are many challenges in traditional data centers: 1) Framework and bandwidth is mainly leased, depending on manual planning and design, which leads to low resource usage and high cost; 2)Service expansion is limited in single physical DC. Each DC resource is isolated, so service and resource can only be deployed in one single DC; 3)VAS (Value Added Service) is provisioned via static configuration, which brings complex draining, long service TTM time and
bad flexibility. This could not meet the requirements of complex use cases, e.g., too many VAS devices, big difference of service requirements. </t>
</section>
<section title="SUPA Benefits">
<t>To solve the above challenges for data center ISPs, SUPA could be applied in the following ways:</t>
<t><list style="symbols">
<t>SUPA provides an open network architecture:Open architecture, fast interconnection with third party cloud platform, support fast service innovation, unified architecture and unified planning;</t>
<t>SUPA provides overall DC resource integration: Network resource virtualization, inter-DC resource integration, vDC service provisioning, unified inter-DC service, which reduces opex;</t>
<t>SUPA provides automatic E2E service delivery: Network (including virtual network), computing, inter-DC management of stored resource, automatic service delivery, which improves operation efficiency;</t>
<t>SUPA improves DDC network usage:Intelligent scheduling of DDC traffic, improving link usage efficiently.</t>
<t>SUPA provides VAS service on-demand provisioning automatically: Create or delete VAS nodes on-demand, based on various service requirements;
ABPD indicates network forwarding policy based on the VAS routing, to achieve automatic draining and automatic configuration of VAS device policy.</t>
</list></t>
<t>The following sections will illustrate four typical cases in distributed data center which could benefit from SUPA architecture. The policies transmitted from Network Management Applications to the DCs will be represented by a network configuration model described in [ID.adel-supa-configuration-model].</t>
</section>
<section title="Bandwidth Usage Optimization betwen DCs">
<t>A large-scale data center may have more than one hundred links. The network between data centers is often leased and the applied bandwidth is very expensive. if the traditional shortest path algorithm is used to calculate a path based on static cost, then the path calculation cannot be dynamically adjusted based on real-time bandwidth usage. This will result in bandwidth waste. </t>
<t>Figure 1 shows how to improve the bandwidth usage efficiency beween data centers. There are two paths from DC A to DC B, for example, A-->B (path 1) and A-->C-->B (path 2). When the bandwidth between A and B is not sufficient, A will automatically transmit the traffic via C. The network management applications will configure a threshold T (e.g., 80%) for the path bandwidth usage ratio and send it to A. When an application request is received, A will detect the bandwidth usage of both paths. When the bandwidth usage ratio of path 1 (T1) has exceeded value T (e.g., 90%), while the bandwidth usage ratio of path 2 (T2) is much less than T (e.g., 10%), it will transmit the traffic to B via C, even though P1 is the shortest path between A and B.</t>
<t>In this case, the available bandwidth between A and B will be
used efficiently, and risks of congestion between the datacenters will be
avoided.</t>
<figure title="Figure 1: Bandwidth usage optimization for DC Interconnection">
<artwork><![CDATA[
+-------------------+
|Network Management |
| |
|Applications |
+--------+----------+
| +----------+
Policy | | |
(Threshold,T) | -> B |
| / | |
| T1 / +----^-----+
| / |
+---v-----+ / |
| |/ |
| A + | T2
| |\ |
+---------+ \ |
\ |
T2 \ +----+-----+
\ | |
-> C |
| |
+----------+
]]></artwork>
</figure>
</section>
<section title="Server Synchronization between Datacenters">
<t>A Data center involves many systems and the server
synchronization is specifically important for DCs. Once there is
error in server synchronization, the system will not run regularly,
which brings mistakes and failures. However, the server
synchronization is not easy to be realized during the daytime when
the Data Center servers are fully loaded services. Instead, many
operators choose to make the synchronization in the evening at some
regular intervals.</t>
<t>Figure 2 shows how server synchronization between datacenters can be
realized. Two servers separately in DC A and DC B are required to synchronize daily. The Network Management Applications, as defined in the SUPA architecture, are configured with several Policies, e.g., syn time (2am to 3am everyday for instance) on when to synchronize the servers, BW (a required bandwidth to be maintained between the period), and the path information (which path between the two DCs costs lower). The Network Management Applications will send these policy information to both DC A and DC B. In this case, the two servers synchronize automatically everyday from 2am to 3am, which will guarantee the normal operation of the servers. </t>
<figure title="Figure 2: Server Synchronization between DCs">
<artwork><![CDATA[
+--------------------+
|Network Management |
| |
|Applications |
| |
+---------+----------+
/ \
/ \
/ \
/ Policy \
/ (Syn Time,BW, \
/ Path) \
| |
+-----v----+ +---v------+
| | | |
| A +--------------+ B |
| | | |
+----------+ +----------+
]]></artwork>
</figure>
</section>
<section title="Low Delay Link Selection between DCs">
<t>Traditional routing algorithms do not consider real-time link conditions, some requirements of specific applications cannot be met timely, e.g., delay is a key requirement for the audio services (Skype for example). How to select a better link based on the delay of each link becomes important for the application.</t>
<t>Figure 3 shows an example of link selection between datacenters according to the delay of each link. A value "d" is configured in the Network Management Applications for the specific applications, e.g., less than 100 ms. The value "d" will be sent to the ingress data center A for the A to detect the delays in both links between A and B. A will transmit the traffic via the link 1 to B if d1 is less than d and d2 is larger than d. In this case, the service quality and QoE user experience will be enhanced.</t>
<figure title="Figure 3: Low Delay Link Selection between Datacenters ">
<artwork><![CDATA[
+--------------------+
|Network Management |
| |
|Applications |
| |
+--------+-----------+
|
|
| Policy (delay value "d")
|
|
| d2
+----v----+ ------------ +----------+
| |/ \ | |
| A |-----------------> B |
| | d1 | |
+---------+ +----------+
]]></artwork>
</figure>
</section>
<section title="On-demand Path Creation between Datacenters ">
<t>Figure 4 illustrates a problem related to bandwidth fragmentation. From DC A to DC B, two paths (A-->B, A-->C-->B) can be reached. From A to B, only 2Gbps bandwidth is left and 8Gbps is used, and from A to B via C, the link capacity is 2Gbps. So there is no bandwidth to transmit the traffic when there is a 4Gbps requirement from A to B, which causes that the bandwidth is not effectively used.</t>
<figure title="Figure 4: Bandwidth Fragmentation Problem">
<artwork><![CDATA[
There is no
bandwidth to
+----------+ transmit 4G +----------+
| | traffic | |
| A +------------------+ B |
| |10G link (8G used,| |
+----------+ 2G left) +----------+
\ /
\ /
\2G 2G/
\ /
\ /
+----------+
| |
| C |
| |
+----------+
]]></artwork>
</figure>
<t>Figure 5 provides a method to create on-demand path and bundle the path capabilities between datacenters. The bandwidth bundle capability is configured and sent to the DC A by the network management applications. When the bandwidth is not sufficient to meet the requirements for a specific application, A could bundle the bandwidth in the two links. The network capability, e.g., bandwidth bundle capability, is firstly negotiated between network management applications and the network element via other methods, which are out of the scope of this document. </t>
<figure title="Figure 5: On-demand Path Creation between DCs">
<artwork><![CDATA[
+--------------------+
|Network Management |
| |
|Applications |
| |
+---------+----------+
|
|Policy (Bundle two paths)
|
|
+-----v----+ +----------+
| | 2G | |
| A +--------------> B |
| | | |
+----------+ +----^-----+
\ /
\ /
\ 2G 2G /
\ /
\ /
+----------+
| |
| C |
| |
+----------+
]]></artwork>
</figure>
</section>
<section title="Security Considerations">
<t>Security is a key aspect of any protocol that allows state
installation and extracting of detailed configuration states. More
investigation remains to fully define the security requirements, such
as authorization and authentication levels.</t>
</section>
<section title="IANA Considerations">
<t>Not applicable.</t>
</section>
<section title="Acknowledgements">
<t>N/A.</t>
</section>
</middle>
<back>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:08:18 |