One document matched: draft-dhodyzhang-actn-use-case-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="info" docName="draft-dhodyzhang-actn-use-case-00" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="ACTN-USECASE">Use Cases for Abstraction and Control of Transport Networks (ACTN)</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author fullname="Xian Zhang" initials="X." surname="Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District
</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P.R.China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</author>
<author initials="O" fullname="Oscar Gonzalez de Dios" surname="Gonzalez de Dios">
<organization>Telefonica</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>SPAIN</country>
</postal>
<email>ogondio@tid.es</email>
</address>
</author>
<date month="February" year="2014" />
<area>Routing</area>
<workgroup>ACTN BOF</workgroup>
<abstract>
<t>This document describes the Abstraction and Control of
Transport Networks (ACTN) use cases that may be potentially
deployed in various transport networks and apply to different
applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The transport networks are in an unique position to embrace the
concepts of software defined networking (SDN) because of the existing
separation in control and forwarding plane via GMPLS/ASON. The path
computation element (PCE) <xref target="RFC4655"/> and its
stateful extension <xref target="STATEFUL-PCE"/> can further provide
a central control over the resources. Abstraction and Control
of Transport Network (ACTN) is focused on building over
the existing blocks by adding programmability, access and control over
abstract virtual topologies. <xref target="ACTN-PROBLEM"/> and
<xref target="ACTN-FWK"/> provides detailed
information regarding this work. </t>
<t>This document explores the use cases of ACTN to help provide
programmable network services like access to abstract topology and
control over the resources. They are divided into - </t>
<t>
<list style="symbols">
<t>Data Center Interconnect (DCI): helps organization meet business
continuity and improve productivity, transparently connect the
geographically dispersed datacenters interconnected via transport
network enabling data replication, server clustering, and workload
mobility etc.</t>
<t>Packet Optical Integration (POI): Increasingly there is a need
for packet and optical transport networks to work together to provide
accelerated services. Transport networks can provide useful information
to the packet network allowing it to make intelligent decisions and
control its allocated resources. It is preferable to coordinate network resource control and
utilization rather than controlling and optimizing resources at each
network layer (packet and optical transport network) independently.
This facilitates network efficiency and network
automation.</t>
<t>Service Provider: Service providers are the
providers of virtual network services to their customers. Service providers
may or may not own physical network resources. </t>
<t>
<list style="symbols">
<t>Carriers-of-Carrier: A two-tiered relationship between a provider carrier
and a customer carrier where the provider carrier may offer abstract
information and partial control.</t>
<t>Virtual Network Operator: Virtual Network Operator are categorized as
virtual because they provide network services to customers without owning
the underlying network.</t>
</list>
</t>
</list>
</t>
<section title="Requirements Language" toc="default">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>Refer <xref target="ACTN-FWK"/> for PNC, VNC terminology.</t>
<t>The following terminology is used in this document.</t>
<t>
<list style="hanging">
<t hangText="ACTN:">Abstraction and Control of Transport Networks.</t>
<t hangText="DCI:">Data Center Interconnect.</t>
<t hangText="PCE:">Path Computation Element. An entity (component,
application, or network node) that is capable of computing a network
path or route based on a network graph and applying computational
constraints.</t>
<t hangText="POI:">Packet and Optical Integration</t>
<t hangText="VNO:">Virtual Network Operator.</t>
</list>
</t>
</section>
<section title="Data Center Interconnect" toc="default">
<t>Data center based applications can provide a wide variety of services
such as video gaming, cloud computing, and grid applications. High-bandwidth
video applications are also emerging, such as remote
medical surgery, live concerts, and sporting events.</t>
<t>The rapid growth of Internet and cloud computing
applications has resulted in an ever increasing datacenter network bandwidth
requirements. Datacenter
operators are faced with the challenge of meeting exponentially
increasing demands for network bandwidth without exorbitant
increases in infrastructure cost. The expansion of cloud computing,
content delivery, and application agility are driving the need for
data center interconnection (DCI). </t>
<t>In order to support new and emerging cloud-based applications, such
as real-time data backup, virtual machine migration, server
clustering or load reorganization, the dynamic provisioning and
allocation of IT resources and the interconnection of multiple,
remote Data Centers (DC) is a growing requirement. These operations
require traffic being delivered between data
centers, and, typically, the connections providing such inter-DC
connectivity are provisioned using static circuits or dedicated
leased lines, leading to an inefficiency in terms of resource
utilization. Moreover, a basic requirement is that such a group of
remote DCs an be operated logically as one.</t>
<t>A flexible data center interconnects is based on simplifying the
architecture and using elegant programmable and orchestration capabilities.
At the
same time, it should enables the dynamic control of services and service
attributes such as allocation of bandwidth on demand or tuning of class of
service all in a multi-vendor environment.</t>
<t>
The increase in traffic volumes for the transport network and volatility
also results in significantly increased operational complexity, which
impacts a service provider's ability to deliver profitable services and
create competitive differentiation. A much more agile, scalable and resilient
framework is required to meet the dynamic traffic demands of cloud computing.
Transport networks lack the end-to-end flexibility and
efficiency required to meet the needs of new and demanding needs of
data center interconnect. To help operators address the end-to-end
service requirements an agile data center connectivity is required
with the understanding of the data center applications.
</t>
<t>
Thus a need to provide network abstraction has emerged as a key
requirement for Data Center (DC) operators; this implies in effect the
virtualization of network interconnecting the DCs, so that the network
is "sliced" and DC operator given a partial view of the topology.
The Data Center Controller (customer controller) is empowered
with various control facilitates (to create, modify, and delete
their slice of virtual network services), allowing DC to introduction
new services and respond to the changing traffic and SLA demands. </t>
<t>Incase of multiple independent network providers interconnecting
geographically dispersed Data Centers, a service provider
that abstracts the transport network across domains on behalf of the
Data Center Controller.</t>
<figure title="Geographically Dispersed DC" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG1">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
+----------------------+
| Data Center |
| Controller |
+----------------------+
|
+----------------------+
| VNC |
| |
+----------------------+
/ \
+--------------+ +--------------+
| PNC1 | | PNC2 |
+----------+ |--------------| |--------------| +----------+
| | | | | | | |
| DC1 | | Network | | Network | | DC2 |
| | | provider 1 | | provider 2 | | |
+----------+ | | | | +----------+
+--------------+ +--------------+
]]></artwork>
</figure>
<section title="Cross Stratum Optimization" toc="default">
<t>Currently application decisions are made with very little or no
information concerning the underlying network used to deliver those
services. Hence such decisions may be sub-optimal from both
application and network resource utilization and quality of service
objectives.</t>
<t>The decisions by the DC or customer controller are typically
made by them with very little
or no information concerning the underlying network. Hence, such
decisions may be sub-optimal from application and network resource
utilization and quality of service objectives.
ross-stratum optimization is the process of optimizing both the
application experience and the network utilization by coordinating
decisions in the application stratum and the network stratum. An abstract
topological view of the network can go a long way in
cross optimization of application and network resources. Further
flexible dynamic control over the transport network resources leads to
adaptability to handle various traffic loads, data center and network
events. </t>
</section>
</section>
<section title="Packet Optical Integration" toc="default">
<t>Connections (or tunnels) formed across the optical transport network,
can be used as virtual TE links in the packet network. The
relationship is reduced to determining which tunnels to set
up, how to trigger them, how to route them, and what capacity to
assign them. As the demands in the packet network vary, these
tunnels may need to be modified.</t>
<t>An entity in packet network - (maybe a Path Computation Element (PCE),
Virtual Network Topology Manager (VNTM) <xref target="RFC5623"/>, Controller
etc..) should be aware of the abstract topology of the transport
network. This entity is the customer controller as per
<xref target="ACTN-FWK"/> which interacts with Virtual Network Controller (VNC).
The abstract topology may consist of established
tunnels in optical transport
network or ones that can be created on demand.
The level of abstraction is dependent on various management,
security and policy considerations. This
abstract topology information in the packet network can be utilized
in various cases - </t>
<t>
<list style="symbols">
<t>Traffic Planning, Monitoring and Automatic Network Adjustments</t>
<t>Automated Unified Congestion Management</t>
<t>Protection and Restoration Synergy across Packet and Optical</t>
<t>Service Awareness across Packet and Optical</t>
</list>
</t>
<t>They are described in detail in <xref target="ACTN-POI-USECASE"/></t>
</section>
<section title="Service Provider" toc="default">
<t>Service providers as an entity is described in <xref target="ACTN-FWK"/> - as
a provider of virtual network services to their customers. Service providers may
or may not own physical network resources. When a service provider is the same
as the network provider, this is similar to traditional VPN models. This model
works well when the customer maintains a single interface with a single provider.
When customer location spans across multiple independent network provider domains,
then it becomes hard to facilitate the creation of end-to-end virtual network
services with this model. A more interesting case arises when network providers
only provide infrastructure while service providers directly interface their
customers. In this case, service providers themselves are customers of the
network infrastructure providers. One service provider may need to keep multiple
independent network providers as its end-users span geographically across multiple
network provider domains (<xref target="FIG1"/>).
</t>
<section title="Carriers-of-Carrier" toc="default">
<t>The customer of a VPN service provider might be a service provider for the
end customer. <xref target="RFC4364"/> describes two main types of
carrier-of-carriers VPNs:</t>
<t>
<list style="symbols">
<t>Internet Service Provider as the Customer - The VPN customer is an ISP that
uses the VPN service provider network to connect its geographically disparate
regional networks. </t>
<t>VPN Service Provider as the Customer - The VPN customer is itself a VPN service
provider offering VPN service to its customers. The carrier-of-carriers VPN service
customer relies on the backbone VPN service provider for inter-site connectivity. </t>
</list>
</t>
<t><xref target="ACTN-FWK"/> supports such recursiveness - a customers of a
given service provider can in turn offer a service to other customers and thus
well suited for such use-case. </t>
<figure title="Carriers-of-Carrier" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG2">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
+-----+
| VPN |
| A |
+-----+
|
+----------------------+ +-----+
| VPN Customer |-| VPN |
| | | B |
+----------------------+ +-----+
|
+----------------------+
| Backbone VPN |
| Provider |
+----------------------+
|
+-----+ +----------------------+
| VPN |-| VPN Customer |
| A | | |
+-----+ +----------------------+
|
+-----+
| VPN |
| B |
+-----+
]]></artwork>
</figure>
</section>
<section title="Virtual Network Provider" toc="default">
<t>A virtual network provides a communications services without owning
the network infrastructure over which it provides services to its customers.
An virtual network operator enters into a business agreement with a physical
network operator to obtain bulk access to network services at wholesale rates,
then sets retail prices independently. An virtual network operator may use
its own customer service, billing, marketing and sales in some cases.</t>
<t>ACTN framework (<xref target="ACTN-FWK"/>) provides tools for the
Virtual Network Operator (VNO) to control the leased physical network slice in
a much granular level by less abstraction and thus providing more control.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>TBD.</t>
</section>
<section title="IANA Considerations" toc="default">
<t>None, this is an informational document.</t>
</section>
<section title="Acknowledgments" toc="default">
<t>TBD.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4364.xml" ?>
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.5623.xml" ?>
<!--STATEFUL-PCE-->
<reference anchor="STATEFUL-PCE">
<front>
<title>PCEP Extensions for Stateful PCE
[draft-ietf-pce-stateful-pce]</title>
<author fullname="Edward Crabbe" initials="E"
surname="Crabbe">
<organization></organization>
</author>
<author fullname="Jan Medved" initials="J" surname="Medved">
<organization></organization>
</author>
<author fullname="Ina Minei" initials="I" surname="Minei">
<organization></organization>
</author>
<author fullname="Robert Varga" initials="R" surname="Varga">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
<!--ACTN-FWK-->
<reference anchor="ACTN-FWK">
<front>
<title>Framework for Abstraction and Control of Transport Networks (draft-ceccarelli-actn-framework)</title>
<author fullname="Daniele Ceccarelli" initials="D" surname="Ceccarelli"></author>
<author fullname="Luyuan Fang" initials="L" surname="Fang"></author>
<author fullname="Young Lee" initials="Y" surname="Lee"></author>
<author fullname="Diego Lopez" initials="D" surname="Lopez"></author>
<date month="February" year="2014" />
</front>
</reference>
<!--ACTN-PROBLEM-->
<reference anchor="ACTN-PROBLEM">
<front>
<title>Problem Statement for Abstraction and Control of Transport Networks (draft-leeking-actn-problem-statement)</title>
<author fullname="Young Lee" initials="Y" surname="Lee"></author>
<author fullname="Daniel King" initials="D" surname="King"></author>
<date month="February" year="2014" />
</front>
</reference>
<!--ACTN-POI-USECASE-->
<reference anchor="ACTN-POI-USECASE">
<front>
<title>Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN) (draft-dhody-actn-poi-use-case)</title>
<author fullname="Dhruv Dhody" initials="D" surname="Dhody"></author>
<author fullname="Xian Zhang" initials="X" surname="Zhang"></author>
<author fullname="Oscar Gonzalez de Dios" initials="O" surname="Gonzalez de Dios"></author>
<author fullname="Daniele Ceccarelli" initials="D" surname="Ceccarelli"></author>
<date month="February" year="2014" />
</front>
</reference>
</references>
<section title="Contributor Addresses" toc="default">
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Luyuan Fang
Microsoft
USA
EMail: luyuanf@gmail.com
Ning So
Tata Communications
USA
EMail: Ning.So@tatacommunications.com
Young Lee
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA
Email: leeyoung@huawei.com
Daniel King
Old Dog Consulting
UK
EMail: daniel@olddog.co.uk
Daniel Ceccarelli
Ericsson
Via Melen, 77
Genova, Italy
Email: daniele.ceccarelli@ericsson.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:47:18 |