Internet DRAFT - draft-dhody-actn-poi-use-case
draft-dhody-actn-poi-use-case
Network Working Group D. Dhody
Internet-Draft X. Zhang
Intended status: Informational Huawei Technologies
Expires: May 1, 2017 O. Gonzalez de Dios
Telefonica
D. Ceccarelli
Ericsson
B. Yoon
ETRI
October 28, 2016
Packet Optical Integration (POI) Use Cases for Abstraction and Control
of TE Networks (ACTN)
draft-dhody-actn-poi-use-case-07
Abstract
This document describes the Abstraction and Control of TE Networks
(ACTN) use cases related to Packet and Optical Integration (POI),
that may be potentially deployed in various TE networks and apply to
different applications.
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 May 1, 2017.
Copyright Notice
Copyright (c) 2016 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
Dhody, et al. Expires May 1, 2017 [Page 1]
Internet-Draft ACTN-POI-USECASE October 2016
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. POI Scenario . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Packet Optical Integration . . . . . . . . . . . . . . . . . 7
3.1. Traffic Planning, Monitoring and Automatic Network
Adjustments . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Automated Congestion Management . . . . . . . . . . . 8
3.2. Protection and Restoration Synergy . . . . . . . . . . . 8
3.3. Service Awareness . . . . . . . . . . . . . . . . . . . . 9
3.4. Coordination between Multiple Network Domains . . . . . . 9
4. Typical Workflow . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
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.
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.
Dhody, et al. Expires May 1, 2017 [Page 2]
Internet-Draft ACTN-POI-USECASE October 2016
[ACTN-REQ] describes high-level ACTN requirements some of which are
derived from the usecases described in this document.
[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.
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:
o 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.
o 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.
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) [RFC4655] and its stateful extension
[STATEFUL-PCE] can further provide a central control over the
resources. Also [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. [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.
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.
Dhody, et al. Expires May 1, 2017 [Page 3]
Internet-Draft ACTN-POI-USECASE October 2016
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 [RFC4208]
and [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.
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.
1.1. POI Scenario
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.
Figure 1 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.
Dhody, et al. Expires May 1, 2017 [Page 4]
Internet-Draft ACTN-POI-USECASE October 2016
+------------+
+------------------+ 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
Figure 1: POI for single adminstration
Figure 2 shows a Carriers-of-Carrier case, where an optical transport
infrastructure provider provides ACTN service to the ISP.
Dhody, et al. Expires May 1, 2017 [Page 5]
Internet-Draft ACTN-POI-USECASE October 2016
+-------------+
| ISP |
| Controler | (CNC)
+------------+------+------+---------------+
| | |
| | |
| V |
| +------------+ |
| | MDSC | |
| | | |
| +------------+ |
| | |
| | |
| V |
| +------------+ |
+-+-------+ | PNC | +--------+-+
| -- | | | | -- |
| | | | +------------+ || | |
| -- | | -- -- |
| -- | +-----------------+ | -- | | |
| | |**** | -- -- | ***| | -- |
| -- |*****| | | |**** | -- |
+---------+ | -- -- | +----------+
ISP | -- | ISP
(Packet) | | | -- | (Packet)
| -- | | |
| -- |
+-----------------+
Infrastructre
Provider
(optical)
Figure 2: POI for Carriers-of-Carrier
2. Terminology
The following terms are as defined in [ACTN-FWK]:
o CNC:Customer Network Controller
o PNC:Physical Network Controller
o MDSC:Multi-domain Service Coordinator
The following terminology is used in this document.
ACTN: Abstraction and Control of Transport Networks.
Dhody, et al. Expires May 1, 2017 [Page 6]
Internet-Draft ACTN-POI-USECASE October 2016
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.
POI: Packet and Optical Integration
VNTM: Virtual Network Topology Manager
3. Packet Optical Integration
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.
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) [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 [ACTN-FWK] which interacts with MDSC. This
is shown in Figure 2. 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 Figure 1.
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.
3.1. Traffic Planning, Monitoring and Automatic Network Adjustments
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.
A unified Packet+Optical traffic planning tool can be developed which
uses the traffic demand matrix to plan the optical transport network.
Dhody, et al. Expires May 1, 2017 [Page 7]
Internet-Draft ACTN-POI-USECASE October 2016
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.
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.
3.1.1. Automated Congestion Management
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.
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.
3.2. Protection and Restoration Synergy
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.
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
Dhody, et al. Expires May 1, 2017 [Page 8]
Internet-Draft ACTN-POI-USECASE October 2016
the packet and optical. A mechanism to provide abstracted SRLG
information can help the packet network consider this information
while handling protection and restoration.
3.3. Service Awareness
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.
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.
3.4. Coordination between Multiple Network Domains
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.
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.
The ACTN framework as described in [ACTN-FWK] should support the
aggregation and orchestration across network domains and layers.
Further Figure 3 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.
Dhody, et al. Expires May 1, 2017 [Page 9]
Internet-Draft ACTN-POI-USECASE October 2016
+-------------------------+
| MDSC |
| |
+-------------------------+
*
+------------+---------+--+ * +-----------+---------+--+
| +---------+ | * | +---------+ |
| | PNC ************************* PNC | |
| +---------+---------+ | * | +---------+---------+ |
| | | | * | | | |
| | | | * | | | |
| | | | * | | | |
| | Packet | | * | | Packet | |
| +-------------------+ | * | +-------------------+ |
| | * | |
| | * | |
| | * | |
| | * | |
| | * | |
| +---------+ | * | +---------+ |
| | PNC ************************* PNC | |
| +---------+---------+ | | +---------+---------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | Optical | | | | Optical | |
| +-------------------+ | | +-------------------+ |
+---+-------------------+-+ +--+-------------------+-+
Domain 1 Domain 2
Figure 3: Coordination between Multiple Network Domains
4. Typical Workflow
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.
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 Figure 4.
Dhody, et al. Expires May 1, 2017 [Page 10]
Internet-Draft ACTN-POI-USECASE October 2016
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 +-----------------------------------+
Figure 4: Typical Workflow
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.
Dhody, et al. Expires May 1, 2017 [Page 11]
Internet-Draft ACTN-POI-USECASE October 2016
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.
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.
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.
5. Security Considerations
TBD.
6. IANA Considerations
None, this is an informational document.
7. Acknowledgments
8. References
8.1. Normative References
[ACTN-FWK]
Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas-
actn-framework-01 (work in progress), October 2016.
Dhody, et al. Expires May 1, 2017 [Page 12]
Internet-Draft ACTN-POI-USECASE October 2016
[ACTN-REQ]
Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D.
Ceccarelli, "Requirements for Abstraction and Control of
TE Networks", draft-ietf-teas-actn-requirements-03 (work
in progress), July 2016.
8.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<http://www.rfc-editor.org/info/rfc4208>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[STATEFUL-PCE]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-16 (work in progress), September 2016.
[STATEFUL-PCE-INITIATED]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-07 (work in
progress), July 2016.
Dhody, et al. Expires May 1, 2017 [Page 13]
Internet-Draft ACTN-POI-USECASE October 2016
Appendix A. Contributor Addresses
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: udayasree.palle@huawei.com
Authors' Addresses
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
EMail: zhang.xian@huawei.com
Oscar Gonzalez de Dios
Telefonica
Spain
EMail: ogondio@tid.es
Daniele Ceccarelli
Ericsson
Via E. Melen 77, Genova - Erzelli
Italy
EMail: daniele.ceccarelli@ericsson.com
Dhody, et al. Expires May 1, 2017 [Page 14]
Internet-Draft ACTN-POI-USECASE October 2016
Bin-Yeong Yoon
ETRI
South Korea
EMail: byyun@etri.re.kr
Dhody, et al. Expires May 1, 2017 [Page 15]
