| Network Working Group | D. Dhody |
| Internet-Draft | X. Zhang |
| Intended status: Informational | Huawei Technologies |
| Expires: October 16, 2016 | O. Gonzalez de Dios |
| Telefonica | |
| D. Ceccarelli | |
| Ericsson | |
| B. Yoon | |
| ETRI | |
| April 14, 2016 |
Packet Optical Integration (POI) Use Cases for Abstraction and Control of TE Networks (ACTN)
draft-dhody-actn-poi-use-case-06
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.
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 October 16, 2016.
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 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.
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.
[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:
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.
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.
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.
+------------+
+------------------+ 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.
+-------------+
| ISP |
| Controler | (CNC)
+------------+------+------+---------------+
| | |
| | |
| V |
| +------------+ |
| | MDSC | |
| | | |
| +------------+ |
| | |
| | |
| V |
| +------------+ |
+-+-------+ | PNC | +--------+-+
| -- | | | | -- |
| | | | +------------+ || | |
| -- | | -- -- |
| -- | +-----------------+ | -- | | |
| | |**** | -- -- | ***| | -- |
| -- |*****| | | |**** | -- |
+---------+ | -- -- | +----------+
ISP | -- | ISP
(Packet) | | | -- | (Packet)
| -- | | |
| -- |
+-----------------+
Infrastructre
Provider
(optical)
Figure 2: POI for Carriers-of-Carrier
The following terms are as defined in [ACTN-FWK]:
The following terminology is used in this document.
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.
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. 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.
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.
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 the packet and optical. A mechanism to provide abstracted SRLG information can help the packet network consider this information while handling protection and restoration.
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.
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.
+-------------------------+
| MDSC |
| |
+-------------------------+
*
+------------+---------+--+ * +-----------+---------+--+
| +---------+ | * | +---------+ |
| | PNC ************************* PNC | |
| +---------+---------+ | * | +---------+---------+ |
| | | | * | | | |
| | | | * | | | |
| | | | * | | | |
| | Packet | | * | | Packet | |
| +-------------------+ | * | +-------------------+ |
| | * | |
| | * | |
| | * | |
| | * | |
| | * | |
| +---------+ | * | +---------+ |
| | PNC ************************* PNC | |
| +---------+---------+ | | +---------+---------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | Optical | | | | Optical | |
| +-------------------+ | | +-------------------+ |
+---+-------------------+-+ +--+-------------------+-+
Domain 1 Domain 2
Figure 3: Coordination between Multiple Network Domains
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.
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.
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.
TBD.
None, this is an informational document.
| [ACTN-FWK] | Ceccarelli, D. and Y. Lee, "Framework for Abstraction and Control of Traffic Engineered Networks", Internet-Draft draft-ceccarelli-teas-actn-framework-02, April 2016. |
| [ACTN-REQ] | Lee, Y., Dhody, D., Belotti, S., Pithewan, K. and D. Ceccarelli, "Requirements for Abstraction and Control of TE Networks", Internet-Draft draft-ietf-teas-actn-requirements-02, April 2016. |
| [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. |
| [RFC4655] | Farrel, A., Vasseur, J. and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006. |
| [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. |
| [STATEFUL-PCE] | Crabbe, E., Minei, I., Medved, J. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-14, March 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", Internet-Draft draft-ietf-pce-pce-initiated-lsp-05, October 2015. |
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
EMail: udayasree.palle@huawei.com