| ACTN BOF | D. Dhody |
| Internet-Draft | X. Zhang |
| Intended status: Informational | Huawei Technologies |
| Expires: August 18, 2014 | O. Gonzalez de Dios |
| Telefonica | |
| February 14, 2014 |
Use Cases for Abstraction and Control of Transport Networks (ACTN)
draft-dhodyzhang-actn-use-case-00
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.
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 August 18, 2014.
Copyright (c) 2014 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.
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. 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. [ACTN-PROBLEM] and [ACTN-FWK] provides detailed information regarding this work.
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 -
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 [RFC2119].
Refer [ACTN-FWK] for PNC, VNC terminology.
The following terminology is used in this document.
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.
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).
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.
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.
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.
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.
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.
+----------------------+
| Data Center |
| Controller |
+----------------------+
|
+----------------------+
| VNC |
| |
+----------------------+
/ \
+--------------+ +--------------+
| PNC1 | | PNC2 |
+----------+ |--------------| |--------------| +----------+
| | | | | | | |
| DC1 | | Network | | Network | | DC2 |
| | | provider 1 | | provider 2 | | |
+----------+ | | | | +----------+
+--------------+ +--------------+
Figure 1: Geographically Dispersed DC
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.
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.
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.
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 transport network. This entity is the customer controller as per [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 -
They are described in detail in [ACTN-POI-USECASE]
Service providers as an entity is described in [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 (Figure 1).
The customer of a VPN service provider might be a service provider for the end customer. [RFC4364] describes two main types of carrier-of-carriers VPNs:
[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.
+-----+
| VPN |
| A |
+-----+
|
+----------------------+ +-----+
| VPN Customer |-| VPN |
| | | B |
+----------------------+ +-----+
|
+----------------------+
| Backbone VPN |
| Provider |
+----------------------+
|
+-----+ +----------------------+
| VPN |-| VPN Customer |
| A | | |
+-----+ +----------------------+
|
+-----+
| VPN |
| B |
+-----+
Figure 2: Carriers-of-Carrier
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.
ACTN framework ([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.
TBD.
None, this is an informational document.
TBD.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
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