One document matched: draft-dhody-actn-poi-use-case-04.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-dhody-actn-poi-use-case-04" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="ACTN-POI-USECASE">Packet Optical Integration (POI)
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>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560037</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>
<author initials="D" fullname="Daniele Ceccarelli" surname="Ceccarelli">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city>Via E. Melen 77</city>
<region>Genova - Erzelli</region>
<code></code>
<country>Italy</country>
</postal>
<email>daniele.ceccarelli@ericsson.com</email>
</address>
</author>
<author initials="B" fullname="Bin-Yeong Yoon" surname="Yoon">
<organization>ETRI</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>South Korea</country>
</postal>
<email>byyun@etri.re.kr</email>
</address>
</author>
<date month="April" year="2015" />
<area>Routing</area>
<workgroup>ACTN BOF</workgroup>
<abstract>
<t>This document describes the Abstraction and Control of
Transport Networks (ACTN) use cases related to Packet and
Optical Integration (POI), that may be potentially
deployed in various transport networks and apply to different
applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>Network operators build and operate multi-layered multi-domain
networks and
these domains may be technology, administrative or vendor specific
(vendor islands). Interoperability for dealing with different
domains is a perpetual problem for operators. Due to these issues,
new service introduction, often requiring connections that traverse
multiple domains, need significant planning, and several manual
operations to interface different vendor equipment and technology
accross IP and Optical layers.</t>
<t>The aim of Abstraction and Control of Transport Networks (ACTN)
is to facilitate virtual network operation, creation of a
virtualized environment allowing operators to view and control
multi-subnet multi-technology networks into a single virtualized
network. This will accelerate rapid service deployment of new
services, including more dynamic and elastic services, and improve
overall network operations and scaling of existing services.
</t>
<t><xref target="ACTN-REQ"/> describes high-level ACTN requirements
some of which are derived from the usecases described in this
document.</t>
<t><xref target="ACTN-FWK"/> describes a business model of ACTN,
comprising of customers, service providers and network providers.
This separates the network operations on physical network from the
business needs (based on virtual network). It further describes
the architecture model for ACTN including the entities (Customer
Network Controller(CNC), Mult-domain Service Coordinator(MDSC), and
Physical Network Controller(PNC)) thier interfaces.</t>
<t>Discussion with operators has highlighted a need for virtual
network operation based on the abstraction of underlying technology
and vendor domains. This would be used for a variety of key use
cases, including: </t>
<t>
<list style="symbols">
<t>Physical network infrastructure providers who want to build
virtual network operations infrastructure via standards-based
interfaces that facilitates automation and operation of multiple virtual
networks for both internal and external trust domains.</t>
<t>Data Center operators that need to lease facility from a number
of physical network infrastructure providers to offer their global
data center applications and services. As they face multi-domain and
diverse transport technology, interoperability based on
standard-based abstraction will enable dynamic and flexible
applications and services.</t>
</list>
</t>
<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.
Also <xref target="STATEFUL-PCE-INITIATED"/> provides capability to
initiate and delete LSP dynamically. 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"/> provide detailed
information regarding this work.
This document focuses on the Packet and Optical Integration (POI) use
cases of ACTN. We refer to POI as packet over any connection-oriented
transport technologies such as MPLS-TE, MPLS-TP, OTN or WSON.</t>
<t>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>In a multi-layer network via client and server networking roles,
Label Switched Paths (LSPs) in a server (lower) layer are used to
carry client (higher) layer LSPs across the server (lower) layer
network. POI in a distributed
control plane environment may be achieved by
some of the existing mechanism as specified in <xref target="RFC4208"/> and
<xref target="RFC5623"/>. This document explores the POI use cases
of ACTN to help provide
programmable network services like orchestration, access to abstract topology and
control over the resources.</t>
<t>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.
</t>
<section title="POI Scenario" toc="default">
<t>This section explores some typical scenario for packet and optical
integration (POI). These include, but not limited to, a single
administrative domain as well as Carriers-of-Carrier case.</t>
<t><xref target="FIG1"/> shows a single administrative domain
comprising of both Packet and Optical transport networks. A POI
coordinator would help build and operate a multi-layered
multi-domain allowing operators to view and control a single
virtualized network.</t>
<figure title="POI for single adminstration" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG1">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
+------------+
+------------------+ POI |
| |Orchestrator|
| +-----+------+ (MDSC)
+-v---+ |
| | |
+-----+ +--v--+
Packet | |
Control +-----+
(PNC) Optical Control (PNC)
+------------+ +---------------------------+ +--------------+
| | | | | |
| +-+ | | +-+ +-+ | | +-+ +-+ |
| |R| |***|O| |O|********|R| |R| |
| +-+ +-+ |*| +-+ +-+ +-+ | | +-+ +-+ |
| |R|*****| |O| | | |
| +-+*****| +-+ | | |
| +-+ |*| +-+ +-+ +-+ | | +-+ |
| |R| |*****|O| |O| |O|*******|R| |
| +-+ | | +-+ +-+ +-+ | | +-+ |
| | | | | |
+------------+ +---------------------------+ +--------------+
Packet Optical Transport Packet
Network Network Network
]]></artwork>
</figure>
<t><xref target="FIG2"/> shows a Carriers-of-Carrier case, where an
optical transport infrastructure provider provides ACTN service to
the ISP.</t>
<figure title="POI for 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[
+-------------+
| ISP |
| Controler | (CNC)
+------------+------+------+---------------+
| | |
| | |
| V |
| +------------+ |
| | MDSC | |
| | | |
| +------------+ |
| | |
| | |
| V |
| +------------+ |
+-+-------+ | PNC | +--------+-+
| -- | | | | -- |
| | | | +------------+ || | |
| -- | | -- -- |
| -- | +-----------------+ | -- | | |
| | |**** | -- -- | ***| | -- |
| -- |*****| | | |**** | -- |
+---------+ | -- -- | +----------+
ISP | -- | ISP
(Packet) | | | -- | (Packet)
| -- | | |
| -- |
+-----------------+
Infrastructre
Provider
(optical)
]]></artwork>
</figure>
</section>
</section>
<section title="Terminology" toc="default">
<t>The following terms are as defined in <xref target="ACTN-FWK"/>:</t>
<t>
<list style="symbols">
<t>CNC:Customer Network Controller</t>
<t>PNC:Physical Network Controller</t>
<t>MDSC:Multi-domain Service Coordinator</t>
</list>
</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="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="VNTM:">Virtual Network Topology Manager</t>
</list>
</t>
</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>One possible way to envision POI is via considering packet network
as customer i.e. 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 optical transport
network. This entity is the customer network controller (CNC) as per
<xref target="ACTN-FWK"/> which interacts with MDSC.
This is shown in <xref target="FIG2"/>. Another way would be to
consider Packet and Optical transport networks as domains and a POI
coordinator (MDSC) to help build and operate a multi-layered
multi-domain network allowing operators to view and control a single
virtualized network as shown in <xref target="FIG1"/>.</t>
<t>
In either case, 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, as detailed in the following sections.
</t>
<section title="Traffic Planning, Monitoring and Automatic Network Adjustments" toc="default">
<t>Currently there is a schism between network planning for packet
and optical transport networks. Sometimes these networks are administered, operated
and planned independently even when they are a part of a single trusted domain.
Any change in traffic requirements
requires long business process to make changes in the network. In dynamic
networks this is no longer acceptable. </t>
<t>A unified Packet+Optical traffic planning tool can be developed which
uses the traffic demand matrix to plan the optical transport network. Further based
on traffic demand changes, historical data, traffic prediction and
monitoring, changes should be made to the optical transport network. An
access to abstract topology of the optical transport network based on
established and potential
(on-demand) tunnels in optical transport network can provide mechanism to handle this.</t>
<t>Further optical bypass may be established automatically to offload the
continuous changing traffic to optical transport network allowing streamlined
business process between packet and optical transport networks.</t>
<section title="Automated Congestion Management" toc="default">
<t>Congestion management and synergized network optimization for packet
and optical transport networks can eliminate the need for overbooking of
optical transport networks as dumb pipes. Application could be written that
provide automated congestion management and network optimization.
Automated congestion management recognizes prolonged congestion
in the network and works with the controllers to add bandwidth
at an optical transport layer, to alleviate the congestion, or make changes
in the packet layer to reroute traffic around the congestion. </t>
<t>For such applications there is a clear need for an abstract network topology of
optical transport layer, further there is also a need for a synergy of cost and SLA across
optical and packet networks.</t>
</section>
</section>
<section title="Protection and Restoration Synergy" toc="default">
<t>The protection and restoration are usually handled individually in Packet and
optical layer. There is a need for synergy and optimized handling of
protection of resources across layers. A lot more resources in the optical
transport network are booked for backup then actually required since there is a lack
of coordination between packet and optical layers. The access to abstract graph
of optical transport network with information pertaining to backup path information
can help the packet network to handle protection, shared risk, fault
restoration in an optimized way. Informing the packet network about both working and
protection path which are either already established, or potential path can
be useful.</t>
<t>A significant improvements in overall network availability that can be
achieved by using optical transport shared-risk link group (SRLG) information
to guide packet network decisions; for example, to avoid or minimize common
SRLGs for the main (working) path and the loop free alternative or traffic
engineered fast reroute (LFA/TE FRR) back-up path.
Shared risk information need to be synergized between the packet and optical.
A mechanism to provide abstracted SRLG information can help the packet network
consider this information while handling protection and restoration.
</t>
</section>
<section title="Service Awareness" toc="default">
<t>In certain networks like financial information network (stock/
commodity trading) and enterprises using cloud based applications,
Latency (delay), Latency-Variation (jitter), Packet Loss and
Bandwidth Utilization are associated with the SLA. These SLAs must
be synergized across packet and optical transport networks. Network optimization
evaluates network resource usage at all layers and recommends or executes
service path changes while ensuring SLA compliance. It thus makes more
effective use of the network, and relieves current or potential congestion.</t>
<t>The main economic benefits of ACTN arise from its ability to maintain
the SLA of the services at reduced overall network cost considering both packet
and optical transport network. Operational benefits of the
ACTN also stem from greater flexibility in handling dynamic traffic such as
demand uncertainty or variations over time, or optimization based on cost or
latency, or improved handling of catastrophic failures.</t>
</section>
<section title="Coordination between Multiple Network Domains" toc="default">
<t>In some deployments, optical transport network may further be divided into multiple
domains, an abstracted topology comprising of multiple optical domains
MAY be provided to the packet network. A Seamless aggregation
and orchestration across multiple optical transport domains is achieved
via the MDSC, a great help in such deployments.</t>
<t>Another interesting deployment involves multiple packet network domains.
There exist scenarios where the topology provided to the packet network
domains may be different based on
the initial demand matrix as well as, management, security and
policy considerations. </t>
<t>The ACTN framework as described in <xref target="ACTN-FWK"/>
should support the aggregation and orchestration across network domains
and layers.</t>
<t>Further <xref target="FIG3"/> shows a multi-domain scenario where
multiple PNC (each controlling a packet or optical domain) and a MDSC
coordinating among them and providing a consolidated view.</t>
<figure title="Coordination between Multiple Network Domains"
suppress-title="false" align="left" alt="" width="" height="" anchor="FIG3">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
+-------------------------+
| MDSC |
| |
+-------------------------+
*
+------------+---------+--+ * +-----------+---------+--+
| +---------+ | * | +---------+ |
| | PNC ************************* PNC | |
| +---------+---------+ | * | +---------+---------+ |
| | | | * | | | |
| | | | * | | | |
| | | | * | | | |
| | Packet | | * | | Packet | |
| +-------------------+ | * | +-------------------+ |
| | * | |
| | * | |
| | * | |
| | * | |
| | * | |
| +---------+ | * | +---------+ |
| | PNC ************************* PNC | |
| +---------+---------+ | | +---------+---------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | Optical | | | | Optical | |
| +-------------------+ | | +-------------------+ |
+---+-------------------+-+ +--+-------------------+-+
Domain 1 Domain 2
]]></artwork>
</figure>
</section>
</section>
<section title="Typical Workflow" toc="default">
<t>Consider a two-layer network where the higher-layer network is a
packet-based IP/MPLS or GMPLS network and the lower-layer network is
a GMPLS-controlled optical network both under a common administrative
control.</t>
<t>The PNC in both layers are under a common MDSC that coordinates between
the two layers. And this multi-layer network is used to interconnect
DCs, where the DC controller (customer network controller - CNC) takes
charge as shown in <xref target="FIG4"/>. </t>
<figure title="Typical Workflow"
suppress-title="false" align="left" alt="" width="" height="" anchor="FIG4">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
Data Center
***** Controller
-------------------------------------*CNC*-------------
| ***** |
| | Multi-layer |
| v Coordinator |
| ****** |
| *MDSC*-- |
Data | ****** | |
Center | | |
+----+ | ***** | +----+ |
| DC1|<- *PNC*<- | DC3|<-
+----+ | ***** | +----+ |
.....|.. Packet | .... |
+----+ | . +-----------------------------------+ | .+----+ |
| DC2|<- .. /R R R R..../...|..| DC4|<-
+----+ / R R / | +----+
........./....R . R . R R../.....|.....
+-----------------------------------+ |
Packet . . . . . . |
Layer . . . . . . |
. . . . . . ***** |
. . . . . . *PNC*<-
. . . . . . ***** Optical
+-----------------------------------+
/ O . O . O . O O /
/ O . O O /
Optical / O O O O O /
Layer +-----------------------------------+
]]></artwork>
</figure>
<t>Data centre controller (as Customer Network Controller)
interfaces the data centre application stratum, it understands multiple
DC application requirements and their service needs. DC Controller provides
its traffic demand matrix that
describes bandwidth requirements and other optional QoS parameters
(e.g., latency, diversity requirement, etc.) for each pair of inter-DC
connections. The MDSC (multi-layer coordinator) sits between the DC controller
(CNC - the one issuing connectivity requests) and the physical network
controllers (the one managing the resources). In this case each layer
has its own PNC managing the resources in each layer with MDSC acting as a
multi-layer coordinator. The PNC is in charge of configuring
the network elements, monitoring the physical topology of the
network and passing it, either raw or abstracted, to the MDSC. </t>
<t>MDSC with the help of PNC(s) coordinates network resource control and
utilization facilitating network efficiency and network
automation. The MDSC are also responsible for the abstract topology and the
level of abstraction, which facilitate various DC
usecases like VM Migrations, global load balancing among geographically
distributed DCs, Business continuity and disaster recovery etc
using the ACTN framework in an elastic and dynamic and way,
improving overall network operations and scaling.
</t>
<t>Based on the Data centre controller's (acting as CNC) requests for virtual
network paths, the MDSC mediates with the PNCs and maps these 'virtual' request to
inter-layer coordinated path computation and provisioning requests in the 'physical'
domain to the PNC. Thus MDSC acts as a multi-layer coordinator both in respect to
multi-layer end to end optimized path computation as well as multi-layer signaling
and provisioning. The path computation and abstract topology creation would be
based on the guidelines set by the CNC including the optimization criteria, traffic
profile, policy etc. </t>
<t>In case the PNC could not fulfill the desired request from MDSC and indirectly
from DC controller, there should be a feedback loop to the MDSC so
that suitable actions including path recalculation and signaling, negotiation of parameters and attributes
with DC controller etc can be undertaken. Thus MDSC effectively arbitrate between the customers (DC) and
the existing network (PNC) in this example. </t>
</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></t>
</section>
</middle>
<back>
<references title="Normative References">
<!--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="Young Lee" initials="Y" surname="Lee"></author>
<date month="March" year="2015" />
</front>
</reference>
<!--ACTN-REQ-->
<reference anchor="ACTN-REQ">
<front>
<title>Requirements for Abstraction and Control of Transport Networks (draft-lee-teas-actn-requirements)</title>
<author fullname="Young Lee" initials="Y" surname="Lee"></author>
<author fullname="Dhruv Dhody" initials="D" surname="Dhody"></author>
<author fullname="Sergio Belotti" initials="S" surname="Belotti"></author>
<author fullname="Khuzema Pithewan" initials="K" surname="Pithewan"></author>
<author fullname="Daniele Ceccarelli" initials="D" surname="Ceccarelli"></author>
<date month="April" year="2015" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4208.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="2014" />
</front>
</reference>
<!--STATEFUL-PCE-INITIATED-->
<reference anchor="STATEFUL-PCE-INITIATED">
<front>
<title>PCEP Extensions for PCE-initiated LSP Setup in a
Stateful PCE Model [draft-ietf-pce-pce-initiated-lsp]</title>
<author fullname="Edward Crabbe" initials="E"
surname="Crabbe">
<organization></organization>
</author>
<author fullname="Ina Minei" initials="I" surname="Minei">
<organization></organization>
</author>
<author fullname="Siva Sivabalan" initials="S" surname="Sivabalan">
<organization></organization>
</author>
<author fullname="Robert Varga" initials="R" surname="Varga">
<organization></organization>
</author>
<date month="October" 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>
<author fullname="Mohamed Boucadair" initials="M" surname="Boucadair"></author>
<author fullname="Ruiquan Jing" initials="R" surname="Jing"></author>
<author fullname="Luis Miguel Contreras Murillo" initials="L" surname="Contreras Murillo"></author>
<date month="September" 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[
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
EMail: udayasree.palle@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:59:40 |